3 ms·
Easy fix: Apply a regular ol hash function first, so the input to the the cryptographic hash function is the short'ish fixed length output of the regular hash
by Sammi 7y ago
Easy fix:
Apply a regular ol hash function first, so the input to the the cryptographic hash function is the short'ish fixed length output of the regular hash function.
A good regular hash function will preserve the entropy of a long input password, so it doesn't hurt, and it solves the problem you present.
Bonus points for doing this on the client side so that you're not even using extra network bandwidth.
- yellow_lead 7y agoIs this sarcastic? If your regular hash function isn't cryptographically secure then it doesn't guarantee lots of things that normal hash functions do. You are potentially reducing the input/preimage to your cryptographic hash function to the output/image of your insecure hash function, which could compromise the cryptographic hash's preimage resistance. Maybe a better point, what happens if there's a collision in your regular hash function?
- Doxin 7y agoSammi is clearly assuming a cryptographically secure hash here which shouldn't provide any obvious problems with the method he proposes as far as I can tell.
- Sammi 7y agoYeah I've mixed up my terms here. Sorry. By regular ol hash I mean a Cryptographic Hash Function [0] (as in SHA1, SHA2...) and by cryptographic hash i mean a Key Derivation Function (as in bcrypt or argon2). [0] https://en.wikipedia.org/wiki/Cryptographic_hash_function https://en.wikipedia.org/wiki/Cryptographic_hash_function [1] https://en.wikipedia.org/wiki/Key_derivation_function https://en.wikipedia.org/wiki/Key_derivation_function