Introduction
WebAuthn is a standard first published by the W3C in 2016. Its primary goal is a safe user-authentication method for web applications using public-key cryptography.
Most browsers (the estimated coverage at the time of writing is ~93%) support WebAuthn, however it has not yet been widely adopted by websites.
While there are a number of adoption challenges that we will discuss in a separate post, this article will focus on the significant security and compliance advantages that WebAuthn provides.
WebAuthn, in a nutshell
WebAuthn enables safe public-key cryptography inside the browser directly from JavaScript through an interface exposed via navigator.credentials. This is what happens under the hood when your user registers a new account on a website with WebAuthn:
- The browser interacts with an Authenticator, which can either be a Platform Authenticator (such as Windows Hello, TouchID, FaceID and similar) or an external/Roamining Authenticator such as a Yubikey or a Titan Key.
- The Authenticator generates a key pair, stores the private key in a secure location and returns the public key to the server via the browser API.
Any time a user wants to log-in, they sign a blob with their private key stored on their device and the remote server verifies the authenticity of the blob by checking its signature through the public key obtained in the registration process.
HIPAA and PSD2 authentication requirements
Both Healthtech and fintech are booming yet highly-regulated fields. Both sectors must comply with strict information security standards across the world. Two of the better known standards are the Health Insurance Portability and Accountability Act (HIPAA), regulating the security of Personal Health Information (PHI) in US healthcare sector, and the Payment Services Directive (PSD2) for EU financial services, both of which mandate a strong authentication policy.
It is beyond this article’s purview to describe who must comply with these regulations or their broader scope, so in this section we will simply focus on the authentication requirements that both laws mandate.
HIPAA mandates service providers to: “Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed” (Security Standard §164.312(d))
The US Department of Health and Human Services published additional verification standard guidance, stating that an user can be verified in one of three ways, by requiring:
- Something known only to that individual, such as a password or PIN.
- Something that an individual possesses, such as a smart card, a token, or a key.
- Something unique to the individual such as a biometric. Examples of biometrics include fingerprints, voice patterns, facial patterns or iris patterns.
By design, WebAuthn satisfies two out of the above three requirements out of the box. In fact, WebAuthn requires a device authenticator (e.g.,: FaceID, Windows Hello, TouchID) or a security key because that is where the private portion of the key as well as the ability to unlock that key which depending on the device is guarded either by a password/PIN or by biometrics.
WebAuthn is the perfect authentication method to satisfy HIPAA requirements, not only because it covers two out of three requirements but also because it makes credentials unfishable further increasing the security posture of the user.
PSD2 requires covered entities to protect their users through Strong Customer Authentication (SCA).
PSD2 states:
Where payment service providers apply strong customer authentication in accordance with Article 97(1) of Directive (EU) 2015/2366, the authentication shall be based on two or more elements which are categorised as knowledge, possession and inherence and shall result in the generation of an authentication code. In order to ensure the application of strong customer authentication, it is also necessary to require adequate security features for the elements of strong customer authentication categorised as ‘knowledge’ (something only the user knows), such as length or complexity, for the elements categorised as ‘possession’ (something only the user possesses), such as algorithm specifications, key length and information entropy, and for the devices and software that read elements categorised as ‘inherence’ (something the user is) such as algorithm specifications, biometric sensor and template protection features, in particular to mitigate the risk that those elements are uncovered, disclosed to and used by unauthorised parties. It is also necessary to lay down the requirements to ensure that those elements are independent, so that the breach of one does not compromise the reliability of the others, in particular when any of these elements are used through a multi-purpose device, namely a device such as a tablet or a mobile phone which can be used both for giving the instruction to make the payment and in the authentication process.
So how does WebAuthn help with PSD2-compliance? The most clear-cut answer is that WebAuthn using an external key such as a Yubikey or a Titan key covers two out of the three PSD2 requirements, depending on the authenticator: either possession and inherence or possession and knowledge.
The European Banking Authority is responsible for promulgating the RTS, the technical standards that govern SCA. However, individual member states are responsible for the laws and regulations that implement RTS. So, from a practical perspective, individual countries’ data regulators can and do alter their advised standards, and so each individual EU country might take a slightly different view on WebAuthn with a platform authenticator.
On the one hand, modern devices store WebAuthn private keys in a separate TPM (Trusted Platform Module) that remains uncompromised even when the phone itself is. On the other hand, compromising the phone can still lead to social engineering attacks that trick the user into authorizing WebAuthn transactions.
However, compromising a device will still lead to the compromise of any knowledge factor (e.g., a password). As such, we believe that WebAuthn with a platform authenticator on modern devices offers as much breach-independence as any other knowledge factor and can likely be used as the sole authentication mechanism for satisfying SCA requirements.
WebAuthn Anti-Phishing Properties
WebAuthn provides strong protection against phishing attacks. All compliant browsers enforce a number of security checks.
First of all, WebAuthn doesn’t work without TLS. Further, browsers enforce origin checks and most browsers will prevent access to the platform authenticator unless the window is in focus or, in the case of Safari/Apple devices, the user triggers an action.
In other words, an attacker trying to compromise user credentials will need to either find a cross-site scripting (XSS) bug in the target website or a vulnerability in the browser which is a very high barrier to overcome. This is the only way in which they can bypass the WebAuthn checks or perform a universal cross-site scripting (UXSS) attack.
In either scenario, a successful attack still won’t give the attacker access to the private key itself, but instead only a session token/cookie which will expire once the browsing session is over.
In comparison to all other authentication methods – where an attacker only has to register a seemingly related domain and have a similar looking webpage to fool the victim through phishing – it is clear that WebAuthn is a vastly superior authentication method.
Key Storage and Anti-Credential Stuffing
As hinted above, one key characteristic of WebAuthn in modern devices is that private keys never leave the secure storage they are created in. How this happens is implementation-dependent, but the guarantee is that, barring a compromise of the secure element itself and not solely of the operating system, the private key cannot be extracted.
The bar for compromising a secure element is extremely high. For example, the secure element inside iOS devices has had only two public bugs since it was created.
For instance, WebAuthn keys on iOS are stored in a system called Secure Enclave, which is separate from the main processor and which is capable of preserving the integrity of the data even in the event of a device compromise. The Secure Enclave is the same system that stores Apple Pay and FaceID data.
Further, unlocking access to a WebAuthn credential requires the user to confirm their identity either through FaceID or TouchID (depending on the device model). In both cases, the communication between the biometric device and the Secure Enclave happens over a physical serial peripheral bus over an encrypted channel, and the data never leaves the Secure Enclave, where it is verified against a 2D representation of the original biometric data.
While the example above specifically discusses Apple devices, similar security guarantees are provided by other Authenticators (whether platform or roaming), which make WebAuthn key extraction and, hence, credential stuffing attacks exceedingly difficult and unlikely, even in the event of full device compromise.
Conclusion
WebAuthn easily allows companies to comply with many regulatory frameworks such as HIPAA and PSD2 without relying on insecure passwords or requiring too many authentication factors from the user.
Additionally, it is clear that WebAuthn is a game-changer in authentication and it is by far the most secure authentication method available today. By employing WebAuthn, we can almost entirely remove credential stuffing, account takeover (ATO) and phishing attacks.
