Concluding: A better way to store password hashes?
1–4 of 4 posts
Re: Concluding: A better way to store password hashes?
#2For reference, this is a follow-up to an earlier opinion piece that was submitted and discussed here:
http://news.ycombinator.com/item?id=4216760
Re: Concluding: A better way to store password hashes?
#3Seems like making the calculation of Hash2 computationally expensive places more burden on the application than it does on a hacker trying to compute plain-text passwords. The app has to work twice as hard to verify (e.g. scryptX2) while to brute force you only really need to match Hash1. To keep latency down this might encourage use of weaker hashing for Hash1 which seems bad.
Of course you could seed your hashes table with false positive matches (perhaps from the list of the top 10,000 passwords), in an attempt to force a hacker to calculate the second hash, but that doesn't seem like a strong defense.
Re: Concluding: A better way to store password hashes?
#4Seems like making the calculation of Hash2 computationally expensive places more burden on the application than it does on a hacker trying to compute plain-text passwords. The app has to work twice as hard to verify (e.g. scryptX2) while to brute force you only really need to match Hash1. To keep latency down this might encourage use of weaker hashing for Hash1 which seems bad. Of course you could seed your hashes ta…
Good point. Hash2 can be a plain vanilla SHA-256 HMAC. But don't say it too loud, or risk raising the ire of the scrypt zealots.