# Secure password-authenticated key exchange that allows for passwords to be stored as hashes, but does not make the hashes password-equivalent

Are there any secure password-authenticated key exchange that allows for passwords to be stored as hashes, but does not make the hashes password-equivalent? This would be useful for many authentication applications.

• sure, there are quite a few, they're called augmented or asymmetric password-authenticated key exchanges. The latest (and IMO "coolest" one is OPAQUE) – SEJPM Sep 8 '18 at 17:14
• @SEJPM has the right answer, however: (1) in aPAKE only one party stores the hash, the other party still needs to know the password in the clear; (2) in OPAQUE at least, the thing that is stored as a "hash" is not actually a traditional hash -- it is a DH key symmetrically encrypted under a key which is a hash of a special PRF of the password ;) – Mikero Sep 8 '18 at 19:57
• @Mikero (1) is a feature, not a bug (it prevents pass-the-hash attacks), and as far as (2) that is good enough for my purposes. – Demi Sep 8 '18 at 21:07
• @SEJPM make your comment an answer (adding details, if you choose) and I'll accept it. – Demi Sep 8 '18 at 21:08

Are there any secure password-authenticated key exchange that allows for passwords to be stored as hashes, but does not make the hashes password-equivalent?

Yes, they are called augmented or asymmetric password-authenticated key exchanges (aPAKE). They generally build on the scenario that the user knows a password and the server may only store a "verifier" that should at most admit off-line brute-force search of the password and the key exchange should only succeed if the right password is match with the right verifier.

There are extensions to this approach which also consider cases where the user has a second device (e.g. a smart card or a phone) and a connection between his primary and secondary device, for an overview of the protocols, see here.

The most notable standard aPAKE is currently OPAQUE, which has already been announced to soon get an IRTF / CFRG draft and hopefully someday become an RFC, see this email thread.

The basic idea of OPAQUE goes as follows:

1. Upon registration the server generates a random key $k$ and two DH key-pairs and stores one of the private key as well as the random key and the two public keys in clear and computes $H(pw,H'(pw)^k)$ with the random key to get an encryption key which is used to perform an authenticated encryption over the complete second DH key and its own DH public key.
2. Upon a login request the client chooses its own DH public key as well as a random key which is used to exponentiate the inner hash of the of the password, ie $H(pw)$.
3. The server then retrieves the data stored on registration, generates a fresh DH keypair, exponentiates the received exponentiated hash with the stored $k$ and computes a key-exchange (HMQV is recommended) over its long-term secret DH key, its short-term DH secret key, the received short-term DH public key and the stored long-term DH public key.
4. The client undoes the exponentiation from 2. and evaluates $H(pw,X)$ on the result. This can e.g. be a memory-hard hash function taking the second input as the salt. It uses the resulting key to decrypt the stored ciphertext and itself computes the key-exchange.