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.
Comment on My password is not accepted because it is too long
foggy@lemmy.world 3 weeks ago
Okay so I agree with you that a longer password is better but this in no way indicates clear text password storage.
Kissaki@feddit.org 3 weeks ago
BestBouclettes@jlai.lu 3 weeks ago
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.
axh@lemmy.world 3 weeks ago
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.
Zikeji@programming.dev 3 weeks ago
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.
LouSlash@sh.itjust.works 3 weeks ago
Image
spankmonkey@lemmy.world 3 weeks ago
Oh look, a free account!
x00z@lemmy.world 3 weeks ago
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.
notquitetitan@sh.itjust.works 3 weeks ago
A reason reason to switch to argon :)
WhatAmLemmy@lemmy.world 3 weeks ago
To be fair, 24 is still a secure length for a password, and will probably be for another 5+ years.
Redjard@lemmy.dbzer0.com 3 weeks ago
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.
Ziglin@lemmy.world 2 weeks ago
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?
Redjard@lemmy.dbzer0.com 2 weeks ago
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.
AA5B@lemmy.world 3 weeks ago
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.