[ceallen]

> if someone has backdoored your login server, it no longer matters if passwords are cleartext for the damage they'll do. The level of difficulty you introduce by having passwords hashed originally becomes moot at that point.

If your hacker has a cleartext password and their login ID (email address), you've just given the hacker access to a bunch of their other accounts on non-compromised sites (for the significant % of your userbase that recycles passwords). I think the possible collateral damage creates a far more severe worst-case scenario.

[mentat]

If they have access to your server they can inline javascript that will do the same thing on the client. The client is not secure, ever. If the users are reusing passwords, it's not something you can same them from except not saving the cleartext password yourself. Database attacks are different from on line interception.

[dsacco]

That's a fair point, though it doesn't outweigh the myriad other reasons not to do client-side hashing.

Security is always a battle of usability and tradeoffs. Client-side hashing simply doesn't make sense for security. It removes the fundamental point of the hash in the first place and introduces an avenue for possibly attacking or manipulating your database.

In fact, there's hardly ever a reason to do client-side security.

[mentat]

Perhaps you can quality "client-side security"? You mean never trust the client right?

[dsacco]

Yes, that's exactly what I mean. Treat all user-input (and by extension, client-side anything) as dangerous. A server putting a security protocol in the hands of the client when it is not unavoidable is usually bad.