Password hashing

Tero Kivinen kivinen at
Wed Oct 17 07:38:18 EDT 2007

Joseph Ashwood writes:
> There is a shortcut in the design as listed, using the non-changing password 
> as the key allows for the optimization that a single HMAC can be keyed, then 
> copied and reused with each seed. this shortcut actually speeds attack by a 
> factor of 3. The fix is to use the salt as the HMAC key, this assumes much 
> less of the hash function.

When you are trying to crack password, you do know the SALT and
iteration count. You do not know the password. You need to try all
possible passwords with different salts. As we use the password we are
trying as an input to our test function we need to initialize
hmac_sha1 again for each pasword we are guessing. Or did I understand
something wrong.

With your fix I could take the SALT from the passwd string and
initialize first level of hmac with it and then feed different
password to it.


Adding USERID to the calculations will firstly break API
compatibility, as the crypt function do not know the userid. It will
also break the ability to copy the encrypted passwords from one
machine to other, even when you would need to change user id in the
progress (If I need to set up account for someone on my machines, I
usually either ask them to send me already encrypted password I can
put in to my /etc/password, or ask them to send me ssh public key... 
kivinen at

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at

More information about the cryptography mailing list