19

I remember hearing before that it's a sign they are storing your info unencrypted but I never checked.

Is this true? I was logging into a .gov website and noticed it does that.

you are viewing a single comment's thread
view the rest of the comments
[-] hitmyspot@aussie.zone 1 points 9 hours ago

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? ;)

[-] p_consti@lemmy.world 1 points 9 hours ago

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).

[-] hitmyspot@aussie.zone 1 points 7 hours ago

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.

[-] p_consti@lemmy.world 1 points 7 hours ago* (last edited 7 hours ago)

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 doing password_from_client == password_from_db in 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.

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.

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.

this post was submitted on 08 Aug 2025
19 points (88.0% liked)

Cybersecurity

8013 readers
281 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

Community Rules

If you ask someone to hack your "friends" socials you're just going to get banned so don't do that.

Learn about hacking

Hack the Box

Try Hack Me

Pico Capture the flag

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