You can—and should—use two-factor authentication with mobile and desktop devices.
At the core of all Web-based transactions is the process of managing fraud. It’s essential to balance the inconvenience of user authentication with the risk of being spoofed. To put it another way, when is there sufficient knowledge of the user’s identity to allow the transaction to proceed?
Authenticating a user’s identity is already a difficult problem in the face of continuously evolving attacks. We’re now in the midst of a major paradigm shift. Mobile devices, not desktop computers, will be the platform for most transactions.
Mobile devices create new impediments to securing Internet services. Inconsistent and clumsy keyboards make it inconvenient to enter complex passwords, so most devices offer features to “remember” passwords. Mobile devices are also far more easily lost or stolen than desktop hardware. Plus, mobile applications—including those that may have access to saved passwords—have proven difficult to vet. These factors expose user identities to additional risk.
There’s another way to view the proliferation of mobile devices. It’s not necessarily a problem, but a solution to previous authentication methods stuck in a losing battle with malware developers and thieves.
The separate communication path—namely, the cellular network—to most mobile devices lets you fortify the barriers faced by any malware. You can use that separate path to bind the user to a specific phone number. Thereafter, the user-to-digits binding (or just having a specific SIM chip) can be reconfirmed as necessary during online transactions. This results in an exponential increase in the number of attempts an attacker would need to mount to get the same level of success.
Using phone numbers to reduce online fraud isn’t new. Banks have been employing this technique for years. What’s new is the ability for any online service, small or large, to easily incorporate this capability.
Microsoft recently acquired PhoneFactor, a mobile phone-based multi-factor authentication solution. It’s now available to customers as Windows Azure Active Authentication. With PhoneFactor, when an online service requires two-factor authentication, the phone can provide the second factor in a variety of ways:
Given the assumption that most users already have their phone most of the time, the benefit is multi-factor authentication without the usual incremental hardware (token) cost. This approach can have a dramatic impact on your fraud risk/reward curve.
Now imagine you’re a malware writer trying to attack a Web site that requires this type of authentication. Typical attacks focus on the device or the communications path to the device. An attack on the HTTP (TLS) connection is insufficient to get access to the Web service because the authorization code is sent via cell. To be successful, an attack must compromise both channels.
It’s good to understand the threats mitigated by new technology, and how and when new threats are introduced. Fortunately, rootkits have not yet become a factor in phone security. PhoneFactor operates at the application layer and thus offers no mitigation of rootkit threats.
At the app level, adding a second factor with no communications path in common with other factors is significant. It’s important to ensure there’s no code shared between the paths. That means the user must be involved at some level, either by copying a pin number from one process to another or by accepting a challenge on the phone that is then forwarded using one of the mechanisms described here.
Any interaction that doesn’t involve a human in the process is open to electronic attack. On the other hand, new threats to one of the authentication paths don’t introduce a greater threat than what’s already posed by static passwords.
Because the authorization code is different on every access by every user, a successful app-level attack doesn’t permit unfettered access to the Web service by the attacker. Thus, the value of the attack is reduced.
Attackers are interested in the greatest return for the least cost, so using multi-factor authentication encourages them to look elsewhere for easier pickings. By making multi-factor authentication relatively inexpensive to implement, services such as PhoneFactor reduce the chance an attack will succeed.
Fancy toys frequently come with a caveat printed on the outside of the box: “Some assembly required.” It’s the same with PhoneFactor. To help outline the typical integration requirements, the rest of this article describes solutions using PhoneFactor in two different user scenarios.
For interoperable Web logon, the goal is to use PhoneFactor for strong authentication. Then you can represent the user identity with a standard Web token format. You can use PhoneFactor in browser-based Web authentication scenarios by pending the request while the back end contacts the user phone. Once the user authenticates, the Web page refreshes and the user is free to proceed with sensitive transactions.
For this to work, the Web application must trust the PhoneFactor service to authenticate the user. It will have to return some representation of the user identity or other user attributes. Whenever possible, Web applications should be designed to use standards-based token formats, such as Security Assertion Markup Language (SAML) or JSON Web Token (JWT). This helps make them interoperable.
PhoneFactor isn’t just for Web authentication, though. It can also help make user authentication more secure without too much inconvenience for Windows desktop login. Microsoft has long recognized the need to support alternate authentication methods on Windows.
The Credential Provider API offers this extensibility. To begin the process, the user downloads a Credential Provider (CP) to the device. When the user attempts to log on, the CP sends a message to the back-end authentication service, requesting a PhoneFactor challenge. The CP provides an edit box for the user to type in the code received on his phone.
Once the code is verified, the back-end authentication system takes the additional step of issuing a short-lived public key infrastructure (PKI) certificate for the user. The CP uses the certificate to perform a Kerberos logon. As an additional layer of protection, you can have the certificate private key bound to the Type Parameter Model (TPM) security chip on the client device. It can also be bound to a random PIN generated by the CP. This results in a non-exportable, multi-factor credential that’s interoperable with existing applications and hardware.
This approach has the benefit of bridging the gap between PhoneFactor as the new authentication mode and the existing Active Directory infrastructure. There are several components involved in two-factor Windows desktop authentication:
While this scenario has the user entering the PIN in the domain-joined computer, you can also install a phone app that lets the user accept the request on the phone with a single click.
The benefits of two-factor authentication are well known, but have been difficult to achieve in practice because of the expense in getting the second factor into the hands of users. These are a couple of ways to extend the new Microsoft PhoneFactor technology into the authentication realms of interactive intranet logon, as well as standards-based Web logon.