Concluding: A better way to store password hashes?(opine.me)
opine.me
Concluding: A better way to store password hashes?
http://www.opine.me/all-your-hashes-arent-belong-to-us/
2 comments
For reference, this is a follow-up to an earlier opinion piece that was submitted and discussed here:
http://news.ycombinator.com/item?id=4216760
Seems 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.
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.
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.