4 ms·

== in python will stop comparing after the first character mismatch. You can use that fact to test byte by byte your password knowing that the more good charact

by herge 11y ago

== in python will stop comparing after the first character mismatch. You can use that fact to test byte by byte your password knowing that the more good characters you have, the longer the comparison will take, which is called a timing attack. hmac.compare_digest is a constant time compare, in that no matter if there is a match or not, it will take the same amount of time.

Retric 11y ago
I don't think that's an issue when your comparing salted passwords. AKA F('Passsword') = Hash('Passsword' xor 'some value') = "123456" F("value") > "123455" which is close, but that does not let you get a 'better' guess. PS: Assuming the Salt is hidden, and the Hash is secure.
tptacek 11y ago
Timing attacks aren't useful against password hashes, but avoiding them is a good habit to be in.
- aidos 11y ago
  Would it still let you sneak in if the hash was rubbish? Say it was just a simple md5 of the password. If you could do a timing attack you could use rainbow tables of the hashes and whittle down the the possible set of passwords really quickly, right? So if the timing attack has told you that the first letter of the hashed version is 'A' then you find another password from the table that hashes to AAxxx, ABxxx, etc. Obviously that depends on you being able to precompute all the passwords in a consistent way as the hash being used. Along the same lines - could you use a timing attack to figure out a salt? I guess it's near impossible?
  - sarciszewski 11y ago
    You could potentially leak the first N bytes of a valid unsalted trash hash (e.g. MD5) and then use this information to optimize an offline brute-force attack. The more bytes you leak of the hash, the more you can narrow down your offline attempts and the less subsequent packets you need to fire. I was going to develop this into an exploit tool, called TARDIS (backronym for Timing Attack to Remotely Dispel the Illusion of Security) against, e.g. Piwik, Oxwall, and other products that still use MD5 passwords. The main reason I didn't was: No free time to build it and tune it against the internals of various programming languages' == implementations.
- sarciszewski 11y ago
  Precisely what Thomas said. Using == instead of hmac.compare_digest is unlikely to be a source of vulnerabilities in your application, but it's a good habit to get into whenever you touch cryptography. See also: https://news.ycombinator.com/item?id=10345965 https://news.ycombinator.com/item?id=10345965 (pg. 33-36, 42-43 of the PDF) Again consider timing leaks. Many interesting questions: How do secrets affect timings? How can attacker see timings? How can attacker choose inputs to influence how secrets affect timings? Et cetera. The boring-crypto alternative: crypto software is built from instructions that have no data flow from inputs to timings. Obviously constant time.
- Someone1234 11y ago
  This is "mostly true" but with an edge case... If the attacker knows which algorithm and work factor you're utilising and your system doesn't use randomly generated per user salts (or an unknown pepper) then theoretically an attacker could use a hash timing attack, combined with a rainbow table, to massively reduce the scope of a user's potential password. For example, let's say your rainbow table has 20 million password-hash combinations and your hash length is 33 letters, for every letter I know I could drop literally millions of hashes I know it ISN'T. With just the first four letters I could drop it by almost 60% (although my maths here might be completely wrong, it is actually pretty complicated to determine). But there's no real limit on how many letters you could drop from the hash with a timing attack, you could turn someone's password into a 1 in 62 chance. The TL;DR: Use a per user salt. But a timing immune comparison definitely is "defense in depth" in case there is a bug elsewhere that breaks salts.
  - tptacek 11y ago
    I chose the words "password hash" carefully. If you're using a secure password hash, you're not worrying about salts, because they take care of randomization for you. If you are worrying about salts, you probably have bigger problems than memcmp timing.
    - Someone1234 11y ago
      I literally don't understand what it is you're getting at. Password hashing has existed since at least the 1970s and until the 2000s salting wasn't common. While some hashing libraries do insist on you supplying a salt, it is still ultimately up to the application developer to generate and store the salt for later usage. Therefore it is still common for an application developer to "worry about salts" even if just for storage and generation reasons. Anyone using 3DES, MD5, or similar is likely vulnerable to timing attacks, and they're definitely still in the realm of a "password hash." Plus some wonderful developers hard code the salt (salt = "secret") which too could leave them vulnerable to timing attacks if an attacker knew what hashing algorithm and workfactor (e.g. the default) was in usage.
      - 11y ago
deleted 11y ago
[deleted]

by herge 11y ago

Retric 11y ago

I don't think that's an issue when your comparing salted passwords. AKA F('Passsword') = Hash('Passsword' xor 'some value') = "123456" F("value") > "123455" which is close, but that does not let you get a 'better' guess. PS: Assuming the Salt is hidden, and the Hash is secure.

tptacek 11y ago

Timing attacks aren't useful against password hashes, but avoiding them is a good habit to be in.

aidos 11y ago
Would it still let you sneak in if the hash was rubbish? Say it was just a simple md5 of the password. If you could do a timing attack you could use rainbow tables of the hashes and whittle down the the possible set of passwords really quickly, right? So if the timing attack has told you that the first letter of the hashed version is 'A' then you find another password from the table that hashes to AAxxx, ABxxx, etc. Obviously that depends on you being able to precompute all the passwords in a consistent way as the hash being used. Along the same lines - could you use a timing attack to figure out a salt? I guess it's near impossible?
- sarciszewski 11y ago
  You could potentially leak the first N bytes of a valid unsalted trash hash (e.g. MD5) and then use this information to optimize an offline brute-force attack. The more bytes you leak of the hash, the more you can narrow down your offline attempts and the less subsequent packets you need to fire. I was going to develop this into an exploit tool, called TARDIS (backronym for Timing Attack to Remotely Dispel the Illusion of Security) against, e.g. Piwik, Oxwall, and other products that still use MD5 passwords. The main reason I didn't was: No free time to build it and tune it against the internals of various programming languages' == implementations.
sarciszewski 11y ago
Precisely what Thomas said. Using == instead of hmac.compare_digest is unlikely to be a source of vulnerabilities in your application, but it's a good habit to get into whenever you touch cryptography. See also: https://news.ycombinator.com/item?id=10345965 https://news.ycombinator.com/item?id=10345965 (pg. 33-36, 42-43 of the PDF) Again consider timing leaks. Many interesting questions: How do secrets affect timings? How can attacker see timings? How can attacker choose inputs to influence how secrets affect timings? Et cetera. The boring-crypto alternative: crypto software is built from instructions that have no data flow from inputs to timings. Obviously constant time.
Someone1234 11y ago
This is "mostly true" but with an edge case... If the attacker knows which algorithm and work factor you're utilising and your system doesn't use randomly generated per user salts (or an unknown pepper) then theoretically an attacker could use a hash timing attack, combined with a rainbow table, to massively reduce the scope of a user's potential password. For example, let's say your rainbow table has 20 million password-hash combinations and your hash length is 33 letters, for every letter I know I could drop literally millions of hashes I know it ISN'T. With just the first four letters I could drop it by almost 60% (although my maths here might be completely wrong, it is actually pretty complicated to determine). But there's no real limit on how many letters you could drop from the hash with a timing attack, you could turn someone's password into a 1 in 62 chance. The TL;DR: Use a per user salt. But a timing immune comparison definitely is "defense in depth" in case there is a bug elsewhere that breaks salts.
- tptacek 11y ago
  I chose the words "password hash" carefully. If you're using a secure password hash, you're not worrying about salts, because they take care of randomization for you. If you are worrying about salts, you probably have bigger problems than memcmp timing.
  - Someone1234 11y ago
    I literally don't understand what it is you're getting at. Password hashing has existed since at least the 1970s and until the 2000s salting wasn't common. While some hashing libraries do insist on you supplying a salt, it is still ultimately up to the application developer to generate and store the salt for later usage. Therefore it is still common for an application developer to "worry about salts" even if just for storage and generation reasons. Anyone using 3DES, MD5, or similar is likely vulnerable to timing attacks, and they're definitely still in the realm of a "password hash." Plus some wonderful developers hard code the salt (salt = "secret") which too could leave them vulnerable to timing attacks if an attacker knew what hashing algorithm and workfactor (e.g. the default) was in usage.
    - 11y ago

deleted 11y ago

[deleted]