For decades we\u2019ve 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\u2019s 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 WebAuthNThe World Wide Web Consortium (W3C), the international group behind many of the Internet\u2019s 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\u2019s 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\u2019m 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\u2019s 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\u2019s popular, USB-interfacing, thin Yubikey devices are based on FIDO 2.0 and U2F.Even Google\u2019s 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\u2019t 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 growingEach 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\u2019t 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\u2019s not enabled and you want it, enable the option and restart the browser. GoogleEnabling WebAuthN in Google ChromeOne 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\u2019s not enabled and you want it, enable the checkbox and restart the browser. MicrosoftEnabling WebAuthN in Microsoft Windows EdgeFirefox 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\u2019t 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 worksClients 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\u2019ll 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\u2019s 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\u2019ve 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 \u201cchallenge\u201d 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\u2019s 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\u2019s harder to steal without the user being aware). Users will like it because they don\u2019t 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 WebAuthNSo, we get increased authentication assurance with fewer user issues. Who wouldn\u2019t 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\u2019t mean it\u2019s 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\u2019s 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 \u201cHey, this is an awesome authentication method that should take over the world!\u201d to a universally implemented authentication solution. How hard? We haven\u2019t done it once in multiple decades of tries and it\u2019s the reason why passwords still rule the web. Still, the world\u2019s 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\u2019t taken over the world before is that they are expensive to buy, maintains and support.Some of the WebAuthN solutions don\u2019t involve physically separate hardware devices, like those that use internal Trusted Platform Module (TPM) chips or the user\u2019s mobile phone. That only lessens the problem. It doesn\u2019t eliminate it.\u00a0I\u2019m 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\u2019t 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\u2019t be hacked, a user phished into going to a completely fake website can be given a completely fake WebAuthN authentication experience. It\u2019s impossible to stop a site from completely faking the entire process. Although the fake website might not have any of the user\u2019s personal data at the onset, it\u2019s 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\u2019re going to need it.This is not to say that we shouldn\u2019t warmly embrace WebAuthN. It\u2019s 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\u2019t think it\u2019s perfect or won\u2019t be hacked, because it isn\u2019t and it will be.