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
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).
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
Hashing will make every password the same length.
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.
yup yup. Forgot we were talking about a protected field and not just raw data
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).
ur absolutely right. Idk why I was thinking about it like a normal text/char field