My suspicion is this to rule out a specific hash. One well known to everyone interested in computer security back in the 1990's. One that haunts our nightmares to this day.
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.
It predates bcrypt by quite a bit - descrypt would truncate password at 8 characters (or technically 8 bytes) and was used on a lot of older Linux and *NIX systems.
Ran into this exact issue on a project. The developer that implemented the solution wanted to make sure that we handled those 6 digit PINs in the most secure way with salt and pepper and bcrypt, and at the end of the day the system only actually checked the first two digits of the PIN because bcrypt ignored the rest.
Still a problem irrespective of algorithms used. I recently set up an account on a website, letting my password manager do its thing. Couldn’t log in. Turns out the password was too long (20 chars when 16 were allowed) and was silently truncated during signup.
The login form of course used the entirety of the password, not truncating it. Fun stuff.
Similar problem with Microsoft Dynamics Great Plains. I think the save-password window accepts more characters than get stored, so trying to log with the seemingly correct password a few times gets you locked out.
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.
I ran into that with Paypal. Login limited my password length to something small (I think 20 characters?) but the signup page accepted my random 32 characters just fine.
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.
Does this permit taking a sha 512 digest hash of the user input and returning that digest hash to the backend for proper password hashing?
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.)
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.