Re: [Cfrg] OPAQUE at Facebook

Although the primary motivation is to avoid logging of plaintext
passwords, we still want to use a login protocol that provides good
security guarantees and models the same user experience that exists
today. We want to allow users to log in with a password, as opposed to
a private key -- so I believe this would make HOBA a less suitable
option. In SCRAM, the salt is sent to the client upon the server's
first message, which would mean that an attacker could build an
offline dictionary based on this salt (a precomputation attack).
OPAQUE gets around this through the use of an oblivious PRF, which
allows the client to keep its password secret, and the server to keep
the client-specific salt secret as well.

On the topic of client-side password hashing for OPAQUE: one advantage
this offers over the traditional plaintext passwords over TLS login
mechanism is that we can force the client to solve a challenge on each
password attempt. This may be useful in defending against "password
spraying" attacks, in which an attacker picks a single common password
and tries to log in to a large number of accounts using this password.
However, it is not clear if we can balance the thresholds for the
password hashing challenge to be significant enough to deter attackers
executing password spraying, while still allowing for a reasonable
user experience for the regular user attempting to log in. Thoughts?

On Wed, Aug 28, 2019 at 10:05 AM Kathleen Moriarty
<kathleen.moriarty.ietf@gmail.com> wrote:
>
>
>
> On Wed, Aug 28, 2019 at 12:36 PM Bill Cox <waywardgeek@gmail.com> 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
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg