Comment by fc417fc802
16 hours ago
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.
16 hours ago
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.
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.
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.
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?
3 replies →