4 ms·

It frustrates me to read stuff like this because as much as it is technically sound, and will make a hash marginally more difficult to crack, I worry that compl

It frustrates me to read stuff like this because as much as it is technically sound, and will make a hash marginally more difficult to crack, I worry that complex criticisms of hashing algorithms can have the effect of discouraging application developers from using any hashing on passwords at all. Now I am going to mention something that will be very unpopular, but it is 100% true, so try to open your mind a little before reading. Let's compare not hashing, the worst hashing algorithm, and the best hashing algorithm. The worst will be something like MD5 with no salt, and the best using the most advanced hashing, random salts, and CPU-heavy calculations. We'll compare the effect of database compromise by a cracker on a user with a weak password (4-character dictionary word) and one with a strong password (15-character random a-Z, 0-9, and symbols) * No hashing - weak: cracked; strong: cracked * Worst hashing - weak: cracked; strong: safe * Best hashing - weak: cracked; strong: safe The best hash will protect more medium strength passwords than the worst but there is no hashing algorithm strong enough to protect the weakest passwords, and MD5 with no salt still protects the strongest. But there are other benefits of using any hashing over none: It protects your users from yourself and other admin-level people on your team and guarantees that your application cannot expose plaintext passwords even after you leave the project. tl;dr The difference between no password hashing and weak password hashing is significant and the difference between weak hashing and strong hashing is small.

nly 12y ago
This is pretty much why HSMs and good PAKE protocols are important. Key stretching only buys you a degree of computational hardness, whereas not storing or exchanging password derived material at all makes offline cracking provably hard. Hashing is just a stopgap measure that hopefully gives your users time to do something before they're compromised. It's hard to say how effective it is in practice when a new db dump goes to auction.
peterwwillis 12y ago
Your comparison is invalid because with 'worst hashing' a strong password is still cracked; there's simply too many workable attacks, the algorithm is too fast, and FPGA implementations are trivial. A password function is the last line of defense, and never foolproof. Looking at the history of successful password exfiltrations over time, attackers have about a month or two before somebody notices they got away with your data. So your password functions should ensure that passwords are strong enough that with current-day technology they can withstand at least that much time out in the wild; otherwise, don't even use a hash.

nly 12y ago

This is pretty much why HSMs and good PAKE protocols are important. Key stretching only buys you a degree of computational hardness, whereas not storing or exchanging password derived material at all makes offline cracking provably hard. Hashing is just a stopgap measure that hopefully gives your users time to do something before they're compromised. It's hard to say how effective it is in practice when a new db dump goes to auction.

peterwwillis 12y ago

Your comparison is invalid because with 'worst hashing' a strong password is still cracked; there's simply too many workable attacks, the algorithm is too fast, and FPGA implementations are trivial. A password function is the last line of defense, and never foolproof. Looking at the history of successful password exfiltrations over time, attackers have about a month or two before somebody notices they got away with your data. So your password functions should ensure that passwords are strong enough that with current-day technology they can withstand at least that much time out in the wild; otherwise, don't even use a hash.