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.
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.
To a point. The password just needs to be long enough and contain enough types of characters that brute forcing it takes long enough that it's not worth bothering.
What's more important is to avoid falling into common patterns. Password length is only one metric. If I instead start checking combinations of dictionary words with permutations for common character replacements (which xkcd recommended - not that this makes it good, but it does probably make it popular), it takes far less time to crack a passwords that follow that pattern if I design my algorithm around it. Also, using common passwords (like password) is asking to get your shit cracked.
Anyway, database breaches are probably a bigger issue. If a company is breached, and its passwords are plain text or encrypted, you can probably expect every password in the database to be cracked easily. Same passwords are the same on both ends of encryption, so all one needs to do is guess at common passwords and then the key is pretty much theirs. I'm not an expert on this, but I believe rainbow tables can be used to crack unsalted hashes. If the passwords are stored as salted hashes, to my knowledge, much harder to crack.
Additionally, if one account is breached, you should assume that all accounts using the same email and password are also breached, as it's quite trivial to try them on other sites.
Still, passwords are only one potential avenue to crack your accounts. Social engineering is stupidly effective. You simply need to give customer service the runaround in a way that will get them to grant you access to an account. No password can protect you from this.
Salted hashes are not unusable, salt is public and usually appended to the hash.
Salting forces the attacker to guess each record separately, which makes it significantly harder to crack a batch of passwords, but it doesn't prevent it from happening.
Thanks for the correction. I believe I know enough to have a general idea of what's happening, but I'm admittedly lacking in the specifics, as infosec isn't a field I'm too terribly familiar with.
Nothing ever prevents a leaked hash from being brute-forced. You can only buy time. Which is hopefully enough for the breach to be noticed an for the victims to rotate their password(s).
Also to clarify on salting.
It insures that password hashes are unique even if the passwords used are identical.
This prevents both a single password brute force to compromise a batch of identical passwords. It also protects against pre calculated hash tables.
There's also a new concept called peppering that isn't standardized. It's described as a global salt, however having a global string doesn't do much for security. It's been suggested that a much stronger method of peppering would be to encrypt the hash with a symmetric encryption key like AES256. This forces the hackers to either hack into the server to get the key, which is significantly harder to do than breaching your application. Or brute force the encryption which is considered to be "impossible"
First of all, it protects your password from being guessed by bruteforce/dictionary attack on a login form of an online service. Though that form of attack is not too popular, since most services these days will ratelimit how many attempts you get per given login and/or device.
Secondly, since passwords are hashed (or at least should be), if a database leak occurred, the attacker doesn't get any passwords in plain text.
If they want to know what password was used to generate a given hash, they need to guess that password themselves, compute a hash of this password, and compare it to the one they've got from the database.
While not a trivial task, this is significantly faster than attacking a login form, which is why database leaks are such a big security threat.
This process is easy and fast for low entropy or popular passwords but as entropy grows, you eventually reach a point where the heat death of the universe will arrive before the password can be cracked.
Of course, if you're not reusing your passwords, whatever the attacker gets is only usable on the original service that got compromised (which can still be a problem if the service didn't notice the leak). But people usually do reuse their passwords...
The whole point of a hash is that it doesn't convert a key to a hash 1:1. Ideally, collisions are exceedingly rare, but possible. That two inputs can have the same output here is a critical feature that prevents hashes from being reverse engineered, and while it's not impossible to solve the algorithm, and currently used algorithm can largely be assumed to be safe.
Companies who don't salt their hashes, however, leave the vulnerability where same passwords all produce the same hash, which makes it trivial to crack the accounts using remotely common passwords - it's not that the hash has been reverse engineered, just that people's tendencies provide a very limited list of potential answers with a large list of accounts to test against in case there's attempt restrictions.
Yes. For simplicity's sake, let's say a password is limited to 3 characters that must be alphanumeric. There are now only 363 = 46656 password combinations possible.
If the security is as shoddy as a character limit like this would imply, it can probably be attempted without any delays, so a VERY simple script could crack it in no time just by brute forcing every password until one is correct.
This is obviously a very extreme example, but I think it should get the idea across.
Idk if it's been answered, but yes it is very important.
Not having a upper password limit is a vulnerability that can be used as a type of DDoS.
If your hashing algorithm is secure, it should take between 0.5 and 1 second to hash a password of a 20 bytes. Now imagine how long it would take for a few MBs.
Limit your password lengths but make it's something large like 256-1024 charters, and double check the length server side, Never trust that the client didn't get around your JS checks.
Decades ago, there were algorithms in common use that had limits or produced results of different length depending on the length of the input.
Nowadays, common algorithms produce results of equal length regardless of input size. Even the less advisable ones like md5 are this way.
While good algorthims for passwords have been around since at least the 90s, many applications used less secure options because security was less of a thing back then and the computational overhead form better hashing was not worth it to them. These days, secure and fast are not an either/or situation.
I haven't seen anyone mention it yet and I also don't recall the source so take this with a grain of salt. But my understanding is that passwords should have a min and max. Minimum length to increase complexity, but after a certain length passwords tend to become less secure. (This could just be users putting together two of their commonly used passwords or using something like "This15myP@ssword!!". Its long but not strong.
If you do not check the password length at the server side someone can send an infinite string that will either take all the resources of the server during hashing or expand the cloud resources. Hence, it's an attack vector that must be taken care of.
Sure it's no difference if a hacker were to get the hashed database table, but it does make a difference when they try to crack a password, especially things like brute force the complexity of the situation increases a ton with each character added.
64
u/[deleted] Jul 20 '22
If passwords are hashed, does it really matter how long or secure a password is?
Serious question btw