This is the part 2 of a series of blog posts on cryptographic authentication. The previous post can be found here. The next post is now available.
As pointed out in the response from the FIDO Alliance to the pre-draft call for comments on version 4 of NIST Special Publication 800-63, the two-factor-authentication solutions widely used today on the web are vulnerable to phishing attacks. On the other hand, cryptographic authentication with a key pair credential is phishing resistant, because the private key component of the key pair is not sent to the relying party, i.e. to the web site or web application to which the user is authenticating, and cannot be obtained by a phishing site.
As we saw in the previous post, FIDO2 is a cryptographic authentication solution that generates, stores and uses the key pair in a FIDO authenticator (except that it may export the private key under encryption to save space). Platform authenticators are now available in all commonly used personal computing devices, and can be accessed by browsers through the WebAuthn API of the W3C. This makes FIDO2 a generally available authentication solution for the web.
However, in a white paper issued in March 2022, the FIDO Alliance announced that FIDO2 “has not attained large-scale adoption in the consumer space”, and attributed the lack of adoption to challenges faced by consumers when a credential is lost because the device containing the platform authenticator becomes unavailable. Apple, Google and Microsoft are addressing this problem by implementing multi-device credentials that are stored in platform authenticators and can be synced across devices.
In the previous post I proposed a different cryptographic authentication solution, illustrated by two demo apps on GitHub, that uses a new user experience to solve the loss-of-credential problem. Key pairs are kept in persistent browser storage, and the user can easily create a new credential in a new browser by logging in with her email address and opening a link sent to the address.
The previous post was thus concerned with three cryptographic authentication solutions: a solution with single-device credentials, a solution with multi-device credentials, and a solution with single-browser credentials. In this post I compare the security postures of these three solutions in consumer-space use cases.
Three cryptographic authentication solutions
The single-device credential solution is the FIDO2 solution, where a credential is stored in a platform authenticator and can be used by all browsers running on the platform. In this solution, the platform authenticator qualifies as a cryptographic module, because it satisfies the following essential characteristic of such a module: the credential is generated and used inside the module, and the private key never leaves the module unencrypted. It is furthermore a hardware-based cryptographic module, where the credential is stored in tamper-proof storage or encrypted under a key that is itself stored in tamper-proof storage.
In the multi-device credential solution being implemented by Apple, Google and Microsoft, the key pair is stored in the platform authenticators of one or more devices and is synced across those devices, as described in the white paper of the FIDO Alliance:
Just like password managers do with passwords, the underlying OS platform will “sync” the cryptographic keys that belong to a FIDO credential from device to device. This means that the security and availability of a user’s synced credential depends on the security of the underlying OS platform’s (Google’s, Apple’s, Microsoft’s, etc.) authentication mechanism for their online accounts, and on the security method for reinstating access when all (old) devices were lost.
In this solution platform authenticators do not qualify as cryptographic modules, because credentials leave authenticators unencrypted, and may be used in authenticators where they have not been generated.
The single-browser credential solution is the browser-storage solution that I described in the previous post. The key pair credential is generated by the JavaScript front-end of the relying party. It is stored in persistent browser storage and never leaves the browser unencrypted, but the user can easily create a new credential in a new browser on the same device or a different device.
Mitigation of attacks relevant to the consumer space
The three solutions provide the following mitigations to attacks that are relevant to consumer-space use cases:
Attack by malicious JavaScript code running in the browser. In solutions 1 and 2, the same-origin policy of the web in conjunction with the FIDO2 specifications prevents JavaScript code originating from web sites or applications other than the relying party to use a credential that the authenticator has generated on behalf of the relying party. In solution 3, the same-origin policy prevents such code from accessing a credential that the relying party has stored in the browser.
Thus, in the absence of a relying party vulnerability, all three solutions are protected against attacker-originated JavaScript code running in the browser. However, a cross-site scripting vulnerability in the frontend of the relying party may allow attacker code to run as if it originated from the relying party. In solutions 1 and 2, such code can use the credential stored in the browser to impersonate the user, while in solution 3 it can extract the credential and use it to impersonate the user from a different device.
Attack by malware running in the device. If a device vulnerability is successfully exploited by the attacker, malware planted by the attacker may try to extract the credential or use it in place to impersonate the user. In solutions 1 and 2 the attacker’s malware can only use the credential in place, unless there is a vulnerability in the OS code that implements the platform authenticator. In solution 3 the malware may be able to extract the credential.
Phishing attack by a man-in-the-middle attacker. Solutions 1 and 3 are phishing-resistant because the private key component of the credential is not sent out on the network. In solution 2, on the other hand, as stated by the FIDO Alliance white paper and quoted above, “security of a synced credential depends on the security of the underlying OS platform’s (Google’s, Apple’s, Microsoft’s, etc.) authentication mechanism for their online accounts”, and those authentication mechanisms are not phishing-resistant. So solution 2 is vulnerable to this attack.
Attack against a backend database. Solutions 1, 2 and 3 do not store any secrets in a backend database of the relying party, as no password is used and the private key never leaves the client device. So they are not vulnerable to a breach of the backend database of the relying party. But solution 2 is vulnerable to a breach of the database of the platform provider (e.g. Apple, Google or Microsoft), which is used to authenticate to the user to the provider and may contain the salted hash of the user’s password and the seed used by the program that generates one-time passwords used as security codes in 2FA. A breach of that database may allow the attacker to log in to the platform provider and obtain a synced credential, which the attacker may then use to impersonate the user vis-a-vis the relying party.
Theft of the device. Platform authenticators are hardware-based cryptographic modules that protect a credential against extraction and against use in place. Protection against extraction is achieved by storing the credential in tamper-proof storage or encrypting it under a key that is itself stored in tamper-proof storage. Protection against use in place is achieved by requiring the user to unlock the credential by providing the same PIN or biometric that is used to screen-unlock the device.
Solution 1 is theoretically vulnerable to an attacker who steals the device and breaches the tamper-proofing or spoofs the biometric, and practically vulnerable to an attacker who steals the device and guesses the PIN.
Breaching the tamper-proofing is possible but difficult, and mitigating such an attack is not a capability that is expected from an authentication solution in the consumer space. Spoofing the biometric may also be possible but is also difficult, and not a relevant attack in the consumer space.
Guessing the PIN is difficult for an opportunistic thief who steals a smartphone that the user has forgotten in a coffee place. But guessing the PIN should be easy for a determined thief who knows the user and plans the theft ahead of time. Users are not asked not to reuse a PIN, and may use the same PIN online for many different purposes. The attacker may lure the victim into using the PIN for some purpose on a web site set up by the attacker, or may phish it as the user sends it to a third party site. The attacker may also obtain the PIN by shoulder surfing, and an attacker working on behalf of an authoritarian government may ask institutions were the user may have used the PIN to surrender all PINs that the user has used at those institutions.
In solution 1, guessing the PIN allows the attacker to use the credential to impersonate the user, but not to extract the credential.
Solution 2, like Solution 1, is vulnerable to a thief who steals the device after obtaining the PIN, and allows such a thief to impersonate the user, but not to extract the credential.
Like solutions 1 and 2, solution 3 is vulnerable to a thief who steals the device after obtaining the PIN, but it allows the thief not only to use the credential in place, but also to extract the credential.
Solution 3 is also vulnerable to credential extraction by a thief who steals the device when it is screen-unlocked. However the default configuration of modern smartphones and laptops screen-locks the device after only a few seconds of inactivity, requiring the thief to unlock it using the same unlocking mechanism that is required to unlock the credential in solution 1.
Furthermore, a device that is modern enough to be equipped with a platform authenticator can be configured to use a data protection feature that encrypts all data under a key that is stored in tamper-proof storage, in the same manner as the platform authenticator may protect credentials by encrypting them under such a key. The entire device can then be viewed as a hardware-based cryptographic module, since the credential is generated and used in the device, never leaves the device unencrypted, and is protected against extraction by a combination of tamper proofing and encryption. However, device encryption was shown to be vulnerable to a device vulnerability when the FBI was able to obtain the data in the San Bernardino iPhone in 2016.
Thus solution 3 prevents impersonation of the user by an attacker who steals the device if the attacker is not able to guess the PIN, the device is configured to screen-lock itself after a few seconds of inactivity, and effective device encryption is used to protect all data in the device when screen-locked. Otherwise solution 3 may allow the thief to extract the credential or use it in place.
Security postures of the three solutions in the consumer space
Solution 1 is phishing resistant and not vulnerable to a breach of a backend database. In the absence of a vulnerability in the JavaScript frontend of the relying party, solution 1 protects the user against impersonation by attacker-originated JavaScript code running in the browser. A cross-site scripting vulnerability in the frontend of the relying party may allow attacker code to use the credential in the authenticator to impersonate the user, but not to extract the credential. Malware running on the device may use the credential in place to impersonate the user, but may not extract the credential. Solution 1 is vulnerable to impersonation by an attacker who plans the attack and obtains the PIN before stealing the device.
Solution 2 is not phishing resistant. It is not vulnerable to a breach of the backend database of the relying party, but it is vulnerable to a breach of the backend database of the platform provider (e.g. Apple, Google or Microsoft). Solution 2 has the same security posture as solution 1 with respect to third-party JavaScript attacks, malware attacks, and device theft.
Like solution 1, solution 3 is phishing resistant and not vulnerable to a breach of a backend database. In the absence of a relying party vulnerability, it protects the user against attacker-originated JavaScript code running in the browser. However, a cross-site scripting vulnerability in the frontend of the relying party may allow attacker code to extract the credential. Malware running on the device may also extract the credential. Solution 3 prevents impersonation of the user by an attacker who steals the device and cannot guess the code, if the device screen-locks itself after a few seconds of inactivity and uses effective device encryption when screen-locked.
A surprising conclusion
Solutions 2 and 3 address the loss-of-credential problem that is blamed for the lack of adoption of FIDO2 in the consumer space by giving up some of the security provided by solution 1. Solution 2 gives up phishing resistance and introduces a database breach vulnerability that is not present in solution 1. Solution 3 has the same security posture as solution 1 under the following assumptions: no vulnerabilities in the JavaScript frontend of the relying party, no malware in the device, the device screen-locks itself after a few seconds of inactivity, and the device uses effective device encryption when screen-locked; but solution 3 is vulnerable to credential extraction when those assumptions are not satisfied.
The above is not surprising. What is surprising is the vulnerability of solution 1 to impersonation by an attacker who plans the attack and obtains the PIN before stealing the device. This weakness is not consistent with strong security features of FIDO2 such as tamper-proof hardware and attestation of authenticator capabilities to the relying party. I did not expect to find a security weakness in solution 1 when I started writing this post.
In the next post I will propose a way of addressing this weakness.
See also:
- Part 1: Passwordless Authentication for the Consumer Space
- Part 3: Strong Authentication for the Consumer Space
- Part 4: A User Experience for Strong Authentication in the Consumer Space
- Overview of the series in the cryptographic authentication page