App-based 2FA versus Hardware-based 2FA

Question

How do apps like Symantec VIP / Okta Verify and similar implementations compare to using a hardware auth token such as the recent U2F devices?

How real is the possibility of an Android system being hijacked and 2FA app authentication tokens or otherwise secret keys being extracted?

Besides not needing another device, are there any other advantages to app-based 2FA?

Given that with app-based 2FA you authenticate a request or login session in real-time, is it not vulnerable to real-time authentication replay phishing attacks?

Edit: This seems to be sort-of answered here Can a smartphone strictly be viewed as the 'something you posses' factor for 2FA when it has no hardware token capability like smartcards?

Answer 1

Have a look at this answer here for more detail. But here's the salient bits for your question:

The problem with 2-factor as implemented by Symantec VIP and Okta Verify has less to do with the fact that it's implemented in software, and more to do with the fact that the code can be intercepted.

In this sense, Symantec VIP, Okta Verify, and RSA SecurID are all in the same boat as Google Authenticator; none of them will protect you from phishing because the same technique the attacker uses to get your password can also be used to get your 2nd factor code; usually by getting you to type it into a fake login page.

But U2F is different.

With U2F, you don't type in a one-time-password to show you have your token. Instead, the browser communicates directly with the hardware token, and part of the process is that the browser tells the hardware token the hostname of the site that is requesting identification, and 2FA identities are tied to the individual host. And the browser (unlike the user) cannot be fooled regarding which host is requesting authentication because the browser checks the TLS certificate.

This means that an attacker's website can't get the correct 2nd factor code, and it means that even if a clever social engineering attacker managed to trick a user into giving up their password, the user can't give up their 2nd factor code.

The 2nd factor token can ONLY be used if the browser is communicating with the correct site, and only if the browser is physically connected to the U2F token. This pretty much eliminates any attack that doesn't involve the physical theft of the victim's hardware.

U2F could be implemented (and has been) in software, so you're depending on software on your computer rather than a physical device. This is still better than OTP-based 2FA such as Symantec VIP for phishing resistance, but in this case physical theft is no longer a requirement for exploitation. Instead, if your token is implemented in software, then any intrusion on your computer (virus, etc.) could make a copy of your authentication device and use it on their computer without your knowledge. So it's not quite as good as a physical device, but it's a lot less expensive.

Answer 2

How do apps [...] compare to using a hardware auth token [...]?

At first sight, they don't differ too far. Well in both cases you have some other device which does an additional cryptographic verification step for you. But one important difference is the complexity of the system (the whole software on that device).

On a smart phone there is a heck lot of interacting pieces of software form different vendors (apps), while a dedicate authentication token is there far simpler since the serve just this single one purpose. Therefore, the chance and surface for vulnerability is generally lower for the simpler system.

Another difference would be the actual algorithm used for that authentication step. But this does not depend anyhow on the hardware. However, apps tend to be simpler e.g. Time-based One-Time Password generators, while the others are usually more sophisticate about their sole purpose, for instance U2F uses challenge based Public key cryptography. BTW that's one reason why using U2F requires also support from the browser to forward the challenge to the U2F stick.

How real is the possibility of an Android system being hijacked [...] and [...] secret keys being extracted?

Well it is real that you can hack a mobile phone like every other computer system and gain root access to it. If a key can be extracted, depends on how the app stores that secret. But since it has to save it and since there is no real private memory on Android devices (AFAIK), an attacker which gained root access could copy the key.

[...] are there any other advantages to app-based 2FA?

On a plain security level, I don't believe there is any advantage for smart phones vs. dedicated hardware. But apps are usually far easier to install and setup than those specialized systems. And a system which is to complicated to be used by an average user, doesn't improve anything in a real world. Also notice that those special systems need usually additional service provider support, an if a technique is to complicated to be implemented or hardly used, the best user can't do anything without supported services.

Given that [...] you authenticate a request or login session in real-time, is it not vulnerable to real-time authentication replay phishing attacks?

As far as I can see it, you can generally do a Man-in-the-middle attack and hijack the authenticated session. But that's what SSL-certificates intend to prevent. And it is accompanied by encryption which limit the usability of simple replay attacks. A part form SSL, replay on time-based tokens is a possibility. However, a service provider could enlist the successfully used tokens and prevent replays. Still, if the attacker were fast enough he would be the one having succeed.