[coder543]

"Much" more time? Do you have any sources to back that up? Why is combining client-side and server-side hashing not commonly considered best practice if it's so great?

I don't agree at all. Login pages are static, since they don't need to be customized per user, because the users aren't logged in. Anyone could easily prepare a modified login page before compromising the underlying system, and swap it in immediately after compromise. The added implementation complexity for the original developer is simply security theater.

Client-side hashing of passwords is actually a dangerous thing to recommend, in my opinion, because a lot of developers would assume that it removes the need to also hash on the server-side. At which point, they would literally be storing the actual password in plaintext in their database, since the client-side hash is the password.

Client-side hashes also aren't going to have a per-user salt, which means that an attacker can just use a rainbow table to reverse the hash of most passwords... making it even less worthwhile. The attacker doesn't even need to change the served content, but they certainly can.

As I mentioned in my previous comment, and I will repeat it here, real benefit to authentication security only comes from adding 2FA or SSO. Don't waste your time on security theater.

[Dylan16807]

> As I mentioned in my previous comment, and I will repeat it here, real benefit to authentication security only comes from adding 2FA or SSO. Don't waste your time on security theater.

In theory there's also convincing browsers to implement a zero-knowledge protocol like SRP.

[coder543]

How is SRP materially better than WebAuthn, which is intended to be able to be used as a single factor authentication mechanism? (Unlike U2F)

If SRP depends on a user to choose a password or to enter it only on the correct website, then it will be substantially less secure than WebAuthn, because users pick bad passwords and phishing can be very effective. WebAuthn sidesteps both of these issues entirely.

[Dylan16807]

If you're using a different computer from normal, and don't have a hardware token or don't have it with you, you can't use WebAuthn.

When it comes to systems that have passwords, a zero knowledge protocol should be best at keeping it safe, and while moving password entry out of websites and into the browser isn't a great protection against phishing it's a lot better than nothing.

[coder543]

> If you're using a different computer from normal, and don't have a hardware token or don't have it with you, you can't use WebAuthn.

This applies to literally all authentication schemes that use something beyond a password, including TOTP and SMS codes. It’s also kinda the point. An attacker will have a much harder time impersonating you.

You can use WebAuthn with just the fingerprint reader on your laptop or smartphone, or FaceID on iPhone. You don’t need an external hardware token, but those do work as well. You might even be able to use WebAuthn with your computer’s TPM using just a PIN instead of biometrics, but I’ve never bothered to check, because I’ve never wanted to do it that way.

A password by itself isn’t good enough anymore, so your argument in favor of SRP isn’t convincing, and I’m sure this is why browsers have never bothered to implement it. Making passwords slightly better doesn’t even come close to fixing them.

[Dylan16807]

> This applies to literally all authentication schemes that use something beyond a password, including TOTP and SMS codes.

Yes, and?

It's still a "real benefit" to passwords if they can't be stolen.

Even if you do have an independent second factor, that means you still have a password. Surely you want to protect that password better, on top of the second factor?

[coder543]

WebAuthn is designed to be able to be used as a strong single factor. You do not need a password. It cannot be MITMed or phished or leaked by server compromise. See an example here: https://webauthn.io/

> It's still a "real benefit" to passwords if they can't be stolen.

SRP does not mean passwords can’t be stolen. It just means that the backend of a particular website is no longer capable of stealing the password, as long as the user is careful to only use their browser’s (currently nonexistent) SRP dialog box.

The user’s computer can still have a keylogger on it.

The user can still be phished.

> Surely you want to protect that password better, on top of the second factor?

No, I want passwords to just go away. They add extremely little security on average. Power users like us might use strong, unique passwords, but almost no one does that in the real world. Protecting the password “better” doesn’t matter when the user also uses that same, weak password on a dozen other websites already.

SRP does not solve the actual problems people are facing, which is surely why browsers don’t support it. It’s a cool idea (honestly!), but it’s a solution in search of a problem now that we have WebAuthn.

If SRP is so beneficial even today, why don’t browsers implement it? They implement so much other stuff. You’re implying quite a conspiracy, which doesn’t make sense when it “compromises” the security of passwords going to Google and Apple just as much as it does everyone else. The “real benefit” appears to be lacking.