Identity Management: Use two-factor authentication to mitigate fraud
You can—and should—use two-factor authentication with mobile and desktop devices.
Dan Griffin and Tom Jones
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.
Phone number as proof
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:
- The server makes an automated call back to the phone with a voice message including a one-time secret code. The user then types the code into a Web form to complete the desired online transaction.
- It can also send an SMS message, instead of a voice message, to convey the one-time code and prove user possession of the device.
- A variation of the previous process is to configure the system to let the user respond directly to the SMS (or to a phone tree during a voice call). This prevents having to remember the code while switching from one screen or window to another, and having to do additional typing. Instead, the online Web service is notified asynchronously of the valid SMS response from the user, and the requested transaction, which had been pending, is authorized.
- A PhoneFactor-aware mobile app can receive and respond correctly to an authenticator from the cloud service. Unlike the previous variations, this approach explicitly requires a smartphone app installed on the mobile device.
- You can forward a soft token (such as OAuth) sent to the PC or phone to the service consuming the claim. The PhoneFactor server isn’t involved in forwarding the token and doesn’t even need to know where it’s sent.
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.
Emerging threats
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.
Web logon
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 with Active Directory
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:
- The user logs on with the existing domain password, in addition to a secret code provided by PhoneFactor. This model uses a trusted Web service to manage the interaction between the client and the PhoneFactor back end.
- The CP acquires a certificate from the Certificate Authority (CA) and logs in to Windows Active Directory. The trusted Web service uses the SAML token from Active Directory Federation Services (AD FS) to acquire the certificate for Kerberos/PKINIT logon.
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.
.jpg "Tom Jones")
Tom Jones was the founding chair of the American National Standards subcommittee ASC X9A10 on electronic payments. He has worked within the financial services community with multiple organizations including Electronic Data Interchange (EDI X12) and Accredited Standards Committee X9 Inc. on electronic payments, as well as with First Data Corp., Intel Corp. and Microsoft.
.jpg "Dan Griffin")
Dan Griffin* is the founder of JW Secure Inc. and a Microsoft Enterprise Security MVP. He’s the author of the books “Cloud Security and Control” (CreateSpace Independent Publishing Platform, 2012) and “The Four Pillars of Endpoint Security: Safeguarding Your Network in the Age of Cloud Computing and the Bring-Your-Own-Device Trend” (CreateSpace Independent Publishing Platform, 2013). He’s also a frequent conference speaker and blogger at jwsecure.com/dan.*