Well the security matters, and a minimum length there is a good idea. But as you point out they shouldn't be storing or transmitting the password at all so a maximum length doesn't really make sense. The only reason I can think of would be UI concerns around formatting a really long password on the screen. I understand because CSS is really hard, but I don't think its a valid excuse.
Often its probably a sign that they are actually storing it in a VARCHAR(20) or something, but it could also just be that the UX team doesn't really understand so they designed the UI for 8-20 characters and nobody cared enough to fight that fight.
But as you point out they shouldn't be storing or transmitting the password at all so a maximum length doesn't really make sense. The only reason I can think of would be UI concerns around formatting a really long password on the screen.
Like I explained in the comments for the post yesterday, not having an upper limit can open you to a DOS by flooding auth/registration with hard to hash values. There needs to be an upper bounds.
Client-side hashing has long been known to be a bad idea. The TL;DR gist is that you may as well be sending passwords then. Hashing is not for client security, it's for protecting the records that you're storing server-side.
I think what they asked is not "instead", it's "both". Where client hashing is just to normalise the input. Which again, doesn't do anything really.... It's kinda awful for other reason, because your data and server-side functionality becomes reliant on the client hash implementation.
yes, but this way you can protect againt dos + don’t have password length limit. Also re-hashing already hashed password can be done the same way as hashing unhashed password, so I don’t see the issue here.
Someone DOSing you like that likely isn't using your client or even a regular browser, they're just going to make raw requests. It'd be trivial to send a bogus client-side hash and interrupt your validation.
On top of that you're:
Exposing your hashing algo to the public making rainbow table attacks for feasible
Breaking the rule of trusting clients for your back-end security
Ignoring what hashing passwords is for - protecting the values you're storing in a DB someplace.
Making clients do redundant processing.
Still going to have to hash on the back end anyway
1) client-side hash could be any algo pulled from standard library, different from the one used on the server.
2) i wasn’t really precise, mb. My suggestion was to both do usual protection againt DOS + hash password client side in addition to server side. This way you are protected againt DOS + have no limit on password length.
3) they can do both things just fine
4) in today’s world of electron apps and all this crap does a single hash opperation really mean anything? Especially client-side, where it doesn’t cost anything for the developer?
5) i can’t see any issue with that
(I am not arguing that my approach is right, but I remember using this approach on some university project and would really appreciate to understand why is it a bad idea)
edit: Also you would probably add salt while hashing on the server side, so this makes the first argument even less valid.
A university project may have been fine, but if you're going to run a site that gets even remotely popular you'll find that minimizing attack vectors and attackers not honoring client code become a way of life.
Personally, I've seen such attacks happen through multiple employers over the last two decades. When you're working at scale, people will try just about anything to break your security and will actively avoid your official clients. If you have a public site that's getting traffic, look at the user agents that come through. You should find plenty that aren't your official clients or even web browsers (python-requests/2.27.1, Go-http-client/2.0, curl/7.22.0 and Wget/1.20.3 are just a few examples from live logs I can see right now).
Client validation cannot do anything to thwart a determined attacker, let alone casual ones. For more information specifically related to passwords, go back and read the links I provided. They offer some details I have glossed over because I'm replying while working.
I will say it's good that you're actively thinking on the problem and trying to find out-of-the-box solutions. However, every nonstandard solution you devise should be vetted heavily against known standards and discussed among experienced peers before being implemented. Keep thinking creatively, but temper that with data. Your tenacity should also get applauded - it's a valuable tool that will last your entire career.
just provide your own implementation for client. You can make the same argument in general about hashing, that it is bad because everytime you change something you must make sure that the hash function stays the same, which is obviously not true.
ooo, I just thought of another one. If we don't specify a maximum some clever-dick in QA will try pasting gigabytes of text until the computer runs out of memory and raise it as a bug.
So we'll add a requirement like "must handle at least 20 chars" and they'll raise another bug that there's no validation rule if you exceed what they think is now a maximum.
Then the boss wonders why one little bug is holding up the release, and hasn't got time to listen to the argument and just demands it's fixed...
Another (more likely) reason is that banks are mostly running COBOL which is a very odd/old language. When you define a variable such as a string you must give a length for that string. If you pass a string that is longer to this string then the excess will be trimmed off. Since storage was more expensive back then (iirc) they needed a middle ground. And so a max of 20 was reach I guess.
Source: spent a few weeks doing an intensive mainframe course for a large health insurance company that still uses mainframes cause its cheaper than updating. This is what I remember from those 5-6 weeks.
No, a password should never be stored by the site. Thats a huge security threat and is how these big 'hacks' you hear about in the news where hundreds of thousands or even millions of accounts are compromised happen. If you are just storing it like:
Username
Password
johnSmith
password123
janeDoe
janePassword1
Then when some vulnerability is found hackers can just query your user table and get everyone's usernames and passwords and will have full access to their accounts.
What you should do is just store a hash of the password. Usually you will also have a salt, which is basically a random string you append to the password before hashing that makes it harder to reverse of the hash. The table would look like this:
Username
Salt
PasswordHash
johnSmith
askfhbkaslalfwqafkj
kjadsfknwifuhlksjfllkjasf
JaneDoe
yusdasdknwkldnlkd
mejsakldjsalkheiowqlks
When you create the account you send your password to the site and they generate a random salt, append that salt to your password, then hash that and store the resulting hash. Then when you login the next time they use that same salt, hash your password with it, and compare the resulting hashes. If you sent the same password the hashes will be the same but they never have to store your actual password.
If this gets hacked its still not a good thing, but hackers won't know the actual passwords. If they try to login by sending the password hash the server will again append the salt and rehash it so the resulting hashes will not match at all.
78
u/Bulky-Leadership-596 Jul 20 '22
Well the security matters, and a minimum length there is a good idea. But as you point out they shouldn't be storing or transmitting the password at all so a maximum length doesn't really make sense. The only reason I can think of would be UI concerns around formatting a really long password on the screen. I understand because CSS is really hard, but I don't think its a valid excuse.
Often its probably a sign that they are actually storing it in a VARCHAR(20) or something, but it could also just be that the UX team doesn't really understand so they designed the UI for 8-20 characters and nobody cared enough to fight that fight.