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, as evidenced here.
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
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.
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
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.
Not true. Password hashing algorithms should be resource intensive enough to prevent brute force calculation from being a viable route. This is why bcrypt stores a salt, a hash, and the current number of rounds. That number of rounds should increase as CPUs get faster to prevent older hashes from existing in the wild which can be more effectively broken by newer CPUs.
I was incorrect about the goal being minimal resources. I should have written that that goal was to have controlled resource usage. The salt does not increase the expense of the the hash function. Key stretching techniques like adding rounds increase the expense to reach the final hash output but does not increase the expense of the hash function. High password length allowances of several thousand characters should not lead to a denial of service attack but they don’t materially increase security after a certain length either.
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, as evidenced here.
[This comment has been deleted by an automated system]
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
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.
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.
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 have to limit it somewhere or you’re opening yourself up for a DoS attack
password hashing algorithms are literally designed to be resource intensive
Edited to remove untrue information. Thanks for the corrections everyone.
Not true. Password hashing algorithms should be resource intensive enough to prevent brute force calculation from being a viable route. This is why bcrypt stores a salt, a hash, and the current number of rounds. That number of rounds should increase as CPUs get faster to prevent older hashes from existing in the wild which can be more effectively broken by newer CPUs.
I was incorrect about the goal being minimal resources. I should have written that that goal was to have controlled resource usage. The salt does not increase the expense of the the hash function. Key stretching techniques like adding rounds increase the expense to reach the final hash output but does not increase the expense of the hash function. High password length allowances of several thousand characters should not lead to a denial of service attack but they don’t materially increase security after a certain length either.
Hashes are one way functions. You can’t get from hash back to input
True. I was all kinds of incorrect in my hasty typing. I’ll update it to be less wrong.