In theory yes. But in practice the DB will almost always have some cap on the field length. They could just be exposing that all the way forward. Especially depending on their infastructure it could very well be that whatever modeling system they use is tightly integrated with their form generation too. So the dev (junior or otherwise) thought it would be a good idea to be explicit about the requirement
That said, you are right that this is still wrong. They should use something with a large enough cap that it doesnāt matter and also remove the copy telling the use what that cap is
Right but that puts a limit on the hash algorithmās input length. After a certain length you canāt guarantee a lack of collisions.
Of course the probability stays low, but at a certain point it becomes possible.
Collisions have always been a low concern. If, for arguments sake, I.hate.password. had a collision with another random password like kag63!gskfh-$93+"ja the odds of the collision password being cracked would be virtually non-existent. Itās not a statistically probable occurrence to be worried about.
This is plainly false. Hash collisions arenāt more likely for longer passwords and thereās no guarantee there arenāt collisions for inputs smaller than the hash size. The way secure hashing algorithms avoid collisions is by making them astronomically unlikely and that doesnāt change for longer inputs.
You misunderstand the issue. The length of the password should not have any effect on the size of the database field. The fact that it apparently does is a huge red flag. You hash the password and store the hash in the db. For example, a sha256 hash is always 32 bytes long, no matter how much data you feed into it (btw, donāt use sha256 to hash passwords, it was just an example. Itās not a suitable password hashing algorithm as itās not slow enough).
