28
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 08 Aug 2025
28 points (88.9% liked)
Cybersecurity
8203 readers
226 users here now
c/cybersecurity is a community centered on the cybersecurity and information security profession. You can come here to discuss news, post something interesting, or just chat with others.
THE RULES
Instance Rules
- Be respectful. Everyone should feel welcome here.
- No bigotry - including racism, sexism, ableism, homophobia, transphobia, or xenophobia.
- No Ads / Spamming.
- No pornography.
Community Rules
- Idk, keep it semi-professional?
- Nothing illegal. We're all ethical here.
- Rules will be added/redefined as necessary.
If you ask someone to hack your "friends" socials you're just going to get banned so don't do that.
Learn about hacking
Other security-related communities !databreaches@lemmy.zip !netsec@lemmy.world !securitynews@infosec.pub !cybersecurity@infosec.pub !pulse_of_truth@infosec.pub
Notable mention to !cybersecuritymemes@lemmy.world
founded 2 years ago
MODERATORS
The client doesn't confirm the hash. The client hashes and sends the hashed data. The server confirms.
Omg, how do you know my login? ;)
The client doesn't hash. The client needs to send the plain text. Otherwise, that's a security problem; the server needs to confirm the user knows the actual password, so the server needs to compute the hash and compare. If the client sent the hash, then there was no reason to compute hashes in the first place, because the attacker can just send the leaked hash (the reason to hash it is to avoid that the leak can be used to log in directly).
No client side hashing is possible and secure.
If you look at sending plain text under SSL, it's almost the same thing.
The password hashed under a mutually known algorithm that is not reversible is just as good as the plaintext.
What's particularly interesting right now is manipulation of data that is encrypted to allow the same output (encrypted) as unencrypted data.
The point of sending hashes info from the client is that each site uses a different key, even if publicly available. This means that leaked login data cannot be compared or matched across different leaks.
No, it is not. If the server accepts the hash from an untrusted source (the client), then that's equivalent to not using hashes at all. The reason why we hash is so a database leak does not allow malicious actors to login directly. If the server accepts a hash, that means it only does
hash_from_client == hash_from_db, meaning that's the same as doingpassword_from_client == password_from_dbin terms of security. This is because the client can just send the hash from the DB, the user does not actually need to know the password, hence your proposal is equivalent to not using hashes at all in terms of security.That is for keyed hash functions, which is not typically done for passwords (but peppers are sometimes used, which helps similarly). This does not prevent the above scenario, though, because the leaked hash can still be used on that site. Sending hashes is a bad idea, the hash should always be computed in a trusted environment to ensure the user actually knows the password.
Not saying you're wrong, what you're saying makes sense, but my cryptology classes describes the stages of hashed authentication the way the guy you're replying to describes things (client sends hash of password, server compares hashes).
I'm not saying what I was taught (intro level cryptology) is correct, up to date, or into the technical weeds enough to distinguish, but can you provide a source that backs up your position?
I'm very interested in this discussion and I'd like to see an authoritative source. I can pull the book I am referencing if you'd like, let me know and I'll find it.
I would be very interested in that book. My university did not provide explicit book sources, so I can't tell you what that is based on, but here are the relevant slides (from page 9). Server-side hashing is so ubiquitous as the standard that e.g. OWASP cheat sheet doesn't even explicitly say it, but their recommendations hint at it.
A quick google search on the topic revealed others with the same opinion: stackoverflow stackoverflow. The second link (accepted answer in the same thread) argues that with a protocol around it, it can make sense, but never in the situation described here. There needs to be a meaningful computation on the server's side, otherwise the described scenario can happen.
It's a bit difficult to find papers on that because server-side hashing is standard, but here, for example, is a paper that explores client-side hashing (see the introduction with a reference to server-side hashing and section 2): Client Password Hashing paper. Very interesting is also section 3.4. Similar paper: Client-side hashing for efficient typo-tolerant password checkers. Essentially, both suggest that to avoid the described attack, both server-side and client-side hashing is necessary (but the server-side hash can be weaker), see "Authentication attacks after leaks". Neither paper describes how the client-side hashing is done on the Chinese websites they mention.
You'll also find that many frameworks (e.g. ASP.NET, Laravel) implement server-side hashing.
My conclusion from the little research I did after your prompt is that client-side hashing can work, but it's dangerous if done incorrectly (e.g. when done as suggested above), due to the scenario I described.
I appreciate your reply but I haven't had the time to go through your links. I just wanted to mention that I appreciate it and I'll reply in another comment when I get the chance to respond!