613
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 21 Aug 2024
613 points (98.0% liked)
Privacy
31796 readers
116 users here now
A place to discuss privacy and freedom in the digital world.
Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.
In this community everyone is welcome to post links and discuss topics related to privacy.
Some Rules
- Posting a link to a website containing tracking isn't great, if contents of the website are behind a paywall maybe copy them into the post
- Don't promote proprietary software
- Try to keep things on topic
- If you have a question, please try searching for previous discussions, maybe it has already been answered
- Reposts are fine, but should have at least a couple of weeks in between so that the post can reach a new audience
- Be nice :)
Related communities
Chat rooms
-
[Matrix/Element]Dead
much thanks to @gary_host_laptop for the logo design :)
founded 5 years ago
MODERATORS
This implies they're storing the plaintext password.
Ideally the password would be hashed with a salt and then stored. Then it's a fixed length field and it shouldn't matter how long the password is.
Or a very very old database system, possibly DB2, where you can't change the column limits or data types after the fact.
If they're hashing, the column size should be irrelevant. Ideally the database should never see the plaintext password in the first place (though I could understand calculating the hash in the query itself). If they're not hashing, they should really be rewriting their database anyway.
Salted passwords are not recommended anymore. Better to use a memory hard key derivation function designed for passwords, like Argon.
https://en.wikipedia.org/wiki/Argon2
Those are salted, they just do it for you.
Where does the salt get stored?
It's usually part of the string stored to the DB.
Edit: you can see the PHC spec here:
https://github.com/P-H-C/phc-string-format/blob/master/phc-sf-spec.md
Which is a common format for various password storage algorithms, including Argon2. It has a salt field.
I'd rather see a paper explaining the flaws with salted passwords rather than "just use this instead".
My initial reaction is that this overcomplicates things for the majority of use-cases, and has way more to configure correctly compared to something basic like a salted sha256/sha512 hash that you can write in any language's standard library.
If the database of everyone's salted password hashes gets leaked, this still gives everyone plenty of time to change passwords before anything has a chance of cracking them. (Unless you're about to drop some news on me about long time standard practices being fundamentally flawed)
Wut. Is the competition not enough data for you? This is how we got AES.
Can you name a single popular language where Argon2 isn't implemented in a stamdard library?
I think you're missing the point of what I'm asking. In what way are regular salted passwords insecure? Sure you can keep adding extra steps to encryption, but at a certain point you're just wasting CPU cycles.
I have no doubts about Argon2 being secure, I just think the extra steps are unnecessary for anything I would build (i.e. not touching financial transactions or people's SSNs). By design argon2 uses a lot of memory and CPU time to make bruteforce attacks much harder, but that's more of a downside when you're just doing basic account logins on a low end server.
I'll happily retract my point about external dependencies. It's available in most languages, and notably std C++ contains neither argon2 or sha256/512 hashing, so that kind of makes my original point invalid anyway.