What is WebAuthN? Possibly the answer to all web authentication

For decades we’ve been trying to replace the easily hackable, ubiquitous, single-factor logon name/password authentication deployments with something better. At least for web-based scenarios, the answer is finally here in the form of the new Web Authentication (WebAuthN) standard and API. WebAuthN enables website owners and service providers to present a unique cryptographic challenge that is bound to its origin. Local authentication of any kind is stored on and never leaves the user’s device.

It is likely that within just a few years, most serious websites and services will be WebAuthN-based, particularly those using multi-factor authentication (MFA) and passwordless solutions. Even websites using single-factor, passwordless solutions will benefit by using WebAuthN.

The question is if WebAuthN is the right standard and can it be hacked? The answer is yes to both.

Introducing WebAuthN

The World Wide Web Consortium (W3C), the international group behind many of the Internet’s latest developing open standards, created the working group behind WebAuthN in February 2016. The first meeting was on March 4, 2016, and it used the FIDO Alliance’s FIDO 2.0 standard as a starting point. The WebAuthN standard defines the WebAuthN API and digital signature details, which need to be implemented in all clients and servers using WebAuthN.

I’m a big fan of anything the FIDO Alliance does. The FIDO 2.0 open standard led to the very popular FIDO Universal Second Factor (U2F) standard. U2F relies on public key cryptography, and any U2F-enabled solution must securely store the user’s public key pair on the device. The private key (of the key pair) should always remain secured stored and used only on the U2F device, but the related public key can be shared off the device.

Hardware-based public-key authentication has been done for decades, mostly using smartcards and a handful of other devices, but the FIDO U2F standard helps generate many other hardware forms. Most of the hardware authentication devices put out over the last few years are U2F devices. For example, Yubico’s popular, USB-interfacing, thin Yubikey devices are based on FIDO 2.0 and U2F.

Even Google’s Security Key is based on the U2F standard. A few weeks ago Google announced that zero of their over 85,000 employees had, at least known to them, had been compromised by simple phishing attacks. WebAuthN is extending the success of FIDO 2.0 and U2F.

To use WebAuthN, the involved server/site/service must have code looking for and supporting WebAuthN authentication. It doesn’t need many lines of supporting code after the API functions have been implemented. Here are good examples of how to implement WebAuthN server-side, including a Microsoft example and one from Google.

Client support for WebAuthN is growing

Each client must use a device and software that is WebAuthN-enabled. Although any software program can be written to interface with WebAuthN, today, WebAuthN is mostly hosted in browser programs. Google Chrome has been supporting WebAuthN since Chrome 65 was released in January 2018, but it wasn’t enabled by default until Chrome 67 was released in May 2018.

To verify if your version of Chrome has WebAuthN enabled, open Chrome and type in type about:flags in the URL, hit Enter, and then look for the option labeled Enable Web Authentication API support (see figure below) near the bottom of the return. If you have Chrome version 67 or later and it says Default or Enabled, WebAuthN is enabled. If it’s not enabled and you want it, enable the option and restart the browser.

Google

One of my biggest beefs with anything FIDO-related has been that although many senior Microsoft people are involved in it and promoting FIDO-based authentication, Microsoft seemed to be more slowly implementing it than Google and other vendors. With WebAuthN the gap is closing.

WebAuthN support been available in Microsoft Edge since Windows 10 Release Candidate 5 version 17682 (i.e., developer versions), and it is available, but not enabled by default, in later production versions. If you have an up-to-date version of Windows 10, your version of Edge probably supports it.

To check if your version of Microsoft Edge has WebAuthN support or is enabled, open Microsoft Edge and type about:flags in the URL, hit ENTER, and then look for the checkbox option labeled Enable Web Authentication APIs (see figure below) near the bottom of the return. If it’s not enabled and you want it, enable the checkbox and restart the browser.

Microsoft

Firefox enabled WebAuthN support in May 2018 with Firefox version 60. Opera and Safari are both part of the WebAuthN working group and are slated to support it, but I could not confirm whether their current browsers support it. Opera does support U2F. No matter what your browser is, you can test its WebAuthN browser support.

One of the reasons not every browser currently supports WebAuthN is that isn’t fully released yet. In March 2018, it made Candidate Release mode, which is usually the final step before the production release. When the final version gets released, which should be soon, expect there to be a rush to support it, from both websites, browsers, and device manufacturers.

How WebAuthN works

Clients must register, at least once, on each website/service, on which they want to use WebAuthN. Like all authentication solutions, the WebAuthN solution is tied to a particular subject identity. So, if you have multiple email addresses or identity accounts or multiple WebAuthN devices, say one for personal use and one for work, you’ll need to register each where you plan to use them, often per device. The registration process collects different types of information, always including the registrant’s public key, but might include other information, like device attestation identifying information.

Registering involves the website sending a plaintext challenge to the WebAuthN client. The WebAuthN client then generates a unique public-key pair for the site. The WebAuthN software and device prompts the user to manually confirm that the new public-key pair can be generated and tied to the specific website. The user must confirm. This requirement prevents a malicious website from generating rogue WebAuthN pairs without the user knowing. The WebAuthN device and software then forwards the public key and other requested identifying information to the requesting site for future use.

When a user visits a WebAuthN-enabled website on which they’ve previously registered their WebAuthN identity and solution, and attempts to logon, the WebAuthN site first looks for all the validly registered WebAuthN IDs previously registered by the user to that site and sends a unique plaintext-based “challenge” to the WebAuthN-enabled software/device.

If not already done, the software/device locally authenticates the user via a supported WebAuthN method, which could include a biometric factor (such as fingerprint swipe) or be as simple as pushing a small button on the USB device (such as is popular on Yubikeys). Either way, the user is authenticating directly to their local WebNAuth-enabled device and software, which then unlocks the user’s private key(s) for use. The local authentication may be cached for future WebAuthN uses.

Once the user has authenticated locally, the private key related to the previously public key is used to sign the challenge and send the resulting digital signature (i.e., response) back to the site. The site then verifies the signed challenge by using the previously registered related public key and any other related validated information (like device attestation). If the site validates the signed challenge, then the user is successfully authenticated to the site.

As compared to password-based, single-factor authentication (1FA) solutions, WebAuthN is awesome! Using trusted public key cryptography, it provides a harder-to-phish credential and requires user (and optionally the device) to attest to use (it’s harder to steal without the user being aware). Users will like it because they don’t have to remember long, complex, and frequently changing passwords or PINs. In the authentication world this is known as less user friction.

Potential issues with WebAuthN

So, we get increased authentication assurance with fewer user issues. Who wouldn’t love that outcome?

As with any authentication solution, you have trade-offs. WebAuthN is giving us a lot of security with less user friction, but that doesn’t mean it’s the best solution in every authentication scenario.

There is no single authentication solution that works perfectly for all people in all scenarios. For example, at least right now, it’s a web-only standard. That means it only works with web-based software and services. Although our world is quickly moving in a web-only software/services world, many legacy software programs are not there yet. In fact, only a few WebAuthN-enabled websites support it (e.g., Dropbox).

The question is can we get to universal or near-universal support or will WebAuthN end up just another option with splintered support? If it does make it to universal support, as I suspect it will, how long until it gets there? Can we do it before the standard starts to fracture into a web of incompatible sub-standards?

It is so, so hard to get from “Hey, this is an awesome authentication method that should take over the world!” to a universally implemented authentication solution. How hard? We haven’t done it once in multiple decades of tries and it’s the reason why passwords still rule the web. Still, the world’s security leaders seem to be coalescing around WebAuthN. It seems to have broader support and more proponents than previous attempts.

I also have a big problem with WebAuthN solutions that allow 1FA. If not paired with some other authentication control, it means that simple possession of the device gives the processor control over the identity. Although to be fair, personal possession of a device is still better than 1FA solutions using logon name/password combinations.

Also, as good as the promise of WebAuthN is, it still has all the regular challenges that come along with the deployment, operations and management that any physical, additional, authentication device has. Ask anyone who has implemented any other physical authentication solutions, such as smartcards or other legacy USB-solutions. Hardware breaks and gets lost. USB ports stop working. One of the biggest reasons hardware-based solutions haven’t taken over the world before is that they are expensive to buy, maintains and support.

Some of the WebAuthN solutions don’t involve physically separate hardware devices, like those that use internal Trusted Platform Module (TPM) chips or the user’s mobile phone. That only lessens the problem. It doesn’t eliminate it. 

I’m a huge fan of this whitepaper that examines the security and challenges of using non-password-based solutions. Read it to get a good idea of the challenges you might face when using a particular type of non-password-based solution.

How can WebAuthN be hacked?

Anything can be hacked. WebAuthN isn’t even considered unhackable in theory, much less practice. Because WebAuthN is closely associated with FIDO 2.0 and U2F, you still have many of the security concerns associated with those standards. The FIDO alliance is well aware of the potential security issues, and not all risks have offsetting controls. In some cases, both clients and servers have to implement additional, optional controls such as token/channel binding and other replay-resistant methods. Some attacks that could be successful against FIDO 2.0/U2F/WebAuthN have nothing to do with the standard or API, but use other reliant technologies such as Transport Layer Security (TLS), channel binding, and replay-resistant methods to prevent current known attacks.

Out of the 11 methods to hack 2FA that I covered in a previous article, seven seem to apply to WebAuthN. Some of the better, but optional security methods, like token/channel binding, would break many deployment scenarios (such as connections involving intermediate or security-inspection proxies), and for those reasons, are not likely to be widely deployed.

Even if the WebAuthN standard or specific implementation can’t be hacked, a user phished into going to a completely fake website can be given a completely fake WebAuthN authentication experience. It’s impossible to stop a site from completely faking the entire process. Although the fake website might not have any of the user’s personal data at the onset, it’s not hard to prompt the user into providing confidential information once they think they are authenticated. How many times has a website prompted you for the last four digits of your social security number or email address after you have logged in?

I also wonder what will happen to WebAuthN when quantum computing breaks traditional public-key crypto forever. What do you do when your security solution relying on public key crypto is no longer reliable? I wonder how many of the WebAuthN solutions are practicing crypto-agility. Because with the public-key crypto break possibly just five years away, we’re going to need it.

This is not to say that we shouldn’t warmly embrace WebAuthN. It’s awesome and I hope every website and service in the world adopts it as soon as possible. It brings better security than passwords alone. Just don’t think it’s perfect or won’t be hacked, because it isn’t and it will be.