Re: [Cfrg] OPAQUE at Facebook

[Kathleen Moriarty <[e-mail]>]

On Wed, Aug 28, 2019 at 12:36 PM Bill Cox <[e-mail]> wrote:

> 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.
>

It's a public key, so I'm not sure that you would and am copying the author
in case he hasn't seen the thread.

I mentioned HOBA as it is more obscure and you may not have heard of it.
FIDO also uses raw keys, but you've likely evaluated that already too?

Best regards,
Kathleen


>
> 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.
>
>

-- 

Best regards,
Kathleen