3 ms·
I found out the main reason why passwords are limited length even when using modern hashing techniques. The problem is caused by the way multi-round password h
by infogulch 7y ago
I found out the main reason why passwords are limited length even when using modern hashing techniques.
The problem is caused by the way multi-round password hashing algorithms are designed. Specifically, in each round, the full contents of the password is concatenated with the previous round's hash result as the input to the next round. This means that the processing complexity of password hashing is proportional to `number of rounds * password length`. Because the implementation has to tune the number of rounds to their authentication server's performance, and because the tuning is performed on "normal length" passwords, this opens the authentication servers up to a DOS attack by overwhelming them with very long passwords which is only a problem because password hashing has quadratic complexity thanks to this design. Thus, in response, administrators are forced (!) to limit password length just so their authentication servers can't be attacked.
This design flaw (imo) could be pretty easily solved by hashing the user provided password once first, and then using that hash to concatenate each round. This changes the complexity to `number of rounds + password length` (note the "+" !). As a secondary benefit, the multi-round hashing step actually becomes constant time because all inputs are the same length! In fact, I wonder if the current design makes it possible to infer a user's password length from timing attacks on the authentication servers while a user is logging in.
I've not got any satisfactory cryptographic reason why we still use this design for password hashing besides platitudes like "don't roll your own crypto", appeal to authority "It's been designed by the experts", or stupid reasons like "but network bandwidth!" -- as if an http authentication request that's 4kb is gonna slow down the network vs a 3kb request (and this is a worst case of a relatively huge 1kb password!). Availability is an important part of security, and sacrificing both availability (vulnerability to DOS) and security (admins forced to limit password length) seems like a doubly whammy argument against the current design.
- Sammi 7y agoEasy 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