[kerkeslager]

I think the only way this can happen is zero-knowledge password proofs, i.e. browsers implement a mechanism by which password fields submit a proof that the user has the password, rather than submitting the password. This way the server can only verify the password if they've implemented the proof system correctly, and they can't leak the password because they've never had it.

The basic idea is, the server gives a unique nonce with the password form. The user enters their password. On form submit, the browser stretches the key space of the password using a slow hash, then uses the digest to generate an asymmetric key via a referentially transparent algorithm (no random salts). Then the browser prepends the URL (obtained from HTTPS) to the given nonce (to prevent man in the middle attacks). The browser then checks to see if it has seen this nonce before and displays an error if it has (to prevent replay attacks--this forces servers to generate new nonces, although the browser can't force them to verify that the nonce that is signed later is the same one they sent). Finally the browser uses the key to sign the nonce, and sends the signature to the server. The server uses the public key (which was generated in the same way and given to the server at sign-up) to verify that the user has the password.

[joegosse]

I love the idea of zero-knowledge password proofs. Others can chime in on the approach you've proposed, but I have a more practical concern about developing critical mass.

How do you break through the chicken and egg problem of not enough users using or not enough browsers supporting this capability?

[kerkeslager]

If it's a field on inputs of type password, all you'd get is something like:

<input type='password' password-nonce='42'></input>

Browsers that support the password-nonce argument sign as I described. Browsers that don't support it pass through the password and the server performs the ZKPP key generation (this is no worse than the current system of hashing passwords). So servers can implement this immediately without worrying about breaking in non-supporting browsers.

After adoption by a few major sites, browsers can add a warning that the server didn't send a password nonce and the password will be passed to the server so the user has to click "Okay" before it gets submitted. This can be escalated to more severe messages to pressure more sites to comply.

[dredmorbius]

Find a large user who feels this is a valuable feature and have them adopt it.

Governments are one such large customer.

Vendors, faced with multiple customers requesting a feature, but with slightly varying specifications, will tend to seek a mutually acceptable spec.

[seangrogg]

I'm waiting for other people to tell you to implement this, but without JavaScript.

[kerkeslager]

Implementing it in Javascript would defeat the entire purpose. The point is for the browser to implement it as a supported field on input tags of type password.