Usability of Stronger Authentication Options
In many cases, websites would like to authenticate their users with something in addition to (or instead of) a password. This can be done as a method to prevent phishing, but also to reduce the chance of someone manually hacking into a user's account. However the usability of some approaches in this area are poor. This document attempts to describe how usability and portability can be improved by combining multiple layers of authentication. Our focus is on approaches that can be deployed in the near term, with the hope that they provide enhanced security that can continue to be strengthened over time.
The following is a list of some of the more common approaches (you can also watch some videos of a few implementations) - note that some of these can be used as authentication mechanisms on their own, whereas some merely provide additional confidence (or lack of confidence) in other mechanisms used:
HTTP Request details (IP/subnet, browser type, OS type, language preferences, etc.) - Assuming a user primarily logs in from just a few machines, a website can remember some of the details about requests from those machines, especially the IP subnet, and use that to gain higher confidence in the identity of the user.
Cookie - While cookies are normally used to track a user after they are logged in, a website can also leave a persistent cookie on a user's computer after they have logged out which has encrypted tokens for each account that a user had previously logged into from that computer. A website can use this information to gain higher confidence in the identity of the user as well, and it works better than IP details if the user has a laptop with which they travel.
Hardware OTP - OTP stands for 'one time password' generator. Many enterprises and trade organizations have deployed physical devices to their end users which will generate a short code when the user presses a button. That code can be used for a short period of time to authenticate a user. These devices are simple (but have some cost) to deploy to end-users, however they are more susceptible than some other types of hardware token to various hacker attacks such as man-in-the-middle approaches.
Phone call - A common variant of OTP is to call the user every time they login using a phone number that has previously been registered with their account, or to send an SMS message to the phone with a 'one-time-password' if the phone is a mobile device.
Software certificate - Cryptographic certificates have been around for a long time. Unfortunately the usability of deploying them to a computer, and enabling the end-user to make use of them, is poor.
Hardware certificate (USB/Bluetooth token by itself, or with a pin entry or biometric, etc.) - These devices combine the strong crypto benefits of software certificates with the increased portability of a physical device. One addition security advantage they have over software certificates is that it is harder for malware to gain access to the private key if the user has to perform some action (such as pressing a button, typing a code, scanning the user's thumbprint, etc) on the hardware device whenever it performs a cryptographic operation. However these devices are not quite as portable as Hardware OTPs or mobile phones because many computers (especially in webcafes) do not allow the user to access USB/Bluetooth devices, and even if they did, the process of connecting such a device can be tricky, especially if additional software and/or configuration is needed.
One thing to note is that while these approaches can be used to more strongly authenticate the user, the rise of malware means that even after the user has been authenticated, there may be software on their machine that monitors for web sessions the user creates after logging in, and then performs actions at that site such as transferring money. Unfortunately protecting against that type of malware is much more difficult both for the end-user, and the website. However both problems (authentication and malware) need to be addressed, and in many cases they can be addressed separately. So for the rest of this document, we will not focus on malware, but just on authentication. In addition, we should learn from history that authentication itself is not sufficient. Take the example of social networks that screen scrape a user's address book, and to which users willingly give their login credentials for that feature. Even if E-mail providers had deployed stronger authentication mechanisms, the social networks could have just provided software for a user to download that would hijack their current E-mail login session, and use that to scrape the user's address book. And sadly, but realistically, users would have been willing to do that. One of the things we learned from that lesson was the need to support authorization, not just authentication, to allow users to give those social networks approval to access the user's address book through authorization protocols such as OAuth, and data formats such as Portable Contacts.
Given those caveats, let's get back to the point of usability for stronger authentication options. There are four major usability problems that need to be addressed, and which are described below.
Portability
As more and more data moves "to cloud services," and as users access that data with more devices (desktops, laptops, mobile phones, Tivos, Apple TVs, Playstations, etc.), the need for users to access their data from any device grows. However, while passwords are easy to use on nearly any device, the same is not true for some stronger authentication options such as software & hardware certificates. Thus websites which have deployed strong auth mechanisms have had more success by allowing users to use a more portable mechanism for stronger authentication such as hardware OTPs or mobile phones. Unfortunately those more portable options tend to provide less security then the less portable options. Even beyond the security, though, there is another usability problem.
Repeat Usage
Both consumer websites and enterprises that have deployed hardware OTPs or mobile phone authentication to users have encountered relatively consistent feedback that those devices become annoying after repeated usage. The task of logging in with such a device is much more cumbersome then using the browser's password autofill feature. One approach is to force users to login to a new machine using a stronger authentication mechanisms (OTP/certificate/etc.), but then to learn the HTTP Request details of that computer, and set a Cookie on the user's computer. For future login requests, those HTTP Request details and Cookies (usually in addition to a password) can be used to identify the user rather than requiring them to use a stronger authentication mechanism every time.
Provisioning
Nearly all the strong authentication mechanism require the users to go through some provisioning process. If a phone is used, then all the user needs to do is go through a one-time process of associating the phone with their account. On the other hand, hardware devices generally require the user to purchase the device, and then it needs to be physically mailed to them.
Rich Client Apps
Most installed software (desktop apps, mobile downloads, etc.) have built in code for displaying login boxes to collect a username/password, and they usually do not work with these different strong authentication mechanism. Google has published one option for how to address this using standards such as OAuth, but it requires a number of changes to how the software talks to the web servers. Of course, for websites that do not provide rich client apps, this is not a problem.
Hybrid (or multi-layered) Approach
The best approach is likely to come by a combination of the techniques above. One such example is the following:
The website can ask the user to enter their mobile phone number when they create an account, and then send them a one-time code via SMS that the user enters on the website to verify ownership of that mobile phone.
Whenever the user tries to log in from a new machine, or on a laptop from a different IP/subnet, an automated call (or SMS message) can be placed to their phone to verify their identity which requires the user to press a button for confirmation.
Once a user has logged into a machine, the website can remember its HTTP request details and allow the user to login in the future using just a password from that machine as long as it is from the same IP/subnet
For laptops the user frequently logs into, but which are portable (i.e. they are used from different IPs/subnets), the website can offer the user the option of installing a per-machine persistent cookie so they no longer need to use their phone every time they want to login from a new IP address. The user can also be asked to give a name to that machine in case they want to invalidate that cookie later.
A number of online banks now use this type of approach with a large number of consumers, so that gives us reasonable confidence that the usability is adequate. Note that in step 2, we use a one-time code (OTP) or phone-call. Both options have the potential to be circumvented by hackers using phishing style techniques, though it is harder than traditional password phishing. However, if the website requires the user to name new machines, then it can also display warnings in the user's account for a few days/weeks after a new machine is set up, and the user might disable access from that machine if they do not recognize its name. If that computer has anti-phishing software installed, or advanced software such as password-authenticated key exchange (PAKE) or zero-knowledge proofs (ZKP), then that will further reduce the chance of the OTP/phone-call being compromised
This hybrid (or multi-layered) approach, provide the user with five levels of defense:
Anti-phishing software
Portable device that can be used to get one-time codes
Per-machine cookies/certificates, which cannot be phished
Traditional password
Website warnings to the user about new machines, or persistent cookies that appear to be used on multiple machines
A traditional website only uses layer 4, and if the user is lucky their computer has software providing layer 1. The addition of layers 2/3/5 provide significant potential to improve security, with minimal impact on usability. But, of course, other layers of security can be provided to further improve security, but with more impact on usability and portability. Below is a list of some additional layers that can be added, and the impact on usability/security.
Some user's mobile phones include a barcode scanner, so if they have previously logged into their mobile phone and still have a session cookie for that login, then the website on the computer can display a one-time URL in a barcode, and if the phone scans that barcode and visits the URL, then the website can automatically log them into the same account that the phone is currently logged into (+ for usability if barcode scanner is well integrated, - for security since the URLs could be embedded in any barcode by a hacker)
Use a per-machine software certificate instead of a cooke (- for usability, + for security, primarily in terms of better protection from cross-site scripting attacks)
Configure the certificate to be automatically sent to the website that issued it upon request (+ for usability)
Store software certificates with specialized software (which sometimes needs to be downloaded) such as an InfoCard selector that can secure the certificate with a local passcode that is needed to unlock it (- for usability, + for security)
A hardware OTP could be mailed to the user to be used instead of the mobile phone (little change in usability/security, more expensive one-time cost, but potentially less-expensive ongoing cost compared with SMS/phone-call fees)
A Hardware token containing a certificate could be mailed to the user to be used instead of a password/OTP on machines where the user can access a USB or Bluetooth device (- for usability, + for security)
Either hardware token can be unlocked by requiring the user to type a PIN or using biometrics, such as a thumbprint scan (- for usability, + for security)
Mail the user a combo hardware OTP/certificate device or build the functionality into an advanced mobile phone (combines the pros/cons of the previous three options).
Use a hardware device to log in to a user account on the operating system, but then use simpler mechanisms such as software certificates (or bypassing of extra hardware unlocking mechanisms) for individual website logins (+ for usability compared to regular hardware certificate usage)
Usage of Certificates
Note that in the second bullet above we suggest issuing "per-machine" software certificates. The other approach is to create a single certificate per user account, and issue it to each computer. The per-user certificate has the potential advantage that other attributes about the user could be embedded in it, and that some other websites might allow the end-user to use that certificate as a way of authenticating the user on that site. However the advantage of per-machine certificates is that they can easily be revoked, and the user can even give a name to the machine so that activity from that machine can be shown in their account. This also works more seamlessly with the advanced mobile phones (or other devices in the future) which already have an integrated certificate which can be bound to the user's account. In addition, if malware on a user's computer copies the per-machine certificate to a different computer, then the IdP can attempt to detect the multiple instances of the certificate by looking at browser cookies, and can display warnings in the users account if the IdP thinks a certificate has been stolen. However this is more difficult (though solvable), if the IdP is not the primary application provider to the user, and thus does not have a place to show those warnings.
Assuming a "per-machine" cert is used, then that raises the question of whether the cert is useful only to a particular website (similar to cookies), or useful across multiple sites. The decision of which to use is likely to mostly be a question of usability and privacy. If the device has an existing cert then the simplest user experience may be to re-use that cert with multiple IdPs who want to bind it to an account on their website. If the device does not have an existing cert, or if privacy is a concern, then it is probably easier to issue a per-site specific certificate because it can probably be installed and used in a way that is nearly invisible to the user, or at most requires one prompt to confirm the installation of the cert.
Unfortunately the biggest problem with certificates (software and hardware) is that there is wide variance in the user interface that different browsers and operating systems use to allow a user to setup or use a certificate with a website. If you want to try a few such options, set up an account at the Verisign PIP service, and after you login try enabling strong authentication for your account using a browser certificate or InfoCard. Or you can watch some videos of a few other implementations.
Unfortunately, because of the wide variance in user interface, it is extremely hard for websites to even provide documentation on how their end-users should interact with these UIs. The InfoCard community has done some of the most detailed work on improving the user interface for software certificates, especially the Microsoft CardSpace team. However, very few platforms support a CardSpace type user interface, and even on the Windows platform only a small fraction of computers have the necessary software to use CardSpace. Hopefully the industry will continue to refine the best practices for the UI of using certificates within a browser, as well as simplifying the underlying technology, and then push for broad deployment to browser platforms in the future.
Consumer Space: Value vs. Work
In the consumer space, there are only a few websites like banks, Paypal, and Microsoft HealthVault that have done significant pilots using strong authentication with the more complex techniques such as certificates or OTPs. However, if we can reduce the "work" required for users to adopt strong auth, and can increase the "value," then we may see them more willing to help websites reduce phishing and other account hijacking attempts. As we hone these strong auth usability approaches, we should be able to reduce the "work." To increase the "value," we probably will need to make it possible for end users to leverage a single strong auth system across multiple websites. That brings us back to the problem of federated login, which is another area with usability problems, but one where the industry is starting to show signs of progress.
Note that when we say "single strong auth system," we mean per-user (or website), not for all users/websites. We will probably see lots of identity providers for federated login (social networks, E-mail providers, etc.), and some of them may give users the option to be authenticated via a strong auth approach. And for some of those approaches, the IdP might in turn redirect the user to a second IdP who handles complex auth mechanisms like certificates (especially if the certificates come from yet another identity provider, like a government issued identity card).
Privacy and Strong Authentication
One topic not covered in the section above is the privacy impacts of strong authentication. If the user's IdP (the one provisioning the strong auth mechanism) asks for the phone number of a user to use for sending one-time-codes, or for their postal address to mail them a hardware device, then the IdP will have more personally identifiable information about them. Another option is for a website to not become an IdP themselves, but to become a relying party (RP) in a federated login scenario to an existing IdP which strongly authenticates the user (and may have needed to ask for PII to provision the strong auth mechanisms). There are even open standards such as PAPE which allow the RP website to tell the IdP the level of authentication that it wishes to have used to authenticate the user.
Another option is for the user to acquire (or possibly even have their government issue) their own certificate (hardware or software), and use that to authenticate to the IdP so that the IdP does not need to ask them for PII like their phone number or postal address. However, the IdP could still potentially track what RP websites a user logged into that identified the user based on the IdP, and also, if the user has multiple IdPs he could be tracked across them. A more extreme option is for the user to authenticate to each individual website using a certificate that is not associated with an IdP. If websites are already willing to become RPs to centralized IdPs, then they potentially may be willing to support this option. However in reality most mainstream websites will require an E-mail address from the user so they can contact them, as well as to use as an identifier if the person calls the company's helpdesk. Unfortunately those E-mail addresses sometimes end up in the hands of spammers. So the use of personal certificates has much less value if the user has to prove ownership of an E-mail address to each website.
For more on this topic, see Privacy and Authentication.
Ben Laurie, Software Engineer, Google Security
Eric Sachs, Product Manager, Google Security
Originally posted: November 2008