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:
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:
This hybrid (or multi-layered) approach, provide the user with five levels of defense:
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 |