[Cfrg] OPAQUE at Facebook

Kevin Lewi <klewi@cs.stanford.edu> Tue, 27 August 2019 22:06 UTC

Return-Path: <klewi@cs.stanford.edu>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 3075C12004D for <cfrg@ietfa.amsl.com>; Tue, 27 Aug 2019 15:06:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id c3cUBAFZrKuR for <cfrg@ietfa.amsl.com>; Tue, 27 Aug 2019 15:06:01 -0700 (PDT)
Received: from smtp2.cs.Stanford.EDU (smtp2.cs.stanford.edu []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2EFF12012E for <cfrg@irtf.org>; Tue, 27 Aug 2019 15:06:01 -0700 (PDT)
Received: from mail-ot1-f53.google.com ([]:45081) by smtp2.cs.Stanford.EDU with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <klewi@cs.stanford.edu>) id 1i2jbF-00009K-8v for cfrg@irtf.org; Tue, 27 Aug 2019 15:06:01 -0700
Received: by mail-ot1-f53.google.com with SMTP id m24so692865otp.12 for <cfrg@irtf.org>; Tue, 27 Aug 2019 15:06:01 -0700 (PDT)
X-Gm-Message-State: APjAAAVp7KHA+P6wetDD49XVmOIiobNJ2tFgxo78EkhCFUienHz18rZx 54Lk0I2tabEkg53OofZ7H/HPhf9sF1LCgTbQGCg=
X-Google-Smtp-Source: APXvYqxntsFtrAHt9yibfllI60o95UGutFOhW5u2nF+Z/q2IUGeDVUGSLxwXC90mJK1swG/14purJW5sE3hMPmtLzMs=
X-Received: by 2002:a9d:7314:: with SMTP id e20mr704235otk.234.1566943560923; Tue, 27 Aug 2019 15:06:00 -0700 (PDT)
MIME-Version: 1.0
From: Kevin Lewi <klewi@cs.stanford.edu>
Date: Tue, 27 Aug 2019 15:05:49 -0700
X-Gmail-Original-Message-ID: <CACitvs_9SoZaG-0ZVNsGgcXJdadYHULVYEOH7VAQFf-VeSwm8Q@mail.gmail.com>
Message-ID: <CACitvs_9SoZaG-0ZVNsGgcXJdadYHULVYEOH7VAQFf-VeSwm8Q@mail.gmail.com>
To: cfrg@irtf.org
Content-Type: text/plain; charset="UTF-8"
X-Scan-Signature: 126b1dc68df40fcb6eeab1e6794671ae
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/1QQ_FfRsOxvoLGqX0t48WLTMSNU>
Subject: [Cfrg] OPAQUE at Facebook
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Aug 2019 22:06:50 -0000

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

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

- Kevin