The World Wide Web of today is unthinkable without user authentication. A wide range of methods have been developed for this purpose, from text passwords over fingerprint recognition to USB security keys. Still, even with an abundance of authentication schemes, the text password remains the most widely used one. Particularly when it comes to web applications.
Despite its popularity, the password still remains an imperfect authentication method. Password security is compromised on various attack surfaces: from network security (phishing) over password storage (database leaks) to human factor. To this day, the most popular password over multiple services remains 123456. All this calls for alternative authentication methods which are secure, user-friendly and not prone to improper use.
In this article, we will take a look at a new web standard called Web Authentication (WebAuthn). It was created by the FIDO Alliance with the goal of complementing and eventually replacing alphanumeric passwords. We have studied WebAuthn’s technical specification and implemented the standard in our own proof of concept. To test passwordless authentication in the wild, we have assembled a participant group and let them try out our implementation. This allowed us to gather first impressions about the practical use of WebAuthn and its perception by the general public. Based on these results, we also made some implementation suggestions for implementing passwordless authentication in your own service.
WebAuthn Overview
WebAuthn provides an API for creating and managing public and private key credentials. Together with CTAP (Client to authenticator protocol), which is also a part of the same project called FIDO2, it provides a framework for communication between authenticators and relying parties (RPs):
In a nutshell, the FIDO2 standard can enable passwordless authentication using external and internal authenticators: for instance USB keys and fingerprint readers integrated into the platform. External authenticators ensure portability between devices, for example if you want to log in on a new smartphone. Internal authenticators allow not having to carry a physical USB key with you at all times, as you are able to log in with previously registered trusted devices at all times.
For more details about the practical implementation of WebAuthn you can consult Sven Lindauer’s inovex blog article. In this article, both registration and authentication with WebAuthn are described from a technical point of view. Since this publication, more browsers adopted WebAuthnn, such as Safari and Edge. Moreover, using internal authenticators for registration and authentication is now possible in Google Chrome. That means, you can use a biometric sensor integrated into your device instead of a USB key. There are many demonstration websites online where you can try out this functionality, so grab your YubiKey or a device with a fingerprint reader and get a comprehensive sneak peak of passwordless authentication here.
WebAuthn Proof of Concept
To try implementing WebAuthn for ourselves, we built our very own proof of concept. This is an Angular 7 web app which extends a user registration and login example application. We re-built it to implement passwordless authentication with WebAuthn, using a USB key for registration and login. It is also possible to enable fingerprint login in the settings.
The WebAuthn Backend is realised as a REST API, which can be implemented in a programming language of your choice, for example Java or Go. It is good practice not to implement your own crypto but to use an existing library for the back-end, as it is required for the relying party to perform numerous checks and cryptographic computations.
In this proof of concept, it is not possible to perform registration with a fingerprint, as it would prevent portability between different devices. As a server, it is possible to only allow one kind of key during registration or authentication, for example only external authenticators. Once fingerprint authentication is enabled in the settings, it is automatically chosen as preferred authentication method on this device.
Passwordless Authentication in Practice
What better way is there to test usability and perception of a new standard than with a user study? We have used the proof of concept described above to give test users a glimpse of what passwordless authentication could look like in the future. We gathered a total of 14 participants with mostly technical backgrounds and let them enable passwordless authentication in an already existing account and create a completely new account using only a USB stick and no password. After that, we interviewed them to find out their opinion of this new authentication method. We recorded and categorised their answers to get a rough overview of their reception of the standard.
Usability Feedback
The presented implementation of WebAuthn received abundant positive feedback, which can be seen from the following System Usability Scale result:
Four people mentioned the system being fast, six people explicitly characterized it as being easy to use. The advantage over the text passwords in terms of usability has also been mentioned („You don’t have to remember anything. Everything is encrypted with your own fingerprint, so to say.“).When asked the question „Can you imagine using the system in everyday life? If not, why?“, nine participants have given a clear „yes“ as an answer. Two of them stated that they would use WebAuthn just at their workplace, and another two would only use it as a second factor. Only one participant had given a „no“ as an answer.
A promising use case has been proposed by one subject. „I find that my most frequent use case would be to give other people the key. (…) I sometimes have this problem: someone wants to use my account but I don’t want to give them my password. Because I always use a fixed password. If I change it, I have to use the new password, and this is complicated.“
When asked a question what they would do in case of key loss, 43% of participants correctly supposed that they would use an option to delete or deactivate the key on the website. Four subjects said they would follow the instructions delivered to them with the security key or on the web-site beforehand. There have also been four participants who said they would call a „support number“ to block the key, like they would do if they lost their bank card. This scenario would not be possible if WebAuthn is used with different independent websites, as relying parties have no knowledge about each other. Nevertheless, it would be imaginable in a corporate context, when all services are managed by one entity.
Key loss has been correctly identified by most participants (64%) as a drawback of this type of passwordless authentication. One of the main considerations of WebAuthn is a lack of a protocol for backing up private keys and sharing them between authenticators. This concern has been voiced by a participant: „I would like to know beforehand what happens if I lose the YubiKey. Whether the security of my account is somehow at risk because of it.“
Usability Impairments
The most significant issue affected 8 out of 14 subjects and had to do with a lack of experience with alternative authentication methods, especially NFC chips. The participants struggled to hold the security key close enough to the smartphone or long enough, which caused an error message to pop up. It took a long time for some of them to find the correct place to hold the key to, and several users tried to touch the sensor of the key without plugging the key into the laptop or holding it to the smartphone.
Another source of confusion has been this pop-up on the smartphone , which instructs the user how to connect the security key in different ways:
Despite not being instructed to do so, many subjects have clicked through all the steps of the tutorial on how to use an NFC key every time. One participant has falsely selected the Bluetooth option every time, which may have caused misinformation, as the key still worked as expected. Later, they have made a following comment: „It would be good if it would be saved (it being the „Bluetooth“ option), so I don’t have to click it every time.“
Statements about Security
The YubiKey used in this study only supports user presence verification. That means, it has no fingerprint reader, just a touch sensor. As following, any person can touch it and approve credential creation or verification, which allows for malicious use. According to one participant, „It is like writing a PIN on the back of a credit card“. Moreover, the use of a fingerprint sensor in the login and registration flow has caused some polarised discussions about the use of biometric data for authentication.
Apart from correctly identified security problems, there have been some misconceptions regarding the use of WebAuthn or alternative authentication methods in general. Some people thought that a string of numbers is saved on the security key, which is used as a very long and secure password. Even though it is technically not correct, it didn’t have a negative effect on users‘ security perception („there is a code or a password that is 256 or longer, and this is in any case more secure than a normal text password“).
An interesting proposal has been voiced by one participant: „I would still use it for online shopping, but then on a separate stick, (…) which I then store in a less secure safe or something like that“. It is generally not a bad idea to use two sticks for a backup option, but they have to be identical. The mindset of using two different sticks with different security levels resembles patterns for reusing passwords for different accounts.
A common opinion voiced by some participants: „I am completely sure: if someone goes to such lengths, then it has to be more secure“. So there is some level of implicit trust in the standard, just because it is new and more „complicated“.
Implementation suggestions
So what do we learn from those interviews? The main concern voiced by the respondents was the fear of losing overview over all the credentials registered with a website. For us developers, this means implementing comprehensible credential management mechanisms, so that the user can always see and delete existing credentials on the service.
Another important thing is to give the users a sense of security while using hardware tokens. It is advisable to implement WebAuthn as or with a second factor. There is a possibility to protect a security key with an additional factor such as fingerprint recognition or a PIN, so you can make use of it in case you choose to use WebAuthn as your first factor. This will alleviate some concerns about what happens if such a key is lost.
This brings us to the last point: user education and guidance. It is always better to give users the knowledge of what to do in case of key loss before it happens, ideally before the first key is registered. The processes also have to be established on the service provider’s side to handle eventual requests from users in such cases.
To sum it up, WebAuthn is a promising standard for simplifying authentication both for users and for developers. It pledges to provide an alternative to the overused text password, with an increase in security. Still, there are usability issues to be addressed to make passwordless authentication ready to face the challenges of the real world. User education and guidance are also indispensable on WebAuthn’s way to mainstream usage.
