5

Apple and now Google are releasing products that are built on WebAuthn as a replacement for traditional username + passwords. Why did this technology beat out PAKEs?

2

2 Answers 2

13

Webauthn and PAKE solve different problems.

Authentication using PAKE is still authentication with a password. The problem that PAKE solves is that with traditional password authentication, you have to send your password in clear text to the server, so if an attacker can either spy on the communication or impersonate the legitimate server, they can learn your password. With PAKE, the data exchanged over the network allows the server to learn whether the client knows the password, but it doesn't allow an eavesdropper to learn the password. This can be beneficial even if the network traffic is protected by TLS or similar, because sometimes the network traffic is propagated through multiple points that have access to the clear text, for example, load balancers. Some PAKE algorithms (known as augmented PAKE) have the additional property that the server doesn't learn the password itself, so if the client uses the same password on two different systems, someone in control of server1 still won't be able to log into server2.

Webauthn allows getting rid of passwords altogether. The idea is that rather than authenticating by proving that you know a password (“what you know”), you authenticate with the help of some local device (“what you have”). This eliminates the problems with passwords, in particular the problem that users are bad at choosing passwords. It also reduces the risk of phishing, because Webauthn and similar protocols have some protection against phishing (by trying to make the data sent to the server useless to a third party, although I don't know to what extent Webauthn succeeds there). The cost is that authentication then becomes tied to a specific device (so if you lose your device, or your device gets compromised, it sucks to be you).

The only thing that both Webauthn and augmented PAKE do is to reduce the risk that the authentication is subject to phishing. But that's not the main argument against passwords, so PAKE wouldn't replace the goals of Webauthn.

2
  • 4
    WebAuthn also authenticates the server ("origin"), which PAKE doesn't, and which humans are understandably much worse at than the WebAuthn authenticator+browser combo is, eliminating an entire class of "site lookalike" and MITM phishing. There's also nothing that prevents WebAuthn from being used as an additional factor, rather than getting rid of passwords altogether. Aug 25, 2022 at 21:49
  • Doesn't the load balancers already on the target site that can open the TLS encryption?
    – kelalaka
    Aug 26, 2022 at 10:42
6

There are a couple reasons why WebAuthn is a better fit for the web than a PAKE, or password-authenticated key exchange.

First, WebAuthn is specifically designed to be resistant to phishing. That is, the browser authenticates the site independently of the operation and includes that data in the signature computation, such that a different site won't receive a valid signature. This isn't an inherent quality of a PAKE, although some PAKEs can include this information in the computation. This is one of the reasons why WebAuthn is one of the most compelling options for authentication, either as a first or second factor.

Second, a PAKE causes you to agree on a secret key that you don't then share with third parties, but can use to derive other keys. This is duplicative of TLS, which already does key exchange, and the reasonably secure approach of channel binding it as part of TLS has tended to be poorly implemented in the past as part of other protocols, and as such, it's tricky to apply it effectively in the real world.

Third, people continue to choose bad passwords. The password Password1! remains very common and unless you're very careful, the PAKE is only as secure as the bad passwords people tend choose. Brute force remains a popular option and PAKEs do nothing to stop this effectively. WebAuthn, on the other hand, uses a cryptographic key providing 128 bits of security and is invulnerable to brute force guessing.

Finally, WebAuthn can be used as a second factor in many cases to improve the security in addition to a password (which is typically how I see it used). This can be a second device which is tamper resistant, such as a YubiKey or other security key, or it can be part of a secure enclave on a device like a phone or computer. Because the algorithms implemented are very common, this can be done with relative ease even in very restricted hardware environments. PAKEs, on the other hand, are typically not a second factor, and they may or may not include operations already implemented securely in embedded CPUs and secure enclaves.

So, effectively, WebAuthn provides better security in the face of bad passwords (which is good when it's used a second factor) and is intrinsically resistant to phishing whereas PAKEs don't intrinsically have those features.

4
  • 1
    “is intrinsically resistant to phishing” — I am very wary of statements like these. Phishing can be very sophisticated and it's difficult to prevent users from inputting authentication data into whatever requests it, whether the authentication data is a password or a one-time code. Aug 25, 2022 at 18:41
  • 4
    WebAuthn includes the domain name in the cryptographic computation. Assuming your domain does not allow an attacker to host a phishing site, then there is no way that such a phishing site can succeed with WebAuthn. Of course, if your domain is compromised and hosts phishing sites, then this can be a problem, but in my experience this would be functionally very difficult to do for most major sites.
    – bk2204
    Aug 25, 2022 at 18:48
  • @bk2204 That is, until the user is running a compromised browser, right? Aug 26, 2022 at 17:55
  • Sure. In that case, the attacker has the password and can forge WebAuthn, the attacker can read all data, and the user and server have no security whatever related to connections from that browser.
    – bk2204
    Aug 26, 2022 at 18:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .