Re:We didn't encrypt your password, we hashed it
by lostcolony on Saturday September 05, 2020 @12:11AM
(#24381348)
Um...you're missing the point.
It's fine to truncate the password (though ideally you don't do it at a super short length).
The issue you are replying to is referring to when a site doesn't do it for both account creation and login. Which is a bug. A stupid, hard to detect, hard to explain, likely never to be fixed, bug. That only affects people trying to be secure.
Re:We didn't encrypt your password, we hashed it
by infogulch on Saturday September 05, 2020 @01:35PM
(#24385349)
I get that different parts of a service truncating the password to different lengths is a problem, and that it's a different (perhaps worse) problem than the one that causes site operators to limit password lengths.
Iterated password hashing algorithms like bcrypt [2] use a parameter tuneable by the site operator that drastically varies the computational cost of calculating the hash, so a brute force attack on the hash could be required to use orders of magnitude more computational power to crack. The tradeoff is that it will make users wait longer to log in, and (might) incur additional operational cost to the site. This is why it's a tuneable parameter: Up increases security at the cost of user delay and operations.
In theory. In practice, the user delay and operational cost are also proportional to the user's password length, which you don't control. Observe, the leak. This can cause wildly varying response times for authentication attempts, and opens your authentication system up to a DoS attack. The only reasonable solution is to put a small cap on password length so that the longest passwords don't take more than 2-5 times as long to compute, as per each site's tolerance of variance.
So why does the runtime of the iterated hash function depend on the length of the password? In each iteration the user's password is joined to the previous iteration's hash, and hashed together to get this iteration's hash. The runtime of any hash function is proportional to the length of the data fed in, the data fed in includes the user's password, thus the runtime of an iteration is proportional to the length of the user's password. So the runtime of the whole iterated password hash is `O(Iterations * PasswordLength)`.
There are various schemes one could come up with to change the time to `O(Iterations + PasswordLength)` ~ `O(Iterations)`, such as concatenating the first hash of the user's password instead of the password itself on all successive iterations, so all iterations but the first are independent of the user-chosen password length. There could be some security/entropy-based arguments for avoiding this solution, though I don't know what that could be.
[1]: https://news.ycombinator.com/item?id=22749706