Hacker News new | past | comments | ask | show | jobs | submit login

I'm no security expert by any means, but my understanding is that HMAC is preferable to hash+salt.



That's kind of liking saying quinces are preferable to hoop skirts.

HMAC is a construction that takes a hash (like SHA1), data, and a secret key (like "ff79f2fbe108a68c34a66004058fcfdb988dbc43") and applies the hash twice, each with a special tweak, to create a digest that only someone who knows the key can recreate from the same data. It's how two parties who share a key can prove to each other that their messages haven't been tampered with.

Hash+salt is a construction that takes a hash (like SHA1), a password (like "gobears") and a random public value (like "$4jdle$") and creates a password hash out of it that can't be precomputed.

People do (ab)use HMAC as a password hash. Those people should know that HMAC is as easy to precompute as naked SHA1 is; you can "rainbow-table" HMAC. People who have misunderstood HMAC tend to stick up for it by saying "yeah, but people will have to find my secret key first", to which a response that ends that silly argument is "once they get your key, they can attack all your hashes in parallel and that's bad".

All of these schemes are demonstrably inferior to any adaptive hashing scheme, like bcrypt or scrypt or PBKDF2, all of which can be tuned so that a single password attempt takes 500ms (or any other time); they in effect require password crackers to complete a "proof of work" that can't be sped up without a breakthrough in cryptanalysis.


This is probably the clearest explanation of the distinction that I've read so far; thank you.


Good.

...

Some day, and that day may never come, I'll call upon you to explain cellular respiration to me.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: