4 ms·

Another reason to hash your passwords!

• homakov 12y ago
  It has nothing to do with passwords and hashes. API keys are not hashed normally. And all kinds of signatures. It's about way you compare strings from params with secret strings
• tshadwell 12y ago
  Perhaps another reason to use a fixed time string equality function
  • yeukhon 12y ago
    You mean checking 123 == 1234 actually going through all 4 characters instead of immediate stop?
    • mikeash 12y ago
      I believe it's OK to bail out early if the lengths aren't equal, but otherwise yes, you'd want e.g. 1234 == 1345 to continue to the end even though it's obvious from the second character that they aren't equal.
      • bmm6o 12y ago
        Bailing early reveals the information that the lengths are different. In most cases the attacker knows the length of the target string and so this test will never pass. You can probably imagine a scenario where the length isn't known and step 1 is to determine the target length.
• emidln 12y ago
  I can think of a couple examples where hashing passwords directly contributes to leaking information recoverable by examining timing (e.g. enumerating django privilege status for a site's users). Edit: not to say that you should store your password plaintext. Hashing (well, properly using a KDF) isn't a panacea.
• squigs25 12y ago
  Everyone who down voted this: 1) I know this would NEVEEERRRRRRR happen, but if there was a website that didn't hash a password, the timing attack would be applicable. 2) It worth mentioning that a timing attack can be frequently foiled if hashing is used on the server side. I.E. Google gives me an API key, stores the hash on there side. I send the API key to Google they hash it and ocmpare the hash to their stored hash. I think it's crazy how fat fingered people have become with the down vote trigger finger. I think it's 100% crazy to discus the timing attack without considering how it could be thwarted.