RSA-Proofing Our Duo Push Two-Factor Authentication

So…RSA happened.

We haven’t commented much on the RSA breach, primarily because, instead of ambulance chasing, we’ve been busy working on some technology to prevent RSA-style attacks from impacting our Duo Push authentication, which is the subject of today’s post.

However, I think there are a couple interesting points that can be drawn from the RSA breach:

First, the RSA breach has shown that two-factor technology is incredibly effective. The attackers targeting Lockheed Martin and company had to plan an entirely separate operation to compromise RSA’s internal secrets to even get their foot in the door of the defense contractors. While RSA’s implementation of two-factor may be suboptimal, the event bolsters the argument for deploying two-factor rather than undermining it.

Second, to butcher a Fight Club quote: “On a long enough timeline, everyone gets owned.” Even RSA. The design decisions and mechanisms that help mitigate the risk of a breach, limit its impact, and rapidly recover from it are the most important things to consider. In RSA’s case, they did a lot wrong, which they undoubtedly realize as they churn millions of new SecurID tokens off the assembly lines.

Trusting your two-factor service

The topic of trust is something near and dear to us at Duo, as we’ve designed our platform from the ground-up to place as minimal trust in our service as necessary and are continually working to further host-proof our service.

We already limit our risk and differentiate ourselves from our competitors by maintaining complete independence (none of this pin+passcode garbage) from your primary authentication for our native integrations (eg. Web, Juniper, Cisco, Unix, etc). That is, instead of delivering an on-site hardware/virtual appliance that proxies usernames and passwords, your users' primary credentials are never touched by Duo-controlled code. In the event of a compromise, the integrity of your users' primary credentials remains intact.

The other issue that is important to protect against is RSA-style breaches, where the shared secrets used as the seed for OTP-based authentication may be leaked out of a database by an attacker. Unfortunately, the use of shared secrets is a necessity for OTP-based authentication, so any and all vendors (RSA, Google, Verisign/Symantec, etc) offering OTP two-factor (whether OATH’s HOTP/TOTP or some other proprietary algorithm) are vulnerable to RSA-style breaches.

RSA-proofing Duo Push

Just a couple weeks ago, we launched our Duo Push authentication:

Duo Push leverages the capabilities of modern smartphones to create a more secure and user-friendly two-factor authentication experience. Specifically, Duo Push utilizes the native push notifications (APNS, C2DM, etc) to provide real-time notification of transaction and login requests to a user’s smartphone, a secure out-of-band (OOB) communications protocol to display the full verified details of the request to the user, and simple one-touch responses to allow the user to approve or deny the request on the smartphone itself.

Today, we’re happy to announce that we’ve “RSA-proofed” our Duo Push authentication, just one of the many security benefits of using Duo Push.

By “RSA-proof”, we mean that even if an attacker leaked all the secrets from our database, they’d be unable to forge successful authentication responses for our Duo Push two-factor. We’re able to accomplish this by ditching the traditional shared secret model of OTP-based two-factor, which uses a symmetric key stored on the server-side to validate one-time passcodes.

Instead, we’ve opted to employ asymmetric cryptography to sign and verify all communications between Duo’s servers and a Duo Push-enabled smartphone. The irony of using RSA cryptography to secure against an RSA-style attack is not lost on us. ;-)

At provisioning time, an asymmetric keypair is generated and split, delivering the private key to the mobile device and the public key to Duo’s servers. The private key on the mobile device is used to sign all authentication responses (eg. when you tap “Approve” or “Deny” in Duo Mobile to respond to a Duo Push request), and the public key is used to verify that signature on the server side. In case of an RSA-style leak of our database, the attacker would only have access to the public key portion of the keypair, which would not allow them to generate signatures to forge Duo Push authentication responses.

If you’re an existing Duo customer, our “RSA-proof” Duo Push functionality will be enabled by default when you upgrade your Duo Mobile application. If you’re not yet a Duo customer, try it today!