mindstalk: (Default)
[personal profile] mindstalk
Good practice for a serving storing passwords is to not do so. Rather it hashes your password and stores that: when you log in, your password is hashed and compared to the stored value. This way someone who steals the password file doesn't get anything immediately useful. (Hashing is a one way function.) To prevent dictionary and other attacks, the password is combined with a non-secret 'salt' value, then hashed. (The password file contains the salt and the hash(password+salt) value.)

More recently, good practice has become to repeatedly hash the password like 1000 times. If a computer can do a billion hashes in a second then you won't notice a slower login, but it makes a brute force attack (of a stolen password file) 1000x harder. This is called "key stretching" or "key strengthening". The description on Wikipedia says to repeatedly hash the hash value with the salt, and I wondered why that was necessary. I think I figured it out.

Say the salt is applied just once, followed by 1000 consecutive hashings. It's possible that two passwords and their salts would collide, give the same value, samevalue, say on the 3rd iteration. Since they have the same value then, they'll have the same value on every subsequent hashing, and the same stored value in the file; they're basically locked in synchrony An attacker could see that they would get two accounts for the work of one.

But by repeatedly using the salt, that's foiled. In this case, the 4th iteration would see hash(samevalue, salt1) and hash(samevalue, salt2), and diverge again due to the different salts. You can still get collisions in the password file, but it has to actually be after 1000 iterations, not at any point in between.
Anonymous (will be screened)
OpenID (will be screened if not validated)
Identity URL: 
Account name:
If you don't have an account you can create one now.
HTML doesn't work in the subject.


Notice: This account is set to log the IP addresses of everyone who comments.
Links will be displayed as unclickable URLs to help prevent spam.

April 2019

141516 17181920

Expand Cut Tags

No cut tags

Style Credit

Most Popular Tags