[jm_l]

Typically you store a hash of user passwords instead, then when logging in you hash the user password client-side and compare the hashes. This acts like a one-way function that protects the password while letting the user authenticate themselves.

[CyberLily]

Hashing passwords client-side is generally a bad idea, since it means that the hash effectively becomes the password. For example, if I have a database row that has the hash of the password and a bad-guy gets access to the database, they will get the hash. The benefit of a hash is that it is a one-way operation, I can't figure out the plaintext from the hash, so my account is safe. If the password is hashed on the client, and sent to the server the attacker doesn't need to reverse the hash, they can just send the hash in the request. Instead, you should send the password to the server (using TLS encryption) and do the hash and compare on the server.

[jmull]

You actually want to one-way passwords both client-side, for transport, and again server-side, for storage/comparison.

Otherwise, there's a hole, between the end of the TLS connection and where the server-side encryption happens, where the password is in plain text. Think logs and load-balancers and proxies.

While the client-side hashing doesn't help protect your site a lot (as you say, the hashed value the client sends effectively becomes the password), it helps protect the users who use the same password across multiple sites.

Notice in this case, that's exactly what the brothers are accused of doing: using credentials harvested from their site to log into other, potentially more lucrative accounts.

I didn't see if that's the hole the brothers exploited but it very well could have been.

The client-side encryption may have been all that was missing in this case.

[PunchyHamster]

If you're worried about MITM in the TLS web connection between client and server, you already lost and no prevention method client side will work, because if you own the connection you can just give client malicious JS to extract the password when they enter it

[fc417fc802]

Hashing client side is sufficient because the only service you can breach with the hash is the one you already had to breach in order to read the database.

Of course performing an additional server side hash on top of the client side one is good defense in depth because there's at least some chance that it might make things more difficult for a rogue insider and doing so costs approximately nothing. But it certainly isn't critical because by the time you're dealing with a rogue insider things are already looking quite bad.

[Tangurena2]

Also, you need to add salt. Otherwise every person using "Password123" has the exact same hash. Before they broke their search engine, it was common to google the MD5/MD4 hashes to "decrypt" or "unhash" them.

[necovek]

And rainbow tables appeared too.

[BrandoElFollito]

(I will be copy/paste this answer for the other comments)

My bad - I misread the post.

To clear things up: I am completely aware about how to store passwords in services that check against them. You are likely to have read some of my prose on that topic in OWASP or at a conference :)

My point, after misreading the article, was that in order to authenticate to a service (the one that holds the hashed version of that password) you need to have access to its cleartext version. This is VERY bad, should never be stored without special considerations etc.

I read the articlae as if they accessed the source of the passwords, the one used to access to services (a vault, with its encryption, access restrictions etc.). 5k was a lot but that could have been bearers or similar ones.

So my comment, and the comments to it, actually yelled at me (that's good!) the way I yell at actual implemententions sometimes :)

In all seriousness - thanks for the reaction, we need more of these. My next obsession are servies that require "only digits" or "strictly 8 to 11 chars" for credentials :)

[jmull]

People shouldn't be downvoting this...

Hashing client-side is a good idea. You must also hash server-side, for storage/comparison.

Otherwise, an insider may be able to harvest the original password, from logs, proxies, load balancers, etc. that requests pass through after the end of the TLS connection, on the way to the db.

They can then try the credentials on other, perhaps more lucrative sites. That's what the brothers are accused of doing here, so client-side hashing (or just simple encryption) may have been the missing piece of security that would have thwarted the credential stealing.

[necovek]

I wonder how common are setups where an internal person has access to the TLS private key part of the certificate or access to a network equipment that all traffic passes through, yet they cannot access the inputs required for hashing/encryption client-side?

This seems to mostly prevent accidental logging and is thus a matter of defense in depth, stopping malicious actors from exploiting it later — but an actively malicious IT person would not be deterred.

[jmull]

> This seems to mostly prevent accidental logging

Yes, and that's not uncommon, IME. There's generally a lot of logging that's at least potentially available, and it gets turned on, and the logs shared when there's a problem that needs to be fixed (especially when it needs to be fixed quickly, which is usual).

This is going to make more sense for "enterprise"-type deployments, where there's a significant distinction between the people who might have access to request logs at times, and the people who can push code to production.

[fc417fc802]

Yes limited protection against insiders is good defense in depth but not the primary purpose which is to protect end user accounts on other services in the event that you are breached.

[necovek]

My question still stands: how do you disallow cleartext password extraction if you are breached, assuming all your IT infrastructure and code is now accessible to an attacker?

I am talking about not logging them ever, using internal TLS and strong hashing in general, and wondering what exact value is added on top with client side hashing.

[fc417fc802]

There are substantial differences between database access, snooping the logs, internal (no TLS) wiretap, and full MITM of the frontend.

Hashing client side minimizes the risk of any blast radius exceeding the bounds of your own service. There's obviously no way to prevent an adversary who achieves full MITM from gradually harvesting credentials over time. The only solution there is to use keys instead of passwords.

[necovek]

We are not disagreeing, but I am not getting my answer: how is client side hashing really helping, what are the circumstances it helps with if you do have the basics right?

In your enumeration, what is breached for this to be meaningfully impactful for other services where customers might be reusing credentials?