4 ms·
The server does have to have access to the plain text password in memory, you know. I don't see why you think it's worth sacrificing guarantees of password stre
by adrusi 10y ago
The server does have to have access to the plain text password in memory, you know. I don't see why you think it's worth sacrificing guarantees of password strength to uphold some kind of taboo.
- arielb1 10y agoNo it doesn't. You can perform the first pass of salted hashing on the client-side. This should not harm security, but it can improve it if someone on the datapath is logging requests but does not alter them.
- warfangle 10y agoIsn't that what SSL does? And if the SSL between you and the destination is compromised, you don't even know if the hashing algorithm you asked the client to use is actually the one they used.
- Bartweiss 10y agoYep. And importantly, SSL is securing more than just the password - if you just salt + hash client side, then anyone watching gets to do a replay on that value instead of the original.
- Xylakant 10y agoso you just replaced the password with another secret, the hashed password. An attacker would now not need to gain access to the original password, but needs the hashed password - which will be logged just like the PW. The only security benefit is that it offers a bit of support for those that are reusing passwords since it doesn't expose the plain text.
- Filligree 10y agoMost people reuse passwords, so that isn't a trivial benefit.
- zeveb 10y ago> You can perform the first pass of salted hashing on the client-side. Not really. JavaScript crypto is fundamentally broken: an attacker, malicious server or disgruntled employee can replace server-side JavaScript and remove the client-side hashing at any time. This is, notably, why Firefox Accounts are completely and totally insecure (and hence why Sync is unsuitable for storing any private data at all).