I'm really excited about PAKEs! But for a totally different reason.<p>PAKEs are great for low-entropy secrets, but they don't have to be static: you can generate them on the fly too. Every time you have a human-mediated channel that eventually needs to agree on a strong secret, PAKEs are good. So, if you have a device that you want to pair with an existing device with an untrusted third party PAKEs are super great. You can use this to safely send a file across the ether by just sharing a short string like "2-bonobo-magic; see magic-wormhole.<p>I therefore disagree with the notion that a PAKE being symmetric is a downside: I just think that they're different tools for different tasks, and we should talk about sPAKEs and aPAKEs specifically. Symmetric PAKEs are worse for password auth: I just think PAKEs are not a high priority for password auth. There are two problems with passwords: cred stuffing and phishing (fundamentally the same attack: an attacker gets a password "out of band" and then replays it) and PAKEs solve neither.<p>[magic-wormhole]: <a href="https://github.com/warner/magic-wormhole" rel="nofollow">https://github.com/warner/magic-wormhole</a>
Unfortunately this won't help while we continue to trust JS sent to us by the server.<p>Their threat model is "server is compromised by an attacker, who then vacuums up all the cleartext passwords". Assuming that under normal operations there's some fancy UI that takes the password and handles the PAKE stuff (which it will have to be, until browsers support it), there's nothing stopping that attacker from simply adding malicious code that fire off your cleartext password.<p>If you want user authentication security, use client side TLS certs. 1) the UI is built into all major browsers, and can't be faked, and 2) the server doesn't require the CA's private key, only the server generating new certs needs it. In the above threat model, the worst that can happen if an attacker compromises the server is he can MITM the traffic at the time... but the attacker will never capture user credentials that can be used in the future, or be used to decrypt past communications.
Usually this blog is very practical and easy to understand. This post, though, just talks about how great PAKE is and what this new proposal achieves, but not the how of it. It sounds better than client side hashing, but it doesn't explain how (or whether) that's achieved. Actually looking into PAKE is left as an exercise for the reader (other than one screenshot full of math at the bottom).<p>Wikipedia is actually more clear in this case:<p>> an eavesdropper or man in the middle cannot obtain enough information to be able to brute force guess a password without further interactions with the parties for each (few) guesses. This means that strong security can be obtained using weak passwords.<p>Looking into SRP, it seems that a server can still brute force a stored login. While cool, TLS achieves the same goal in popular login systems: eavesdroppers cannot learn anything (in fact, they cannot even make a single attempt at the password, unlike with PAKE). The other advantage of PAKE, the server never receiving the password, can be done with client side hashing (for which I've been advocating for years, as it would have prevented many issues).
The reason it's not used more often is only because it's <i>incrementally</i> better than salted and memory-hard hashed passwords. It has obvious and important benefits, but still only incrementally better.<p>It's more important that bad implementations are removed immediately. Personally I'd rather get rid of all of my passwords and use FIDO2 or perhaps even something through touch-id on my iOS/Mac. At this point every password I have is unique thanks to great password managers.
I'll shamelessly plug this for Kerberos since SPAKE is a variant of PAKE...<p>Kerberos has a draft for adding SPAKE to Kerberos:
<a href="https://tools.ietf.org/html/draft-ietf-kitten-krb-spake-preauth-06" rel="nofollow">https://tools.ietf.org/html/draft-ietf-kitten-krb-spake-prea...</a><p>This was implemented sometime around March in MIT Kerberos:
<a href="https://github.com/krb5/krb5/pull/741" rel="nofollow">https://github.com/krb5/krb5/pull/741</a><p>One of the interesting use cases would be to add 2FA support to the Kerberos protocol, but that support is still pending last I checked.<p>A second draft that is useful for SPAKE would be improved Channel Binding (CBs) support:
<a href="https://tools.ietf.org/html/draft-ietf-kitten-channel-bound-flag-01" rel="nofollow">https://tools.ietf.org/html/draft-ietf-kitten-channel-bound-...</a><p>CBs are still WIP upstream:
<a href="https://github.com/krb5/krb5/pull/685" rel="nofollow">https://github.com/krb5/krb5/pull/685</a><p>Channel bindings allow Kerberos to piggy back on top of an existing encrypted channel (e.g., TLS). When doing 2FA with SPAKE in a browser, this means that we can take advantage of the security guarantees of the TLS protocol by ensuring the value of the final handshake is the same. This is most helpful for SSO-type scenarios.<p>If anyone wants to comment on either RFC, I'm sure the Kitten WG would be happy to take feedback:
<a href="https://tools.ietf.org/wg/kitten/" rel="nofollow">https://tools.ietf.org/wg/kitten/</a><p>Disclosure: I work closely with several of these folks and worked on the CBs PR.
I wonder if "Don't do password-authenticated key exchange." is still "Cryptographic right answer"; does OPAQUE address the reservations that tptacek had back in the day<p><a href="https://news.ycombinator.com/item?id=9593916#9594731" rel="nofollow">https://news.ycombinator.com/item?id=9593916#9594731</a>
Without digging into this post too much ... is the problem that we don't know the solution, that servers aren't implementing it, that clients (browsers) are limited, or more than one of the above?<p>To the degree that it's the browsers' limitations, couldn't the browser makers make a standard authentication client (or at least an API) with whatever tech and features are needed? A sandboxed mini-application, hardened, that passes a 'yes', 'no', or 'timeout' to the browser? Not every website would utilize it, but certainly the well-resourced ones could at first (FAANG, banks, etc.) and web server engines, frameworks, content management systems, etc. could incorporate the server side over time. It doesn't seem expensive, and the ROI would seem to enormous - safe authentication over the Internet. But maybe I'm solving the wrong problem?
For a more technical references check out Dan Boneh and Victor Shoup's cryptography book (pg 789). [0]<p>For the Gophers out there, I wrote a Go library for doing PAKE [1], which I use for a data transfer utility [2].<p>[0]: <a href="https://crypto.stanford.edu/~dabo/cryptobook/BonehShoup_0_4.pdf" rel="nofollow">https://crypto.stanford.edu/~dabo/cryptobook/BonehShoup_0_4....</a><p>[1]: <a href="https://github.com/schollz/pake" rel="nofollow">https://github.com/schollz/pake</a><p>[2]: <a href="https://github.com/schollz/croc" rel="nofollow">https://github.com/schollz/croc</a>
One place where PAKEs are widely deployed is in enterprise wifi networks that use PEAP/MSChapV2 password auth. MSChapV2 is really terrible and basically requires you to store passwords with weak hashes (or in cleartext).<p>Its nice to hear that there are PAKEs that are not tied to specific password hashing functions.
Something I've never understood is why we don't hash the password on the client before sending it to the server, and again on the server. This prevents the server from knowing your password (assuming it's a good one) with no real drawbacks that I can see.
Related and maybe more accessible: <a href="https://00f.net/2018/10/18/on-user-authentication/" rel="nofollow">https://00f.net/2018/10/18/on-user-authentication/</a>
This bit I didn't get:<p>> The earliest key exchange protocols — like classical Diffie-Hellman — were unauthenticated, which made them vulnerable to man-in-the-middle attacks.<p>From Wikipedia (<a href="https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange" rel="nofollow">https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exc...</a>):<p>> The Diffie–Hellman key exchange method allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure channel.<p>Maybe there's something I'm not understanding, but I thought the point of DH was you could exchange something even when other people are listening. You can see in the example in the article that it does't matter what Eve can see.