In password security, the longer the better. With a password manager, using more than 24 characters is simple. Unless, of course, the secure password is not accepted due to its length. (In this case, through STOVE.)
Possibly indicating cleartext storage of a limited field (which is an absolute no-go), or suboptimal or lacking security practices.
Okay so I agree with you that a longer password is better but this in no way indicates clear text password storage.
Is the maximum 24 characters because their database column is a VARCHAR(24)? That’s one of the first questions that I thought of. Sure, it doesn’t guarantee plaintext, but it’s a indicator that it may be stored plaintext, considering hashing doesn’t care about length. Or at the very least whoever has had eyes on this code doesn’t know shit about security, which makes me less confident in the product as a whole.
The only reason I can think of to have a maximum would be to save on bandwidth and CPU cycles, and even then 24 characters is ridiculously stingy when the difference would be negligible.
Oh look, a free account!
bcrypt hashes only the first 72 bytes. 24 characters is the max amount of 4 byte UTF8 characters when using bcrypt. Which is stupid because UTF8 is variable, but still, it’s a possible explanation.
A good reason to switch to argon :)
To be fair, 24 is still a secure length for a password, and will probably be for another 5-10+ years.
Cryptographic hash functions actually have fixed runtime too, to avoid timing-based attacks.
So correct password implementations use the same storage and cpu-time regardless of the password.
I figured it was about the time spent transmitting. But the password should probably be hashed before sending as well as upon arrival at the server, correct?
It isn’t usually. If it was, the server-side function wouldn’t need a constant runtime at different-length inputs since the inputs would not have differing lengths.
The problem with client-side hashing is that it is very slow (client-side code is javascript (for the forseeable future unless compatibility is sacrificed)), unpredictable (many different browsers with differing feature-sets and bugs), and timing-based attacks could also be performed in the client by say a compromised browser-addon.
For transit a lot of packaging steps will round off transfer-sizes anyhow, you typically generate constant physical activity up to around 1kB. Ethernet MTU sits at ~1500 bytes for example, so a packet of 200 bytes with a 64 char password or a packet of 1400 bytes with a 1024 char password containing some emoji will time exactly identically in your local network.
I would have thought the opposite. I remember having a familiar conversation: “we need a sanity check in the password: what would no sane person do?” I believe we cut it off at 64 characters, but I can see someone thinking 24 is kore than enough, if they’ve never used a password generator.
It does. If you hash the user passwords, which you should, the hash is always the same length and it’s thus irrelevant how many characters the user’s password consists of.
Now, it’s not certain though, which wasn’t claimed either, because the front end developer might have other reasons for setting limits. The backend shouldn’t care though.
The backend should care though. Even if strings can have an unlimited amount of characters, you don’t want to go and hash a gigabyte of data. In lower level languages you don’t have magic strings either so you might do something like
char password[64].There’s many reasons to limit raw password length. Not many good ones to have it as small as 24 (or even 64) though.
There should be a limit. It should be so high that we never hear about it. 1MB for example.
Exactly. The tax on hashing the password can’t be ignored and if you’re doing this enough times it can kill a system. 24 characters is too low. I’d say 100 characters is enough for most use cases. 1024 if you’re feeling 1337.
Sure, but when we talk about the computation then the number of rounds is by far the more important factor compared to password length.
The discussion is about whether 24 characters indicate cleartext though - not whether password lengths should be in the gigabytes.
Seems reasonable.
I agree you might have threat actors looking to DoS your system if there’s a publicly exposed REST endpoint accepting gigabytes of data. That has nothing to do with the discussion on password hashing though.
The claim was that a limit on passwords implies plaintext storage. It doesn’t. There is no such thing as unlimited on computers.
quoting the post:
It was not a claim that it certainly is plaintext storage. It was claimed to be a possibility. AND provided an alternative explanation.
Maybe you’re more confident than me in good practices and implementations across all services. But I’ve seen enough to know that’s not always the case. It’s good to be skeptical on anything related to security.
No it doesn’t.
It does.
/80’s hacker turned Software Engineer turned Cybersecurity professional
Lmao.
As if my title isn’t almost exactly the same.
deleted by creator
Don’t worry, I’m autistic myself and understand how difficult it can be to parse “it’s thus irrelevant how many characters the user’s password consists of” to mean something besides “all implementations must accept an unlimited amount of characters”.
I do believe the point was understood by the general reader however.
What an awful thing to say. Go question your motives.
Curiousity: Could you please explain what was awful about the comment you responded to?
For context, I’m also autistic.
I don’t think I’m autistic but I am confused too :/
There is no good reason so send the passwors itself to the server. Send the hash and you will have a fixes length of data to send anyway.
And even if insist in sending the password over the wire, there is no problem on the backend to handle longer passwords than that, so that no one will run into a limit in practice. We’re talking about bytes here, not even a kb.
Proper hashing of a password includes a salt that should be kept private. This means the password should definitely be passed to the server in plaintext. The server adds the salt to the password, then hashes it.
This adds more protection should an attacker somehow manage to get access to your hashed passwords. Even if they identify the type of hashing mechanism used it will prevent the use of rainbow tables, dictionary attacks, etc. against the hashes.
If that were the case you could still hash it on the client side, forcing it to be a certain size and then hash it again on the server with the right salt. I don’t think there’s a real disadvantage to hashing a hash.
While I’m not arguing for doing the crypto client side, the salt isn’t needed to be private - only unique.
It definitely needs to be private. If an attacker can obtain both the password hashes and the salt(s) (via the same database vulnerability for example) then they have everything they need to run offline attacks against the passwords.
No, it most definitely does not need to be private. The idea with salt is to invalidate rainbow tables. If you’re “keeping it private” it’s just another password.
https://en.wikipedia.org/wiki/Salt_(cryptography)
The salt is specifically to invalidate pre-generated rainbow tables, and doesn’t need to be kept private. It only needs to be unique.
The attacker generates rainbow tables by running common passwords through known hashing algorithms. So I run “password1” through a bunch of different algorithms, and save the results of each. Notably, generating decently large rainbow tables takes a lot of time, processing power, and storage space. Because you don’t just use common passwords; You’re basically running a brute force/dictionary attack on your own computer’s hashing algorithm.
Now if a database is unsalted, I can search for matching results against my rainbow table. When I see a match, it tells me both which users had that password and which hashing algorithm they were using. So now I can narrow down my focus to only using that algorithm.
But if a database is salted, all of my pre-generated tables are useless. Even if someone used “password”, it won’t match my rainbow tables because the hash was actually fed “password{hash}” instead. And even if multiple users used “password”, each salt is unique, so I don’t see a bunch of repeated hashes (which would point to those accounts using the same password). I would now need to generate all new tables with the salts I stole in order for my rainbow tables to be usable again. And even then, I’d need to repeat that table generation for every user.
you absolutely should not be hashing client side. You need to securely transmit the password to the server where it is hashed. You do not want clients knowing /how/ the password is salted/hashed. this lowers your security overall.
If you’re doing hashing and salting on the client then yep it’s useless, no difference to just using a hash output as a password.
If on the other hand you’re doing a zero-knowledge password proof method then it’s quite secure. As the password is never transmitted over the network, not even the server knows what it is, but can still verify the user has the correct one.
There’s some software that hashes the password clientside before sending it, sure. But it still should be hashed serverside too.
If the server hashes a hash, the plaintext password’s length is still irrelevant
That’s not true. There’s limits everywhere.
At no point the server has to deal with the length of the plaintext
It could be an older codebase that’s using an inline encryption algorithm as opposed to a hash. Using an encryption algorithm with a private key would result in varying length outputs.
That’s the same as “cleartext” for someone who works in security though, since that means anyone with the private key can decrypt the password.
Password hashes always have the same length.
Why is there a limit at 24? It may be an arbitrary limit set, or it may be because they don’t store more.
What would be the other reason for a password length limit so low ? I could understand limiting to like 64 characters but 24 sounds low.
I heard some banks encrypt single characters of the password separately (no idea how that would be safe) they often ask to provide random characters from the password instead of the entire password.
My bank only accepts up to 20 characters. It doesn’t validate it… The login page simply ignores all characters beyond 20th. So I didn’t even know that it cut my password until I tried to log into the mobile app, which replaces the last character when you type more than 20… that was confusing 20 minutes when I didn’t know why I can’t log into my mobile app.