
Let’s talk about PAKE - stargrave
https://blog.cryptographyengineering.com/2018/10/19/lets-talk-about-pake/
======
lvh
I'm really excited about PAKEs! But for a totally different reason.

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.

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.

[magic-wormhole]: [https://github.com/warner/magic-
wormhole](https://github.com/warner/magic-wormhole)

------
parliament32
Unfortunately this won't help while we continue to trust JS sent to us by the
server.

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.

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.

~~~
akerl_
The problem that exists with TLS certs, and not with PAKE, is usability.

Client certs suffer from questions like "as a user, how do I handle multiple
devices? Logging in from my phone? Logging in from the biz center at some
hotel / my friend's phone / etc?

The UX for client certs in browsers makes it a pain to use even as a tech-
savvy person; if we want it to actually become popular as a web auth method,
it has to start with better UX.

~~~
parliament32
To be fair the UX for client side certs is pretty idiotproof once you have the
cert installed. You get a "X site is requesting an identity certificate" box.
Installing certs is pretty painless too -- you navigate to a certain page and
get a "this site is attempting to install a security identification
certificate in your browser" box. Securely getting to that page is a different
matter.

As for logging in on untrusted devices (biz center, friend's PC, etc)... you
shouldn't be doing that under any circumstances in a high security situation.

~~~
dogma1138
The problem with certificates is that A) it requires the user to install them
on every device B) they are required to be installed on every device C) they
are a bitch to manage and distribute and D) protection around certificates is
fairly weak and any client compromise will lead to the exposure of all
credentials.

You also end up delegating the authentication to your transport layer which is
never that good of an idea.

~~~
elblanko
I think most linux distro's protection of certificate private keys is pretty
weak (just storing a .pem file somewhere) and I can't say anything about OSX
but on Windows you can prevent the private key from being disclosed even if
the user wants to export it and enforce entering a password or PIN each time
the certificate is used. Getting access to the physical hardware is about the
only way to bypass the CryptoAPI, which is pretty far from 'any' client
compromise.

~~~
tialaramex
You can't actually "prevent the private key from being disclosed even if the
user wants to export it" out of box on Windows [if you have an HSM this may be
an option although it may also make the keys unsuitable for some purposes].
You can make it _annoying_ which is a stock in trade for Microsoft designs,
but attackers don't care about it being annoying. The reason is that the
CryptoAPI hands over the keys to an application for it to use (it does not
function only as a proxy like say ssh-agent), and so application can export
the keys. People even make ready-to-use apps to do this, because, as described
above, the CryptoAPI behaviour is annoying.

You can require a password, but that's true for text files on a Linux system
too. So why don't most people use a secret password to protect a file with a
secret key inside it? Because it's yet more pointless busy work, again a stock
in trade of Microsoft environments.

Also, because this is so very annoying you don't need physical access but only
console access, which you can of course get remotely, as otherwise
administrators of the mountains of Windows servers set up this way couldn't
type in all the passwords needed over RDP every day. (If you're lucky they are
using an encrypted RDP session to do this...)

~~~
elblanko
I agree that CryptoAPI is nasty, but if your key doesn't have the
CRYPT_EXPORTABLE flag set when it was created then it can not be exported by
CryptoAPI, and can only be accessed maliciously by breaking the CryptoAPI (by
patching it in memory, which requires full admin access to a running system)
or accessing the OS disk offline.

CryptoAPI does not hand over the key and delegate signing and encryption to
the application. Instead, it provides APIs for signing and encryption and does
not disclose the private key.

~~~
tialaramex
> CryptoAPI does not hand over the key and delegate signing and encryption to
> the application. Instead, it provides APIs for signing and encryption and
> does not disclose the private key.

There is no proxy, they keys live in your process. Because Windows is
proprietary they can do the moral equivalent of:

    
    
      if (key->flags & CRYPT_EXPORTABLE) {
        export(key)
      } else {
        error_not_exportable
      }
    

If you did this in OpenSSH, everybody would laugh because they could see it in
the source code. "This doesn't make the key unexportable Beavis, you idiot".
But in Windows they can solemnly announce that the key isn't exportable and as
you've demonstrated, people believe them even though some introspection tells
us this can't be true (Where is the key? Like, really, where - it isn't in a
proxy because there isn't one... when we load it _our_ process gets bigger and
in a debugger we can see it's in our memory, just CryptoAPI tells us we're not
supposed to export it...)

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

Wikipedia is actually more clear in this case:

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

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

~~~
matthewdgreen
Client side hashing solves only one aspect of the problem. Effectively, this
means a password breach of your service will give the attacker a “password
equivalent” that they can subsequently use to log into the service without
further cracking. This may or may not be a problem, depending on whether
you’re willing to lock all user accounts.

Whereas a proper asymmetric PAKE means that even if your password file is
breached, the attacker can’t use the leaked hashes to log into the service
without first cracking each password.

The problem you point out: that password hashes can be brute-force cracked, is
unfortunately not a problem we can solve. Consider that a server can always
“attempt a login to itself”, so given a password database you can always run a
dictionary attack. The only thing truly protecting you in that case is the
combination of strong passwords and a hard password hashing algorithm.
Passwords are fundamentally a drag.

~~~
xyzzy123
[Orthogonally to client-side hashing]

Using a hardware one-way function you can ensure that even if your database is
breached or disclosed, attackers cannot brute-force outside of your
environment (e.g. the hashed are “anchored” to your systems).

You can construct such a function using something like CloudHSM (pity that KMS
cannot be coaxed to be deterministic or you could use that). All you need is
an encrypt operation with no corresponding decrypt or way to extract the key.

I’m surprised that more large online services don’t use anchoring.

------
cipherboy
I'll shamelessly plug this for Kerberos since SPAKE is a variant of PAKE...

Kerberos has a draft for adding SPAKE to Kerberos:
[https://tools.ietf.org/html/draft-ietf-kitten-krb-spake-
prea...](https://tools.ietf.org/html/draft-ietf-kitten-krb-spake-preauth-06)

This was implemented sometime around March in MIT Kerberos:
[https://github.com/krb5/krb5/pull/741](https://github.com/krb5/krb5/pull/741)

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.

A second draft that is useful for SPAKE would be improved Channel Binding
(CBs) support: [https://tools.ietf.org/html/draft-ietf-kitten-channel-
bound-...](https://tools.ietf.org/html/draft-ietf-kitten-channel-bound-
flag-01)

CBs are still WIP upstream:
[https://github.com/krb5/krb5/pull/685](https://github.com/krb5/krb5/pull/685)

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.

If anyone wants to comment on either RFC, I'm sure the Kitten WG would be
happy to take feedback:
[https://tools.ietf.org/wg/kitten/](https://tools.ietf.org/wg/kitten/)

Disclosure: I work closely with several of these folks and worked on the CBs
PR.

~~~
lvh
Is there a particular reason to use a symmetric PAKE in this case? Is it
somehow not a long-held password?

------
dev_dull
The reason it's not used more often is only because it's _incrementally_
better than salted and memory-hard hashed passwords. It has obvious and
important benefits, but still only incrementally better.

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.

~~~
DINKDINK
>Personally I'd rather get rid of all of my passwords and use FIDO2

FIDO2 should be implemented in many more areas but it shouldn't be exclusively
relied on for authentication. Authentication should require proof of
person/entity (something you have, a FIDO2 key) and proof of volition (using a
password stored in their brain that their will decides to produce/disclose)

~~~
floatboth
> their will decides to produce/disclose

Or someone else's will decides to shoulder-surf / keylog the password :)

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

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?

~~~
fileworm
There is such an API. It's called HTTP authentication. No one uses it.

------
qrv3w
For a more technical references check out Dan Boneh and Victor Shoup's
cryptography book (pg 789). [0]

For the Gophers out there, I wrote a Go library for doing PAKE [1], which I
use for a data transfer utility [2].

[0]:
[https://crypto.stanford.edu/~dabo/cryptobook/BonehShoup_0_4....](https://crypto.stanford.edu/~dabo/cryptobook/BonehShoup_0_4.pdf)

[1]: [https://github.com/schollz/pake](https://github.com/schollz/pake)

[2]: [https://github.com/schollz/croc](https://github.com/schollz/croc)

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

[https://news.ycombinator.com/item?id=9593916#9594731](https://news.ycombinator.com/item?id=9593916#9594731)

~~~
tptacek
No, not at all. OPAQUE addresses problems Green has with SRP, not the problems
I have.

~~~
aidenn0
WPA-3 is using a PAKE, ignoring the fact that there are some concerns about
the specific PAKE used, do you think a PAKE buys anything in that use case?

~~~
lvh
It's pretty decent for the WiFi use case, but you could actually do something
cooler with a symmetric PAKE if your WiFi device had a display. Pick a short
random password, copy it over to the client, do SPAKE2. You now have a unique,
high entropy secret -- and you have strong guarantees no-one else has that
secret (an attacker can guess, but there's a tiny time window for them to do
so, and the honest participants are immediately convinced foul play occurred).

As it stands, the PAKE is better than what they had, but not ridiculously
better in the way U2F is over TOTP for example.

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

Its nice to hear that there are PAKEs that are not tied to specific password
hashing functions.

~~~
tptacek
The WPA2 4-way handshake isn't great, but a PAKE actually doesn't do too much
--- besides breaking the (slow) dictionary attack --- to operationally improve
its security. PAKEs are a good fit for wifi handshakes, if you're starting
from zero.

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

~~~
caf
Because then the hash of the password becomes equivalent to a password - a
malicious actor that learns the hash of the password can just use that to log
in to the service (since they can just choose to send it to the server).

~~~
gpm
You're absolutely right. But it means that they can't use the password to
build a dictionary, to log in to other services, etc. (Assuming the password
is complex enough that the hash isn't reversible)

------
jedisct1
Related and maybe more accessible: [https://00f.net/2018/10/18/on-user-
authentication/](https://00f.net/2018/10/18/on-user-authentication/)

~~~
nmadden
We have been looking at something very similar (using scrypt and Ed25519) at
work for LDAP (SASL) authentication. The primary motivation for us is to move
costly password hashing off the LDAP servers.

Our current design is basically the same, but we generate and store a random
salt server-side and present that to the client along with the challenge.
Using a deterministic salt based on the username and domain is a nice idea -
we actually do something similar if the client presents an incorrect username
to avoid leaking whether the account exists (we send salt = HMAC(secret,
username) in that case).

------
lordnacho
This bit I didn't get:

> The earliest key exchange protocols — like classical Diffie-Hellman — were
> unauthenticated, which made them vulnerable to man-in-the-middle attacks.

From Wikipedia
([https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exc...](https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange)):

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

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.

~~~
mike-cardwell
Without auth, you know you're doing DH, you just don't know who you're doing
it with.

If somebody is passively observing/recording the traffic, they wont know what
the negotiated shared secret was. However, if they actively insert themselves
in the middle, they can negotiate a shared key with you, and another one with
the final destination. Then they can decrypt messages from you with the shared
secret they negotiated with you, re-encrypt with the shared secret they
negotiated with the other party and forward them on.

------
Zash
Shout out to SCRAM (RFC 5802) which enables hashed password storage on both
the client and the server.

~~~
tptacek
Aren't you shouting out to a protocol that is in every material sense worse
than a PAKE?

