[ikeboy]

>Since the resulting hash must be deterministic, you can't use a salt

You can as long as it stays the same over time. Either lookup salt by username (requires an extra call back and forth) or use a single salt for the whole site, or actually you could have the salt deterministically depend on the username. All of those defeat hash tables.

I agree that the password length problem is not a great benefit, but the benefit that the server never sees the plaintext is pretty good in my eyes.

Logins take longer: a single hash+salt won't make a big difference even on low end devices.

Javascript: fair point, although plenty of sites require it for signing in anyway. I suppose you could make it optional.

Complexity of code: if it's in a library and vetted this doesn't matter as much. Conceptually this is pretty simple, would probably be 3-5 lines of code (2 lines to hash, 2 lines to generate salt from username).

[tokenizerrr]

> You can as long as it stays the same over time. Either lookup salt by username (requires an extra call back and forth) or use a single salt for the whole site, or actually you could have the salt deterministically depend on the username. All of those defeat hash tables.

And here you just answered your initial point.

> If the salt changes, you'd need to compute the password using multiple salts, which might have crypto guarantee issues when sent to the server.

[ikeboy]

If you're using different salts for each password and sending them from the server each time (the first option above), then my point still applies: the client would need to send the same password hashed to different salts, which may weaken security guarantees. (I don't know if any hash algorithms could be exploited using this, though.)