4 ms·
I didn't think hashing the hash would be helpful here, and couldn't think of a way to mitigate against this attack. After reading more it seems the only mitiga
by jaytaylor 7y ago
I didn't think hashing the hash would be helpful here, and couldn't think of a way to mitigate against this attack.
After reading more it seems the only mitigation is Layers of Security.
https://en.m.wikipedia.org/wiki/Pass_the_hash#Mitigations https://en.m.wikipedia.org/wiki/Pass_the_hash#Mitigations
- kragen 7y agoNo, hashing the hash solves the problem.
- jaytaylor 7y agoI see, clever. Thanks!
- lisper 7y agoIt's important to understand why this is so: it's because the hash is big, so while it might be possible to mount a brute force preimage attack against a password, it is not practical to do so against a hash. So hashing a hash (once) is secure even though hashing a password (once) isn't.
- throwaway838475 7y agoAlmost. That construction is still vulnerable to chosen input attacks without inner and outer padding, which is basically rediscovering HMAC, which also isn’t suitable for storing passwords. Don’t roll your own crypto if you don’t know what you’re doing. Use a PBKDF like argon2, scrypt, bcrypt or PBKDF2 as they are intended because they are far, far stronger than hashing a couple of times.
- nneonneo 7y agoI believe what we’re discussing is having a client compute a PBKDF of the password, and then having the server hash the PBKDF output one more time to obtain the thing that’s actually inserted into the database. The idea is that if the database leaks, the attacker gets H(PBKDF(password)) which is hard to bruteforce due to the PBKDF, and can’t be used directly as a login token because of the extra H(). I don’t see where this would be subject to a chosen input attack.