I wonder, how is the Duo Push secure?


I wonder, how is the Duo Push secure, compared to challenge-response systems?

One problem I have seen with “push based” authentication system without any challenge input, is that a fraudster could call the victim and say like “hey im calling from the bank, there is fraudulent charges on your account, login to your account and see for yourself”.
The victim initiates a login, but at the same time, the fraudster also initate a login to the victim’s account at the same time.

If the fraudster times this right, the Duo Push prompt will be for logging the fraudster to the account, while the victim thinks its for himself. And the victim didn’t do anything “wrong” security-wise, as the victim did as you should do, never follow any links or adresses a fraudster sends, but instead type the correct URL and login itself to verify if the information given, is correct.

Why isn’t some challenge requested in Duo Push? It could be a 4 digit code on computerscreen, that the user enters into the mobile, in the Duo Push request to “Allow”. If the 4 digit code entered, does not match the 4 digit code contained in the actual push login request, the login request is automatically rejected. (because obviously, then its a mismatch between the push request and the session the user intends to authenticate).


Hi Sebastian,

I think it’s important to distinguish between the security of Duo Push authentications and possible complex malicious attacks involving social engineering that would involve the second factor of authentication.

Duo Push is end-to-end encrypted and a very secure, out-of-band method of two-factor authentication. You can read more about its encryption here: https://help.duo.com/s/article/3252.

As you correctly point out, malicious actors with access to compromised primary credentials could attempt to trigger a push authentication to trick end-users into providing access. We’re very interested in preventing this kind of attack. The push confirmation screen in Duo Mobile currently displays contextual information regarding the application and location from which the request is being initiated to help mitigate this type of attack.

In addition, our development teams are actively working on additional enhancements to Duo Mobile to further help end-users avoid being targeted in this way. While I cannot share details or mockups publicly at this time, please know that we’re constantly working to enhance the security of this already very secure authentication method.


What about my idea?

To differentiate, we will call the channel that is being authenticated, as the “insecure” channel, and the channel the authenticator resides in, the “secure” channel.

After primary authentication has been done, show a random PIN code on-screen, on the “insecure” channel.
In the push request, send the same PIN code encrypted to the device., over the “secure” channel.

The Duo app requests the PIN code, and will “allow” only if the entered PIN code match the PIN-code in the push request. If the PIN codes mismatch, “disallow” the authentication request automatically. This binds the insecure channel hard to the secure channel.

Something like this (made the picture in paint, so you understand the idea):

And then when clicking “Send push request”, it will tell “Push request sent, Enter PIN code 3782 in your device” (where 3782 is a random code).

For those users that use the device PIN code as authentication to Duo Push, it could be wise to display a 4+[Device PIN length] passcode prompt, and say like “Push request sent, Enter PIN code 3782 followed by your device PIN in your device. (or enter PIN 3782 and authenticate with touch ID)”

So if a user has device PIN 9214, they would enter 37829214 as PIN, or enter 3782 (and leave 4 rings empty) and then touch finger.
To make this user-firendly, a touch ID icon or similiar, could be greyed out until at least 4 digits are entered, and then lights up to tell that you can either finish authentication by using touch ID, or continue entering digits to authenticate by device PIN. Of course touch ID should be made available even if a incorrect on-screen PIN is entered (but then, using touch ID would result in a “Disallow” action sent back).

And now to some more threat scenarios, not only the phone call one, which this are designed to prevent:
::CASE A::
Imagine you are sitting at a public café. Or a internet café. Or a computer in the library. Or you are just sitting in the park with your computer connected to mobile 3G.
Regardless, you are sitting in a location so a adversiary could observe you, either by a binocular or oculary.

Now the adversiary does have access to the primary credentials. Since the adversiary could observe you, it means the adversiary could observe you beginning a login, and then do a “race attack” to get to send the push request first. Since the adversiary and the victim is roughtly on the same location, the details in the Duo Push application will not make you any smarter.
And since the user will think its his request, he will approve it, instead approving the adversiarys push request.

::CASE B::
Imagine now the network is being eavesdropped by a attacker. Note that the attacker does NOT need to break SSL/TLS, and does NOT need to see the data. The only thing a adversiary needs to see, is the host or IP the user is contacting.
This attack could be mitiaged by using a VPN, but note that if Duo Push is used to establish that VPN, the connection to the VPN itself will reveal that the user are attempting a login. This means a VPN without Duo Push, preferably at a third party, needs to be used.

The attacker observes a DNS request or a TCP connection to the login service (like: login.acme.com).
Note that even if the connection is protected by SSL or TLS, the attacker can observe the host name by checking SNI information.
Now the attacker waits time T, where time T is a well tought out time to “race attack” the user, and then sends his own request using the user’s primary credentials. Note here that the same applies here, the attacker is close to the user, and the “verifying data” inside Duo push will not help.
The time T, which is the time the user uses to complete primary authentication, can be collected by allowing the user to do the authentication, but then denying the service, by for example flooding the user with packets, so the user reattempts the authentication. Now the attacker, by listening in on connections only, have recorded the time T, and can do a precise race attack.

Now the user will too think the authentication request belongs to himself and allow it.

Imagine my PIN idea was implemented in the above scenarios:
When the adversiary begins the “race attack”, the user will see on screen: PIN code “3992”, when the user initates HIS push request. He enters this into the push app. Since this push request was initiated for the same user, but by the adversiary a few seconds before, the PIN code expected will be “9187”, which the adversiary got on his screen. PIN code mismatch. Authentication “Disallowed”.


Your extensive writeup (and design) are super appreciated, Sebastien! I’ll pass them along to our mobile development team.

While I can’t share the exact mechanisms at this time, we are working on a solution that will provide enhanced security in this and similar scenarios while maintaining the ease of use that makes Duo Mobile such a popular auth method.