this post was submitted on 17 May 2025
29 points (100.0% liked)
Mildly Infuriating
41039 readers
233 users here now
Home to all things "Mildly Infuriating"
Not infuriating, not enraging. Mildly Infuriating. All posts should reflect that.
I want my day mildly ruined, not completely ruined.
Please remember to refrain from reposting old content. If you post a post from reddit it is good practice to include a link and credit the OP. I'm not about stealing content!
It's just good to get something in this website for casual viewing whilst refreshing original content is added overtime.
Rules:
1. Be Respectful
Refrain from using harmful language pertaining to a protected characteristic: e.g. race, gender, sexuality, disability or religion.
Refrain from being argumentative when responding or commenting to posts/replies. Personal attacks are not welcome here.
...
2. No Illegal Content
Content that violates the law. Any post/comment found to be in breach of common law will be removed and given to the authorities if required.
That means:
-No promoting violence/threats against any individuals
-No CSA content or Revenge Porn
-No sharing private/personal information (Doxxing)
...
3. No Spam
Posting the same post, no matter the intent is against the rules.
-If you have posted content, please refrain from re-posting said content within this community.
-Do not spam posts with intent to harass, annoy, bully, advertise, scam or harm this community.
-No posting Scams/Advertisements/Phishing Links/IP Grabbers
-No Bots, Bots will be banned from the community.
...
4. No Porn/Explicit
Content
-Do not post explicit content. Lemmy.World is not the instance for NSFW content.
-Do not post Gore or Shock Content.
...
5. No Enciting Harassment,
Brigading, Doxxing or Witch Hunts
-Do not Brigade other Communities
-No calls to action against other communities/users within Lemmy or outside of Lemmy.
-No Witch Hunts against users/communities.
-No content that harasses members within or outside of the community.
...
6. NSFW should be behind NSFW tags.
-Content that is NSFW should be behind NSFW tags.
-Content that might be distressing should be kept behind NSFW tags.
...
7. Content should match the theme of this community.
-Content should be Mildly infuriating.
-The Community !actuallyinfuriating has been born so that's where you should post the big stuff.
...
8. Reposting of Reddit content is permitted, try to credit the OC.
-Please consider crediting the OC when reposting content. A name of the user or a link to the original post is sufficient.
...
...
Also check out:
Partnered Communities:
1.Lemmy Review
2.Lemmy Be Wholesome
3.Lemmy Shitpost
4.No Stupid Questions
5.You Should Know
6.Credible Defense
Reach out to LillianVS for inclusion on the sidebar.
All communities included on the sidebar are to be made in compliance with the instance rules.
founded 2 years ago
MODERATORS
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.
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.
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.
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.
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.
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.
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.
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
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)
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.