If you hash the password on the client, then the hash essentially becomes the new password and you haven't solved anything. What you're looking for is a password authenticated key agreement in which one party authenticates to another without an eavesdropper learning any secret [1]. For whatever reason, no major websites use PAKEs today.

[1] https://blog.cryptographyengineering.com/2018/10/19/lets-tal...

I agree that it becomes the new password, but it prevents your own site becoming a contributor to credential stuffing attacks - if you don’t have the clear password transmitted to your systems, you can’t leak it accidentally in logs or through poor DB practices.

I wonder why PAKEs haven’t caught on?

Anything faster than bcrypt is practically clear text due to brute forcing, and running bcrypt inside the user interface is needlessly expensive. The common practice is to ensure that passwords are checked and discarded before they can be accidentally disclosed, or to avoid re-usable passwords altogether. Production logs should also only be accessible when there is a direct need. Sometimes this still fails, but it is relatively rare in well run sites.

The AWS Cognito User Pool Authentication Flow utilizes an augmented PAKE (SRP). I imagine there are a number of major sites that use Cognito along with the SRP auth flows baked into their std libs. I know I've used it a number of times.

I implemented SRP a decade ago — it has issues, and thus a lot of revisions. It also leaks your salt and you can’t use a pepper. There is Opaque (see the play on PAKE! but it’s new and difficult to search for).

But you have. It means even if you refuse your passwords elsewhere, only the website that was compromised is compromised.

You can (and should) store the salt server-side. Moving the hashing to the client does not solve anything.

Really, that should be a salted hadh to really defend against password reuse.

Blizzard Entertainment uses a PAKE implementation (SRP).

This article (somewhat ironically) talks about it:

https://arstechnica.com/information-technology/2012/08/hacke...

I don't know PAKE to know if this is equivalent to it, but you can use a timestamp + hash to avoid sending anything equivalent to a password. The caveat is your system needs to have the correct time set. But otherwise it works fine.

> why do clients still send passwords to a server? Doesn't it make more sense to hash the username and password together with some sort of nonce/salt that's sent to the server for validation?

You must ALWAYS hash the password (as a salted iterated cryptographic hash) on the server. You can in ADDITION also hash the password on the client end, but by itself that's not enough.

The issue, as usual, comes down to "what is the attack you're trying to thwart"? If you hash on the client and not the server, then when (not if) the attacker manages to download the hashed password set, the attacker can create a modified client & send those hashes directly. If you don't hash on the server, it's exactly the same as storing passwords as clear text, because you're storing the data that an attacker can directly use to log in.

You can also hash the password on the client IN ADDITION to the server. In that case, you're hiding from the server the actual password you type in. That's an improvement if you're sharing a single password across many services; in this case the attack you're trying to thwart is to prevent an attacker from actively capturing the password & trying to reuse the password on other systems. However, a much better idea is to not share a single password anyway, so it's not such a great thing.

Users reuse passwords. The main reason of not having your passwords in clear text is to protect them from that. At least when (not if as you noticed) your site is hacked (the same day this attacker download your password database probably), it has no other impact for your users that whatever can happen on your site (the attacker might be able to use the hashed passwords to log on your site but at this point you probably have bigger problems, given that someone is able to download your password database, and you are probably going to reset all those passwords anyway).

This comment is full of many inaccuracies. Leaked hashed passwords still pose a risk to users on their other accounts that may use the same password. Hashing passwords prevents internal abuse and makes your site a much less juicy target (in addition to making leaks less disastrous). It also makes timing attacks far less feasible by enabling reasonable constant time comparison of the hashed password.

I agree with what you are saying but I don't see how this conflicts to what I said.

That introduces additional complexity, and the password is already protected by https.

As others have pointed out, if you go for complexity, there are better schemes. However, by avoiding the complexity you keep simpler client side code.

Especially because this is standard, whilst doing extra stuff would involve doing your own crypto code.

The only thing that you nées is a hash fonction. I think thé added complexity ils negligible on any modern System.

Small tip: looking at the spelling errrors, I bet you're on mobile, and using the standard Google or iOS keyboard set to French. I constantly have to switch between English and my native language as well. But I found out that with Swiftkey (by Microsoft), you don't need to manually switch between two languages; you just configure two language at once and the software does autocorrect for both.

Complexity of the code base. The computation of hashes client side requires quite a bit of custom code. Sending a plain text password is build into the browser.

If you take your idea and step through the login//authentication process, you'll find that what you're suggesting isn't really all that different to what is done normally.

Overview, Scheme_0: - You send your unique identifier (email, username, etc) and password to the server in plaintext. - The server looks up the password hashing scheme and salt associated with your identifier - The server checks that salt+password+hashing scheme produce the stored hash - Server kicks back proper response

In your scenario, Scheme_1: - You prehash the password locally and send your identifier + prehashed_password to the server - The server looks up the password hashing scheme and salt associated with your identifier - The server checks that salt+prehashed_password+hashing scheme produce the stored hash - Server kicks back proper response

The only difference is the extra hashing step. From a security perspective, there is no gain; storing the prehashed_password from Scheme_1 in plaintext (e.g. logs) is no different than storing the password from Scheme_0 in plaintext.

The difference is that the password of scheme 0 is probably reused on many other websites. If for example you bcrypt the password client side, you at least don't have to deal with credentials that might work with all the other websites that your user is using.

How do you bcrypt at an appropriate difficulty client-side? Consider that it probably needs to work on a mid-range Android phone from years ago.

Password reuse on other sites is not your problem. It is your user's problem.

A fuck-you,-got-mine sort of approach to security doesn't work. It's everyone's problem.

PAKEs are probably a good idea across the board.

Take a look at SRP: https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...

No it doesn't. In your example, the hash of the password becomes the new password (I.e. the new secret). The nonce/salt adds no security because it must be open to anyone attempting to authenticate.

Surely it adds security in that an attacker cannot take that new password and use it on another site, even if the user re-used the underlying password?

Yes. It adds this feature. But only if you assume that the database was compromised or nefarious logging was enabled and no further access to the server was possible. Otherwise, the attacker can modify the JavaScript that is used by the client to perform the hashing (and remove/adjust the hashing function).

To be clear, it would have prevented these logged passwords from impacting other websites if the true cause of the Robin Hood password reset was a logging issue.

As a user, you can prevent this from happening either way by choosing strong, unique passwords for every service.

This is still a meaningful improvement because accidentally making everything world-readable is in many cases easier than accidentally making everything world-writable.

It’s not assuming that has happened, it’s acknowledging it could happen (or any other bug that reveals database field, e.g. sql injection). It seems like it should just be a default practice - generally I try to design systems to fail safe, regardless of what causes that failure.

some additional discussion: https://security.stackexchange.com/questions/53594/why-is-cl...

I've also wondered why this isn't more common.