Everyone has a smartphone (in fact, many have more than one). Nobody wants to remember yet another password. Surely the combination of these two means that the smartphone app is the logical solution to securing authentication and delivering a truly passwordless experience for both employees and customers? Unfortunately, it’s not always as simple as that, though. In the ongoing war between convenience and user experience on the one side, and strong security and privacy on the other, we need to ensure that we do not unwittingly create new risks and attack surfaces in our rush to remove passwords.
The Trouble with Passwords
It’s probably not all that controversial to say that we, as an industry, are not doing knowledge- based authentication (and passwords in particular) at all well. Knowledge is fallible and unreliable – just because somebody knows a particular random string of characters at one point in time is unfortunately no guarantee that they’ll remember that same thing days, months oryears later. Bad password hygiene thus abounds, as individuals would rather use weak passwords to eliminate complexity and improve their own user experience. Companies often counter by enforcing impossible password policies that only make the user experience worse.
Smartphones are commonly used today as a secure yet convenient second factor, for a number of good reasons. Phones offer built-in private keystores protected with a biometric and a built- in way to deliver secure authentication challenges via push messaging. Smartphone apps often double as a soft token, and organizations can stay in control of the user experience and branding of the app. They are also cheaper and more convenient than hard-token based solutions
Are we ready, though, to abandon passwords entirely and rely solely on the smartphone as a way to authenticate users? I believe that we certainly can do this now.
The Boy who Logged In using (only) his Phone – with apologies to JK Rowling.
A number of techniques and patterns exist today for enabling authentication using only a smartphone. There are, of course, pros and cons to each of them.
Identifier + Push is one technique that I’ve seen. This is where the password is dropped entirely, with the user instead only providing a username (which can, of course, be cached in a browser cookie). Once the user has been identified, a push notification is sent to the smartphone app in order to authenticate the user through the possession factor. In order to implement this model securely (and not reduce security to single-factor, possession only authentication), it is strongly advised to ensure that a biometric login or approval is required on the mobile in order to accept the authentication request.
Claiming an authentication session through scanning a QR code is another popular approach – one that has the added usability bonus of removing the username entirely. In this model, the user opens a trusted app that is strongly linked with her identity, uses a biometric to unlock her private key, and then scans a code that is presented by the website she wishes to access. It’s agreat and novel approach to the problem but can lead to something of a proliferation of different authentication apps on the phone. Some level of user retraining may well be required, too.
Native app auto-login is a good approach for passwordless authentication when the user’s journey starts on the smartphone itself. Once again, the combination of possession (a private key within the app) and inherence through a biometric can be used to enable login without requiring users to type in usernames and passwords each time they launch an app.
Across the industry, we continue to evolve and develop new standards to improve authentication and two newer options for passwordless authentication have emerged from the identity standards community – each aiming to tackle the problem in different ways.
Client-Initiated Back-channel Authentication, or CIBA, is a new standard from the OpenID Foundation that complements the existing redirect-based OpenID Connect flows with a decoupled option that uses a push to a smartphone app as the primary means of user authentication. CIBA is still emerging but offers a solution to a wide variety of use cases, moving beyond authentication towards transaction approval as well.
The new WebAuthN standard developed under the auspices of the W3C provides an end-to-end secure flow for user authentication with a high level of resistance to phishing and man-in-the- middle attacks. Central to the approach is the Client-to-Authenticator Protocol (CTAP) that enables a user agent to communicate with any authenticator device that implements thestandard. Google’s latest phones incorporate a built-in CTAP authenticator, allowing the native biometric capability of the device to be used as an authentication factor.
With Great Power comes Great Responsibility
I do need to end with a few caveats, though. While the approaches outlined above all offer a far better user experience than anything based on passwords, we do need to take some key points into consideration. It’s a pretty small leap from “My Phone is my Password” to “My Phone is my Identity” and it thus becomes very important to include a strong process of identity proofing in any enrollment process that allows enablement of a smartphone app as a primary authentication factor. As the smartphone becomes the primary authenticator, it is equally important to ensure that possession of the smartphone alone is not sufficient to allow access; a biometric or knowledge step must always be added to the authentication process.
Some of these approaches are reliant on standards that are not yet implemented consistently across mobile operating systems and/or browser ecosystems; others rely on the user installing ‘yet another’ authentication application on their device, which can mar the user
experience. Both of these situations will improve with time, but for now, take care to pick solutions which are appropriate for your target user base.
Finally, we need to be realistic about the risks and vulnerabilities of a smartphone-app-based approach to identity and security and ensure we are implementing the necessary countermeasures to protect our users against the threat of compromise of their mobile keystores. This starts with detection of rooted or jailbroken devices but should also encompass an appropriate level of malware detection and anti-tampering counter measures.
(For additional background, check out Rob’s Identiverse presentation on this topic)
Rob Otto Office of the CTO Ping Identity
