Re: [Cfrg] OPAQUE at Facebook

[Bill Cox <[e-mail]>]

I have concerns about HOBA.  From the RFC:

> Servers using HOBA define their own policies for binding
>>>       CPKs with accounts during account registration.
>>>
>>> I assume this step involves sending the sever a password, which it would
have to check against a password hash database.  If this is true, it would
defeat the point of HOBA.  This RFC appears to be a partial solution only.

As for SCRAM, it still stores a salted password hash server-side.

OPAQUE has some interesting properties:

- The security proofs under the UC model provide some confidence in the
OPAQUE framework.
- The specific instantiations of the framework in the RFC look pretty good.
- If the aPAKE verifier is stored in a different security domain than the
OPRF secrets, an attacker mus PWN both to learn anyting when attacking
servers.
- The OPRF oracle can be an independent service, not controlled by the
aPAKE server in any way.
- The resulting 2-way authenticated shared key is interesting, and may
prove useful at some point (not sure how...).

Downsides include:

- The OPRF servers have to forward key exchange info learnied in the first
message to aPAKE server.  Can this be fixed?
- Only client-side password hashing is supported.
- Servers store password-derived public keys, and if an attacker has both
the OPRF secrets (sid) and these keys, they can brute-force passwords.
- 3 messages are involved vs the usual 1 message for authentication.