Anytime you see a password length cap you know they are not following current security standards. If they aren’t following them for something so simple and visible, you’d better believe it’s a rat infested pile of hot garbage under the hood.
I was incorrect but I still disagree with you. The hashing function is not designed to be resource intensive but to have a controlled cost. Key stretching by adding rounds repeats the controlled cost to make computing the final hash more expensive but the message length passed to the function isn’t really an issue. After the first round it doesn’t matter if the message length was 10, 128, or 1024 bytes because each round after is only getting exactly the number of bytes the one way hash outputs.
Yes, a hashing function is designed to be resource intensive, since that’s what makes it hard to brute force. No, a hashing function isn’t designed to be infinitely expensive, because that would be insane. Yes, it’s still a bad thing to provide somebody with a force multiplier like that if they want to run a denial-of-service.
I’m a bit behind on password specific hashing techniques. Thanks for the education.
My background more in general purpose one way hashing functions where we want to be able to calculate hashes quickly, without collisions, and using a consistent amount of resources.
If the goal is to be resource intensive why don’t modern hashing functions designed to use more resources? What’s the technical problem keeping Argon2 from being designed to eat even more cycles?
Argon2 has parameters that allow you to specify the execution time, the memory required, and the degree of parallelism.
But at a certain point you get diminishing returns and you’re just wasting resources. It seems like a similar question to why not just use massive encryption keys.
Are you saying that any site which does not allow a 27 yobibyte long password is not following current security standards?
I think a 128 character cap is a very reasonable compromise between security and sanity.
At my job they just forced me to use a minimum 15-character password. Apparently my password got compromised, or at least that was someone’s speculation because apparently not everyone is required to have a 15-char password.
My job is retail, and I type my password about 50 times a day in the open, while customers and coworkers and security cameras are watching me.
I honestly don’t know how I’m expected to keep my password secure in these circumstances. We should have physical keys or biometrics for this. Passwords are only useful when you enter them in private.
Yeah you should have a key card. Like not even from a security perspective but from an efficiency one. Tap a keycard somewhere that would be easily seen if an unauthorized person were to even touch or even swipe it if need be. I’m sick and tired of passwords at workplaces when they can be helped
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.
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).
Anytime you see a password length cap you know they are not following current security standards. If they aren’t following them for something so simple and visible, you’d better believe it’s a rat infested pile of hot garbage under the hood.
you have to limit it somewhere or you’re opening yourself up for a DoS attack
Edited to remove untrue information. Thanks for the corrections everyone.
Incorrect.
They’re designed to be resource intensive to calculate to make them harder to brute force, and impossible to reverse.
I was incorrect but I still disagree with you. The hashing function is not designed to be resource intensive but to have a controlled cost. Key stretching by adding rounds repeats the controlled cost to make computing the final hash more expensive but the message length passed to the function isn’t really an issue. After the first round it doesn’t matter if the message length was 10, 128, or 1024 bytes because each round after is only getting exactly the number of bytes the one way hash outputs.
It depends on the hash. E.g., OWASP only recommends 2 iterations of Argon2id as a minimum.
Yes, a hashing function is designed to be resource intensive, since that’s what makes it hard to brute force. No, a hashing function isn’t designed to be infinitely expensive, because that would be insane. Yes, it’s still a bad thing to provide somebody with a force multiplier like that if they want to run a denial-of-service.
I’m a bit behind on password specific hashing techniques. Thanks for the education.
My background more in general purpose one way hashing functions where we want to be able to calculate hashes quickly, without collisions, and using a consistent amount of resources.
If the goal is to be resource intensive why don’t modern hashing functions designed to use more resources? What’s the technical problem keeping Argon2 from being designed to eat even more cycles?
Argon2 has parameters that allow you to specify the execution time, the memory required, and the degree of parallelism.
But at a certain point you get diminishing returns and you’re just wasting resources. It seems like a similar question to why not just use massive encryption keys.
See “Password Hashing” here: https://en.m.wikipedia.org/wiki/Key_derivation_function
It is actually important to have a controlled cost to calculate in the forward direction too.
Hashes are one way functions. You can’t get from hash back to input
Only if the hash function is designed well
True. I was all kinds of incorrect in my hasty typing. I’ll update it to be less wrong.
Are you saying that any site which does not allow a 27 yobibyte long password is not following current security standards?
I think a 128 character cap is a very reasonable compromise between security and sanity.
Atleast this is reasonable, I have seen some website don’t allow more than 6 character.
At my job they just forced me to use a minimum 15-character password. Apparently my password got compromised, or at least that was someone’s speculation because apparently not everyone is required to have a 15-char password.
My job is retail, and I type my password about 50 times a day in the open, while customers and coworkers and security cameras are watching me.
I honestly don’t know how I’m expected to keep my password secure in these circumstances. We should have physical keys or biometrics for this. Passwords are only useful when you enter them in private.
Yeah you should have a key card. Like not even from a security perspective but from an efficiency one. Tap a keycard somewhere that would be easily seen if an unauthorized person were to even touch or even swipe it if need be. I’m sick and tired of passwords at workplaces when they can be helped
Ask your boss to get you a yubikey
At least it’s 128
I had a phone carrier that changed from a pin to a “password” but it couldn’t be more than 4 characters
my bank…
That’s too many characters
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.
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
[This comment has been deleted by an automated system]