> 9 Verifiers SHALL verify the entire submitted password...
Is this "don't microwave your hamster"-requirement a result of the bcrypt trouble [1] or how comes?
[1] https://security.stackexchange.com/questions/39849/does-bcry...
Is this "don't microwave your hamster"-requirement a result of the bcrypt trouble [1] or how comes?
[1] https://security.stackexchange.com/questions/39849/does-bcry...
Back in my day, you see, there was this hash known as NTLM, which actually took your password and stored and then matched it in two ways, the NT hash (MD5 of your password in UTF-16) and the LM hash (split the first 14 bytes of your password in ASCII, then add parity bits and use that as a DES key to encrypt a well-known string). That LM hash was because they wanted it to be backwards compatible with Microsoft LanMan, introduced for OS/2 back in 1987. Even back in the 1990's it was a well known weak link, and given how trivial it is today to brute force a match for MD5 (since all characters after the first 14 can be arbitrary), you can see that this is simple to brute force with modern computing power. Microsoft has recommended NTLM not be used since 2010, but it's still in Windows for backwards compatibility reasons, and there are almost certainly still servers running today that a NTLM hash could get you access to. So that's my guess as to what they are targeting.
The login form of course used the entirety of the password, not truncating it. Fun stuff.
I found out I could just enter the first 20 characters and log in. I've had other websites that simply broke. The worst one had a password reset page that also didn't verify their own password length limits, sending me in a frustrating password change loop.
It also doesn't sanitise or warn about the password having impermissible characters that will mess up the user's account the SQL Server that backs GP. Then, after an admin tries to reset the user's password (typic'ly to something like "Password1!"), the user can log in with the insecure 'temporary' password as many times as they want, but cannot change to a new password. When the user tries, GP claims success and says to use the new password at next login…but when logging out announces that the password failed to change.
My interpretation is that the entire password is being verified, even though the backend is only ever verifying a sha 512 digest hash of it.
(Oh and why would you do this? To be able to support arbitrary length passwords without opening yourself up to ddos attacks. Support as long passwords as the user wants - only the digest hash is sent.)