Notice:
This post is older than 5 years – the content might be outdated.
Use complex passwords they said! It will be secure they said!
This meme may be part of a humoristic view on the harsh reality. According to Google’s study 1.9 billion passwords were exposed during a period of one year caused by data breaches. In the same time 12.4 million users fell victim to phishing attacks. Also the Hasso-Plattner-Institut investigated that 20% of users in Germany re-use their passwords for different accounts. They also found out that ‚hallo‘ and ‚passwort‘ are the most popular German passwords. This reality shows that in practice passwords aren’t secure at all.
One thing that provides a remedy are One-Time Passwords (OTPs) which are sent for Two-Factor Authentication (2FA) via SMS or generated by an authenticator app. The problem with that approach is, in addition to poor usability, users still may be tricked to submit their credentials to the wrong website.
So a new authentication mechanism is needed that is more robust against exploits than passwords and simpler to use than OTPs. This challenge is the business of Fast Identity Online (FIDO), an alliance of more than 250 companies like PayPal, Microsoft and Google. In 2014, they announced the Universal Second Factor (U2F) specification which provides 2FA based on security keys, resistant to phishing, man-in-the-middle attacks (MitM) or stolen passwords.
Universal Second Factor Protocol: U2F
Simply put, besides a password the user needs an additional U2F device that is used for 2FA. Upon registration the device creates a key pair, with the public key stored by the service.
As the protocol is built upon challenge-response authentication, first a challenge token is sent to the client. To login, the challenge needs to be signed by the user’s private key and sent back to the server. The corresponding public key is used to identify the user without sharing any secret over the wire. Additionally, to protect against phishing and MitM attacks, the authentication flow is linked to the origin of the service and the channel ID, both of which are also signed by the U2F device and verified by the service. An overview of the sign-in process is illustrated in the following graphic.
WebAuthn: Web Authentication API
The Web Authentication API is based on the Credential Management API and adds a new PublicKeyCredential type to the credentials interface. It provides a standardized communication with external devices, to retrieve key pair information.
To this end, the Credential Management APIs navigator.credentials.create() and navigator.credentials.get() methods are extended by a publicKey parameter to register and authenticate users.
For registration the server sends a challenge token, information about the relying party as well as user information that need to be passed to the external device to initially create the key pair.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
navigator.credentials.create({ publicKey:{ challenge: Uint8Array(32) [141, 62, 161, 47, 3, 103,…], rp: { id: "example.com", name: "Example Corporation"}, user: { id: new Uint8Array(16), name: "john.doe@example.com", displayName: "John Doe" }, pubKeyCredParams: [{ type: "public-key", alg: -7 }], } }).then( PublicKeyCredential => { // PublicKeyCredential Object send to server }) |
After the keypair has been created, the promise returns a PublicKeyCredential object which contains the public key and additional metadata like the origin and the server challenge, signed by a hardware-backed private key. As soon as the PublicKeyCredential object has been sent to the server, it is stored with the users account after verifying its metadata and validating its signature, using the device’s certificate chain of trust.
Now that the user has been registered to the service, the navigator.credentials.get() method may be used to sign-in. But first, the server again sends a challenge to the client that needs to be passed to the Credential Management API. Now the previously created private key is used to sign the PublicKeyCredential information, which is send to the server.
|
1 2 3 4 5 6 7 8 9 |
navigator.credentials.get({ publicKey: options }).then(PublicKeyCredential => { // PublicKeyCredential send to server }) |
On server-side the corresponding public key is used to verify the identity of the user to create a session.
Back to the Future
So what does public key authentication mean for passwords, and the issues they introduce. As public keys may be used as 2FA, U2F will be a strong tool to defend against phishing and MitM attacks. The integrity of the users‘ data will be safer, as the signed metadata contains information about the relying party and the communication channel.
Also data breaches won’t compromise a user’s account as the public key part is useless to attackers, even when the password is simple or has been stolen.
Good news? Maybe you are wondering about FIDOs goal, to improve the simplicity of authentication. And you are right, the usability hasn’t changed much. To authenticate, users still need to carry an external device. Here, in addition to the WebAuthN specification the FIDO2 project defined a new Client-to-Authenticator Protocol (CTAP 2) that allows to use common devices to simply authenticate to web services. But the most stunning feature is that authenticators may be used as a first factor, which has the potential to replace passwords in the future.
Currently there are some services that already implemented the new Web Authentication API, like github or Facebook.
If you want to take a small glimpse into the future you may want to test dropbox’s U2F option with chrome 70, to use your device’s fingerprint sensor to sign-in. In the future maybe more and more services will adopt U2F as it provides an additional layer of security. It remains to be seen if passwords will be replaced, as still some security and usability factors need to be discussed first. Nevertheless, important first steps have been taken.
Further Resources
Other Articles in this Series
One thought on “WebAuthn: Strong Authentication for the Web [State of the Web]”