Subject: [Cfrg] OPAQUE at Facebook

From: Kevin Lewi <[email-masked]>
Date: Tue, 27 Aug 2019 15:05:49 -0700

Hi all,

At Facebook, we are currently evaluating various methods for improving
the handling of plaintext user passwords server-side, and one proposal
which has caught our interest is using an augmented PAKE like OPAQUE
to completely avoid having the plaintext password sent (over TLS) to
the server during user login and account registration. Our primary
motivation is to prevent prior incidents involving the storing of
plaintext passwords due to logging bugs from ever happening again.

It is true that we do not need a cryptographic solution to avoid
logging plaintext passwords, and indeed, we have considered a myriad
of solutions to prevent such logging, including automated detection
mechanisms which regularly scan our data warehouse for plaintext
passwords. Of course, not having access to the plaintext password via
an augmented PAKE is not only a much cleaner solution, but it also
provides better guarantees. As a result, we have started to look into
what it would take to implement OPAQUE as an alternative login
mechanism for specific apps and supported devices.

This problem is also not specific to Facebook -- in the past two
years, Github, Twitter, Google, Robinhood, and Coinbase have all
reported a similar problem of accidentally logging plaintext
passwords.

It would be great to hear from this group on where the community
stands with the standardization of augmented PAKEs.

- Kevin

---

From: Bill Cox <[email-masked]>
Date: Tue, 27 Aug 2019 17:47:07 -0700

> stands with the standardization of augmented PAKEs.
I, for one, would say great minds think alike :)  The OPAQUE RFC could use
some tweeks, but looks pretty strong, IMO.  For example  they're
recommendation of iterating a password hash should be replaced with calling
Argon2.  Note that Argon2 runs pretty fast in browsers that support web
assembly.  Password hashing has to be done client-side in OPAQUE, with the
possible exception of using Makwa delegated hashing possibly in paraallel
with the OPRF round-trip.

---

From: Björn Haase <[email-masked]>
Date: Wed, 28 Aug 2019 03:18:23 +0000

Hi to all,

as one of the ones who nominated a candidate for augmented PAKE (AuCPace) I can confirm that the CFRG reviewers are presently very active and reviewing e.g. the proof strategies in detail. I agree that memory-hard password hashing should be used (in my proposal, I have suggested scrypt, but Argon2 is also a decent choice).

I also agree that we should really have a standardized protocol that mandates use of strong password hashes also for applications such as social media.

Yours,

Björn.

Mit freundlichen Grüßen I Best Regards 

Dr. Björn Haase 

Senior Expert Electronics | TGREH Electronics Hardware
Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 Gerlingen | Germany
Phone: +49 7156 209 377 | Fax: +49 7156 209 221
[email-masked] |  www.conducta.endress.com 

Endress+Hauser Conducta GmbH+Co.KG
Amtsgericht Stuttgart HRA 201908
Sitz der Gesellschaft: Gerlingen
Persönlich haftende Gesellschafterin:
Endress+Hauser Conducta Verwaltungsgesellschaft mbH
Sitz der Gesellschaft: Gerlingen
Amtsgericht Stuttgart HRA 201929
Geschäftsführer: Dr. Manfred Jagiella

Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, wenn wir personenbezogene Daten von Ihnen erheben.
Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis (https://www.endress.com/de/cookies-endress+hauser-website) nach.

Disclaimer: 

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer. This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such.

Von: Cfrg <[email-masked]> Im Auftrag von Bill Cox
Gesendet: Mittwoch, 28. August 2019 02:47
An: Kevin Lewi <[email-masked]>
Cc: IRTF CFRG <[email-masked]>
Betreff: Re: [Cfrg] OPAQUE at Facebook

- Kevin

I, for one, would say great minds think alike :)  The OPAQUE RFC could use some tweeks, but looks pretty strong, IMO.  For example  they're recommendation of iterating a password hash should be replaced with calling Argon2.  Note that Argon2 runs pretty fast in browsers that support web assembly.  Password hashing has to be done client-side in OPAQUE, with the possible exception of using Makwa delegated hashing possibly in paraallel with the OPRF round-trip.

---

From: david wong <[email-masked]>
Date: Tue, 27 Aug 2019 21:25:45 -0700

What about balloon hashing? It's compactness is very attractive. 

David

> On Aug 27, 2019, at 8:18 PM, Björn Haase <[email-masked]> wrote:
> 
> Hi to all,
>  
> Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis nach.
> 
>  
> 
> Disclaimer:
> 
> The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged
> material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities
> other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer.
> This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such.
> 
>  
> 
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Wed, 28 Aug 2019 07:39:43 +0300

Hi all,

- Kevin

Currently there is a PAKE selection process in CFRG - there are 8 PAKEs
that have been nominated.
We're on Stage 4, where the selected independent reviewers prepare their
analysis regarding the assigned questions. It will continue until
September, 15th, when the Crypto Review Panel members will start to work on
their overall reviews based on all obtained materials.

Kevin, Bill, David, are you willing to volunteer to help with these
reviews? Say, preparing short reviews regarding suitability of the
nominated PAKEs for usage in certain kind of services.
We still have 17 days left - that must be enough for doing such short
reviews.

Best regards,
Stanislav Smyshlyaev,
CFRG Secretary

ср, 28 авг. 2019 г. в 07:26, david wong <[email-masked]>:

> as one of the ones who nominated a candidate for augmented PAKE (AuCPace)
> I can confirm that the CFRG reviewers are presently very active and
> reviewing e.g. the proof strategies in detail. I agree that memory-hard
> password hashing should be used (in my proposal, I have suggested scrypt,
> but Argon2 is also a decent choice).
>
>
>
> I also agree that we should really have a standardized protocol that
> mandates use of strong password hashes also for applications such as social
> media.
>
>
>
> Yours,
>
>
>
> Björn.
>
>
>
> *Von:* Cfrg <[email-masked]> *Im Auftrag von * Bill Cox
> *Gesendet:* Mittwoch, 28. August 2019 02:47
> *An:* Kevin Lewi <[email-masked]>
> *Cc:* IRTF CFRG <[email-masked]>
> *Betreff:* Re: [Cfrg] OPAQUE at Facebook
>
>
>
> ------------------------------
> ------------------------------
>
> ------------------------------
>
> Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu
> informieren, wenn wir personenbezogene Daten von Ihnen erheben.
>
> Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis
> <https://www.de.endress.com/de/cookies-endress+hauser-website> nach.
> ------------------------------
>
>
>
> Disclaimer:
>
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential, proprietary, and/or
> privileged
> material. Any review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon, this information by persons or
> entities
> other than the intended recipient is prohibited. If you receive this in
> error, please contact the sender and delete the material from any computer.
> This e-mail does not constitute a contract offer, a contract amendment, or
> an acceptance of a contract offer unless explicitly and conspicuously
> designated or stated as such.
>
>
>
> https://www.irtf..org/mailman/listinfo/cfrg
> <https://www.irtf.org/mailman/listinfo/cfrg>
>

---

From: Neil Madden <[email-masked]>
Date: Wed, 28 Aug 2019 07:15:32 +0100

Do you need a PAKE for this? Wouldn’t something like SCRAM (https://tools.ietf.org/html/rfc5802) suffice?

— Neil

> On 27 Aug 2019, at 23:05, Kevin Lewi <[email-masked]> wrote:
> 
> Hi all,
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 28 Aug 2019 09:46:10 -0400

On Wed, Aug 28, 2019 at 2:15 AM Neil Madden <[email-masked]> wrote:

> Do you need a PAKE for this? Wouldn’t something like SCRAM (
> https://tools.ietf.org/html/rfc5802) suffice?
>

Or HOBA https://tools.ietf.org/html/rfc7486.  Both were experimental drafts
in HTTP-bis looking to solve the password problem.  HOBA also worried about
it on the server side and uses raw public keys to eliminate use of
passwords.

-Kathleen

-- 

Best regards,
Kathleen

---

From: Bill Cox <[email-masked]>
Date: Wed, 28 Aug 2019 09:35:50 -0700

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.

---

From: Bill Cox <[email-masked]>
Date: Wed, 28 Aug 2019 09:44:01 -0700

> We still have 17 days left - that must be enough for doing such short

I would be happy to review the PAKE schemes, from an implementer's point of
view.  I am a hacker rather than a cryptographer.  I implement a lot of
cryptographic algorithms, and am familiar with practical differences in
terms of threat models, efficiency, and such.  I also have more knowledge
of password hashing than most folks, if that is helpful.

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 28 Aug 2019 13:05:05 -0400

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

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

-- 

Best regards,
Kathleen

---

From: Kevin Lewi <[email-masked]>
Date: Wed, 28 Aug 2019 21:44:42 -0700

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
<[email-masked]> wrote:
>> 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
>
>>
>>
>> - The security proofs under the UC model provide some confidence in the OPAQUE framework.
>> - 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?
>> - Servers store password-derived public keys, and if an attacker has both the OPRF secrets (sid) and these keys, they can brute-force passwords.

---

From: Kevin Lewi <[email-masked]>
Date: Wed, 28 Aug 2019 21:46:11 -0700

I'm also happy to help with the PAKE review process.

On Wed, Aug 28, 2019 at 9:44 AM Bill Cox <[email-masked]> wrote:
>
> On Tue, Aug 27, 2019 at 9:40 PM Stanislav V. Smyshlyaev <[email-masked]> wrote:
>>
>>
>> Kevin, Bill, David, are you willing to volunteer to help with these reviews? Say, preparing short reviews regarding suitability of the nominated PAKEs for usage in certain kind of services.
>> We still have 17 days left - that must be enough for doing such short reviews.
>
>
> I would be happy to review the PAKE schemes, from an implementer's point of view.  I am a hacker rather than a cryptographer.  I implement a lot of cryptographic algorithms, and am familiar with practical differences in terms of threat models, efficiency, and such.  I also have more knowledge of password hashing than most folks, if that is helpful.