User authentication on the Web is in flux. Passwords are still the dominant authentication method, in spite of efforts to replace them with social login. Conflicting requirements for anonymity, pseudonymity and identification are being voiced. The US government is trying to create a secure identity ecosystem, is asking federal agencies to accept externally-issued credentials, and is working on methods of storing credentials of Federal employees and contractors in mobile devices.
Here are our view points, research and proposals in this exciting area of Web technology.
Password-based Authentication
User authentication on the Web has traditionally relied on passwords. Passwords have many virtues, notably those of simplicity and privacy. Passwords will no doubt persist even if alternative authentication methods are deployed successfully, and research on improving password security is warranted. We have done such research ourselves and been granted patents in that area, as reported in the white papers:
- Protecting a Multiuser Web Application against On-Line Password-Guessing Attacks.
- Secure Password Reset in a Multiuser Web Application.
But it is clear that passwords have serious drawbacks, notably the burden on the user to remember passwords, and the resulting security risks posed by password reuse.
Third-Party Login
An alternative to traditional password-based authentication is third-party login, where a Web site, the relying party, outsources authentication to another site, the identity provider, based on what we call double redirection protocols, such as SAML Browser SSO, OpenID, or OpenID Connect. The relying party redirects the user’s browser to the identity provider, which authenticates the user, typically by username and password, and redirects the browser back to the relying party, passing along user identity data.
Third-party login is convenient for the user, who has fewer passwords to remember. But it does not eliminate passwords, nor the risk of password reuse; and asking the user to enter a password after a redirection is a bad security practice, which increases the risk of phishing attacks against the identity provider, and fosters bad habits that facilitate phishing attacks on the Web at large.
Third-party login is also an invasion of user privacy, since the identity provider is informed of every login to a relying party.
Social login
Social login is a flavor of third-party login, pioneered by Facebook Connect, where the identity provider is a social site and the relying party not only learns the user’s identity, but also gains partial access to the user’s account at the social site so that it can issue updates on behalf of the user.
Today social login is typically implemented using OAuth, which requires the relying party to preregister with the social site. This reduces user choice, since the user can only log in via the social sites that the relying party has preregistered with. It gives power over the relying party to the social site, which can revoke the preregistration at its sole discretion. It also gives the social site power over users, who must get an account at the social site to be able to log in to the relying party, and can have their accounts terminated at any time at the social site’s sole discretion. And it inhibits competition, because a new social site will not be able to offer its users the convenience of social login at a large number of relying parties. OAuth also has serious security drawbacks. We summarized these issues in a response to the IETF Last Call for comments on the protocol.
In the context of our work on mobile authentication, we have devised a social login technique where the relying party does not need to share a secret with the social site and therefore does not need to preregister. Furthermore the user authenticates to the social site cryptographically rather than with a password, eliminating the risk of phishing attacks. The technique is briefly described in Section 7 of the paper
Although the technique is primarily intended for mobile devices, it can be adapted for use on traditional PCs by means of browser extensions, as described in Section 9 of the same paper.
Public key certificates
An alternative to passwords has been available for authentication on the Web since 1995, viz. public key certificates coupled with their associated private keys. The SSL protocol created by Netscape, later renamed TLS by the IETF, provided for authentication of both client and server with public key certificates. Server certificates, which were a prerequisite for ecommerce, were successfully deployed. But client certificates were not essential, because passwords provided a simpler alternative; little effort was put into working out practical deployment issues, and deployment of client certificates has remained cumbersome to this day.
Nevertheless, client certificates for protocols including TLS and IPsec are being successfully used for authentication of Federal employees and contractors to the information systems of Federal agencies, as a way of complying with presidential directive HSPD-12. The certificates and associated private keys are carried in Personal Identity Verification (PIV) cards, together with private keys for signing and decrypting secure mail and their associated certificates. NIST is now working on methods of storing Federal credentials in mobile devices, and we have proposed methods of doing so securely, as discussed in the Derived Credentials page.
NSTIC
In April 2011 the White House launched the National Strategy for Trusted Identities in Cyberspace, which aims at creating an Identity Ecosystem based on identity solutions that reduce password use and improve security, while increasing privacy and user choice. NSTIC subsumed the earlier Open Identity Initiative, whose goal was to use private sector identity providers to authenticate citizens who access government Web sites. Some NSTIC proponents believe that the goals of NSTIC can be easily achieved using currently deployed technologies; we have argued that this is not the case in the blog post NSTIC Is Not Low-Hanging Fruit.
Privacy-Enhancing Technologies
NSTIC was inspired in part by the existence of credentials based on privacy-enhancing technologies such as Microsoft’s U-Prove and IBM’s Idemix.
We reviewed the pros and cons of those credentials in four blog posts
- Pros and Cons of U-Prove for NSTIC
- Pros and Cons of Idemix for NSTIC
- Are Privacy-Enhancing Technologies Really Needed for NSTIC?
- Deployment and Usability of Cryptographic Credentials
We were then asked to summarize these posts as an introduction to a panel on privacy in the identification domain at the NIST Meeting on Privacy-Enhancing Cryptography. (See also our trip report). After the workshop we discussed an additional issue of privacy-enhancing credentials in another post:
We believe that credentials based on privacy-enhancing technologies have an important role to play in the NSTIC Identity Ecosystem, but it will take time to determine what use cases they are best suited for, and to resolve technical, deployment and usability issues.
We have compared the privacy features of a broad variety of authentication technologies in the paper: