Re: [Cfrg] OPAQUE at Facebook

[Bill Cox <[e-mail]>]

On Wed, Aug 28, 2019 at 9:44 PM Kevin Lewi <[e-mail]> wrote:

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


I agree HOBA doesn't look like a near-term solution.

Eliminating the problem of logging plaintext passwords can be done by
encrypting the password to a backend key sent in the login form.  For
clients that cannot run Javascript, the plaintext password can be encrypted
by the front-end machine (where where TLS terminates), minimizing the
chance of accidental logging.  IMO, this is a reasonable short-term
solution for this problem.

Various security upgrades are possible over this simple scheme.  OPAQUE is
interesting.

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

It also has the potentially cool property that the OPRF server and password
verification service can be in different security domains.


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

If you switched initially to the simple scheme of encrypting the password
to a public key in the login form, you also have the opportunity to do do
client-side hashing.  You can do rounds of hashing: Catena calls this
"pepper".  For example, the client could start with a 1MiB hash, then a
4MiB hash, and if it feels a 16MiB hash is too hard, the server could do
the 16MiB hash for the client.  The real salt should not be used: instead
just a userID of some sort on the client.  The final hash. after the
required rounds of pepper, is done server-side with secret salt, maybe just
HMAC(hardenedHash, secretSalt).

With this sort of adaptive client-side hashing, you can begin to gather
stats on what your client devices can do.