114
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 30 May 2025
114 points (98.3% liked)
privacy
4345 readers
1 users here now
Big tech and governments are monitoring and recording your eating activities. c/Privacy provides tips and tricks to protect your privacy against global surveillance.
Partners:
- community.nicfab.it/c/privacy
founded 3 years ago
MODERATORS
It’s usually shoddy (or intended?) coding that only allows a 16 byte length for the password. One character equals one byte of memory so my guess is they only allocated 16 bytes of space for the password. The irony is NIST 2025 recommendations argue for AT LEAST 15 characters for passwords.
This is true for storing text in general but passwords aren't supposed to be stored as text, they should be hashed. The size of the hash will depend on the hashing algorithm. In other words, if there's a database limitation for the size of a password, it probably means they're storing the password plaintext 💀
More likely than not it's just some poorly designed validation
Yea, you are correct. The database size should be based on the hashing algorithm.
What's funny is a character isn't necessarily a byte now. It could be 1, 2, 3, or 4 bytes. Or only 2 or 4 bytes if we include utf-16 and 32. Character encodings are fun!
Guess how many systems 'with full unicode support' are broken by using emojis in your username or password...
Which is dumb because passwords should be treated as opaque bytes then salted and hashed. If your code breaks due to invalid unicode, your code is broken.
No. If you're salting and hashing your passwords, you're doing it wrong.
We have password specific memory hard functions like argon that you should be using
I've always wondered about Unicode normalization and passwords. I don't know a ton about it, but I think it's that things like
öand be represented as one character for the whole thing or two, one for the umlaut and another foro. That means that there are at least two sequences of code points that make the same... Glyph? I forget the word. The thing you see on the screen.Anyway, what if you have that
öin your password and one browser/keyboard/os/lovecraftian nightmare makes the mark one way and the other does it the other way? They aren't the same bytes. So they won't hash the same and you just can't tell why. Without digging super deep.There are standard ways to normalize the Unicode but I don't imagine most password systems use them. Maybe it's some intermediate layer. But I kind of doubt it. Those are complex, evolving standards.
Oh. And that "evolving" thing might make trouble for password systems. Are these standards backwards compatible in the way they'd need to be for a normalization upgrade not to break any passwords?
Oh God, what nightmare have I found?
I’m gonna add a 𓂸 to my password.
Better yet of you include users - there are so many lookalike characters (and the additionally all those diacritics to make more lookalikes) that look the same, so that a human most certainly can't/won't tell them apart, but that are completely different codepoints.
I � Unicode!