i vs L strikes again
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.
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.
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).
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.
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.
Incorrect.
They’re designed to be resource intensive to calculate to make them harder to brute force, and impossible to reverse.
Some literally have a parameter which acts as a sliding scale for how difficult they are to calculate, so that you can increase security as hardware power advances.
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.
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
Atleast this is reasonable, I have seen some website don’t allow more than 6 character.
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
Yikes… This thread is a wasteland of misinformation and mininformers arguing with other mininformers about who’s misinformation is less ill informed.
This thread is:
- 50% technology illiteracy
- 25% Dunning Kruger valley
- 10% Actual knowledge
- Everyone else just here for the ride
Seems like they don’t consider a period to be a “special character”
That’s not the issue here as the special character check passes. It’s the validation between the two fields that’s broken.
Most probably not broken at all.
I.hate.password.
l.hate.password.
The first is a capital i, the second is a lower case L.
OP here, reading all the comments and theories as to why the I or L or whatever isn’t a match. I copy and pasted it after it didn’t like my typing skills, tried it twice and no go… I believe the periods aren’t an acceptable special character even though they technically are. It also would not accept spaces in-between words, I was first gonna use “I hate password” for my password but no go there.
The password it accepted was weak AF, two “stupid-words” strung together.
No, one is an uppercase “I” while the other is a lowercase “L.” lI — you can see the difference when you compare it to the nearby “h.”
I know this a a joke, but please use a password manager, it is such a game changer.
Bitwarden is free and E2E encrypted and if you want additonal feature, they only cost 10 bucks pre year. You can even use it with anonaddy to hide your email, which is also totally free and open source.
I’m already using Bitwarden but I hadn’t heard about anonaddy, thanks for the tip!
They work like a miracle together https://bitwarden.com/blog/add-privacy-and-security-using-email-aliases-with-bitwarden/
What is even more surprising is that even the free tier is perfectly usable, but consider paying if you have the money to support them.
What are those premium features? I never felt like I was missing something from the free bitwarden
2FA one time code was the reason I got premium (and obviously support FOSS project). It is a slight security downgrade, but a whole lot of QOL upgrade.
I also imagine hardware key support like yubikey would be very appealing for many.
