4 ms·
Just curious, but long passwords shouldn't in any way affect CPU load. After the first hash (of thousands?), it's just hashing a hash, which is always the same
by vectorjohn 11y ago
Just curious, but long passwords shouldn't in any way affect CPU load. After the first hash (of thousands?), it's just hashing a hash, which is always the same length unrelated to the original password length.
Even though I can't think of a legitimate use for > 256 character passwords.
- Someone1234 11y agoCannot argue with that. It should be noted that 256 characters is our default across all inputs if no other maximum has been selected. We could trivially increase it on passwords, but as you said, 256 is already higher than 99% of people use for a password and not at all unreasonable. Allowing legitimately unlimited inputs could cause problems regardless of hashing, since our timeout (which is fairly long for other reasons) would ultimately be our only protection. But if there was a request/need/complaint we would just double it and day to day likely wouldn't notice a thing.
- phlo 11y ago> After the first hash, it's just hashing a hash The recommended password hashing functions (PBKDF2, bcrypt, scrypt) actually use the provided password in each iterated round of the algorithm. The DoS vector Someon1234 mentioned is real and has previously affected Django[0] (and, I believe, others). In order to prevent it, you should either limit the maximum password length (256 characters seems sensible, as does Django's choice of 4096) or hash the password (to a known length) before passing it to the KDF. [0] http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/ http://arstechnica.com/security/2013/09/long-passwords-are-g...