This is part 3 of a series of blog posts on cryptographic authentication. Links to earlier posts can be found at the end of this post.
In the first two posts of the series I proposed a cryptographic authentication method that solves the loss-of-credential problem blamed by the FIDO Alliance for the lack of adoption of FIDO authentication in the consumer space, and does so without exposing the private key to capture by syncing the credential across devices.
In this post I show that strong authentication as traditionally defined can be achieved in the consumer space by combining a cryptographic credential with a second factor.
Traditional definition of strong authentication
Traditional thinking about user authentication distinguishes three types of authentication factors and requires at least two factors of different types for strong security. The three types are knowledge, or something that the user knows, such as a password; inherence, or something that the user is, i.e. a biometric feature; and possession, or something that the user has. Cryptographic authentication is a possession factor, based on a proof that the user possesses a cryptographic module containing a private key that is generated within the module and never leaves the module in the clear.
According to this thinking, cryptographic authentication by itself does not provide strong security because it only provides one authentication factor. But in the three authentication solutions discussed earlier in the series, cryptographic authentication is not used by itself. To use the key pair credential the user has to use a PIN or a biometric to unlock the platform authenticator that contains the credential in solutions 1 and 2, or to screen-unlock the device that contains the browser where the credential is stored in solution 3. Does such unlocking amount to a second authentication factor? Does it provide strong security?
Unlocking the credential is not an authentication factor in the consumer space
Even though a PIN is “something you know” and a biometric is “something you are”, unlocking the authenticator or screen-unlocking the device may or may not qualify as an authentication factor. This is because the PIN or the biometric are not presented to the remote relying party: they are presented to a local device, which may be controlled by the attacker. The device could be, for example, a public computer that the attacker has had access to and has tampered with. For the unlocking to qualify as an authentication factor, the relying party has to be assured that: (i) the authenticator in solutions 1 and 2, or the device in solution 3, are supposed to be capable of securely verifying the PIN or the biometric and communicating the result to the relying party, and (ii) they have not been tampered with. This assurance can be provided by the attestation feature of FIDO authenticators, but the FIDO Alliance recommends not using attestation in the consumer space:
A note on attestation: We recommend that most relying parties operating in the consumer (as opposed to enterprise) space not specify the attestation conveyance parameter attestation (thus defaulting to none), or instead explicitly use the value indirect. This guarantees the most streamlined user experience (platforms are likely to obtain consent from the user for other types of attestation conveyances, which likely results in a larger fraction of unsuccessful credential creations due to users canceling the creation).
Therefore unlocking does not count as an authentication factor in the consumer space.
Furthermore, even if attestation were performed, the unlocking would not provide strong security. Having to unlock the authenticator is meant to provide protection against an attacker who steals the device. But, as discussed in the previous post, an attacker who plans ahead may be able to use various easy attacks to obtain the PIN before stealing the device.
Yet it is possible to provide strong authentication in the consumer space, by using an undisputable second factor.
Two-factor cryptographic authentication
To provide strong security according to the traditional definition, I propose to combine a cryptographic credential with an authentication factor of a different type; specifically, with a password. Using a password as the second factor may seem surprising, since passwords are infamous for being vulnerable to phishing attacks, backend breaches, and reuse at malicious sites. But these vulnerabilities can be eliminated by combining the password with the cryptographic credential, rather than using both factors independently of each other.
The cryptographic credential that I propose to use consists of a key pair plus a secret salt, which are stored together in an authenticator or in browser storage. The secret salt is a just a random secret; I refer to it as a salt because it is hashed with the password.
To register, the JavaScript frontend of the relying party submits to the backend the public key and a hash of the password and the salt. The backend hashes together the public key and the salted hash of the password, stores the resulting joint hash in the backend database, and deletes the public key and the salted hash; the joint hash is the only security element stored in the backend database.
To authenticate, the frontend submits again the public key and the salted hash of the password to the backend, plus a signature on a backend challenge computed with the private key. The backend uses the public key to verify the signature and computes the joint hash of the public key and the salted hash of the password, which it compares to the stored joint hash.
This authentication method has the following security properties:
- The password, the salted hash of the password, and the public key are protected against a breach of the backend database, because they are not stored there. By contrast with one-factor password-based authentication, the salt and the salted hash are stored in the client rather than in the backend database; and by contrast with one-factor cryptographic authentication, the public key is not stored in the database either. Protecting the public key is useful in case a weakness is found in the cryptosystem used to compute the signature.
- The same password can be used without risk of compromise with all relying parties that use this authentication method, since a different salt is used for each relying party.
- The password is not vulnerable to a phishing attack, since it is sent hashed with the salt. The salted hash can obtained by a man-in-the middle phishing attacker, but cannot be used for impersonation, which would also require submission of a signature computed with the private key on a fresh challenge.
Security posture improvements
The above authentication method can be used to add a second factor to each of the three security solutions discussed in the previous posts, and improves their security postures as follows:
- Solution 1 (FIDO2) and solution 2 (multi-device credentials) become invulnerable to an attacker who steals the device after learning the PIN, or is able to use a physical adversarial example to defeat the biometric verifier.
- Solution 3 (browser storage) becomes invulnerable to such an attacker as long as the device is screen-locked when stolen and device encryption is in place.
Intellectual property
The above authentication method is disclosed in US patent 9,887,989. Please contact us if you would like to get a license for this patent.