The FIDO alliance has a working solution to the annoyance of the 2nd factor. It requires mobile device support or a hardware token (Yubikey Neo as of October supports the FIDO protocol), but it's much better than standard existing 2-factor because it doesn't require typing in a code from a dongle or app. Instead, the app or dongle authenticates directly once user presence (or in some cases, depending on the dongle or app, biometrics) are confirmed.
That means, for low-security applications, users can reuse passwords, or not have passwords, using only this second one-time-password factor, as long as they don't lose their FIDO dongle or FIDO-enabled mobile device (recovery protocols are at the discretion of different services, but a recovery code that you keep in a secure location is one way way to do it, or emails or text messages for less secure applications).
For high security applications, it avoids the annoying scrolling through a list of 2-factor accounts to get the right code, then typing it in manually.
Email or text message, even if secure (text messages are not, and emails are probably not) require internet access. Mobile internet access isn't always available when logging into a service from some other device that has a different internet connection. Similarly, the mobile network (for text messages) is not always available, either. Even if it's done through email, email service might be down; the machine used to login could be compromised so you wouldn't want to input your (hopefully very secure) email password on the same machine you're using to access some other service. If you don't have internet access via a separate more trusted device, the rationale for having 2 factor is weakened.
There's nothing preventing a FIDO-enabled service from also using email or text message for users that don't have FIDO devices, and account recovery can be done via recovery code, text, email, backup FIDO device, phone call, or a combination. It's all up to the service.
Sorry, I don't watch hour-long presentations when all I want is a bullet list of features and requirements. So I have no idea how FIDO actually works.
Here's what I will say: the best combination of security and usability would come in the form of an app that bridges an automatic communication (such as from an SMS, e-mail, or existing [https?] connection) to a TOTP token provider (either in software or hardware) and a prompt to the user to submit the token over a secured connection to the requesting provider. For internet-less use, you'd simply generate and copy the token the way Google Authenticator works now.
From the looks of the NEO & U2F yubico page, it sounds like this is similar to what they're going for; is that correct?
It uses asymmetric crypto. It generates a unique keypair for each service you register with, each key linked to a specific dns or service domain. It uses USB or NFC (and requires app, i.e. browser, support) rather than displaying a code and having the user type it in somewhere. The app or hardware key confirms user intent (by requiring a button-press or sampling biometrics), so for example a plugged-in NEO won't auto-authenticate to a site. Beyond that, it works pretty much how you'd expect.
Adding FIDO 2-factor to a service, when the browser/app stack supports FIDO, is as simple as adding a prompt and button press on the NEO to the process (either account setup, adding 2nd factor, or during login, it makes no difference). All the details of creating a keypair or authenticating to a service using a key associated with that service are under the hood.
There's nothing preventing FIDO devices from having additional requirements. They could require a PIN. They could require biometrics. They don't have to be a separate minimal hardware dongle (although, obviously, for the best security, you'd want them to be). (The S5 Paypal + FIDO demo uses the phone itself as a FIDO device, and a fingerprint swipe.)
Cool. So it is similar to what I describe, with perhaps one or two differences. For example, you say it requires app support, so.... if you're logging in through your desktop, does your desktop app need to support it? Or can your mobile handle the authentication independent of your desktop?
The reason I ask is that requiring one device to complete the authentication is less secure than two independent devices. While it's great that the NEO can plug into your desktop to auth with the browser, or that NEO plugs into your mobile to auth a mobile app, what I actually want is to start authentication on the desktop and finish it on the mobile, independently.
I don't know if that's possible with the protocol.
I guess it would require associating a key with a kind of authentication API endpoint for that service, stored on the device, and forcing the service provider to maintain that authentication API url indefinitely (or would have to force regenerating 2-factor keys when the auth endpoint changes).
It would also require that your FIDO authentication device has separate internet access (either itself or by proximity/connection to a smartphone). That's unreliable, and one of the reasons I hate it when routine authentication tokens have to be sent from the service over data links. It also takes additional effort to pick up your phone, unlock it, get to a FIDO middleware app, select the site you're authenticating to, and then completing the authentication. I don't even know if that's possible... it would require a device (computer or smartphone) to be able to enumerate accounts stored on, for example, a FIDO hardware token. That "feature" could be bad. It would also have to violate the (typical?) FIDO protocol where a hardware token is responding to a specific authentication challenge. Sending authentication authorization blind, which would be required if it were sent out-of-band from a different device, breaks the continuous thread of login attempt, then challenge, then response, then mark the user logged in [and set a browser cookie]. The separate device authenticating out of band can't know that there was even a login attempt. It could be sending authentication tokens continuously, only restricted by service-side rate limits.
> requiring one device to complete the authentication is less secure than two independent devices
What security vulnerability is there with using the same internet-connected device to authenticate with the FIDO 2nd factor, that can't also be done by malware waiting until after authentication and hijacking or doing malicious things with the account then? Is your concern about malware on the computer compromising the hardware token? Malware on a smartphone could compromise a hardware token too, in that case.
I think there's a much bigger problem: FIDO implementations that don't have a separate hardware dongle; for example, using a Samsung S5 to log into some service, and using a FIDO-enabled app that stores credentials in normal private app storage space on the S5 itself. A secure computing enclave (like on Apple phones, does the S5 or any android have that) makes that marginally acceptable, but far from ideal.
This actually makes malware less of an issue, because you'd need to target both a desktop and a mobile device of a particular user in order to MITM. The only things that are happening 'automatically' is the request being sent to the user's mobile device, and the entire process can be verified cryptographically to ensure an attacker doesn't send a false request.
(HTTPS)
Client -> Server: LOG ME IN PLEASE
Server -> Client: Do you have a cookie?
Client -> Server: NO, BUT HERE's MY PASSWORD
Server -> Client: I've just sent you a request for an additional auth token. Please confirm it to log in. And please stop shouting.
(Email, SMS, HTTPS)
Server -> Client's Mobile Device: Here's a token. Sign it with some crap you've already got and give it back to me.
CMD generates new token after confirming origin of original request; uses software, or talks to hardware token.
(App, Website)
CMD -> User: IS THIS REQUEST OKAY? CAN I SEND THIS THING?
User -> CMD: Yeah sure, I requested this login. *pushes button*
(HTTPS)
CMD -> Server: HERE'S YOUR NEW SIGNED TOKEN
Server -> CMD: Thanks. Here's a cookie to remember me by.
Server -> Client: Page refresh! We got the right token from your mobile device, so here's your new cookie, you're logged in.
The only major security pitfalls here are in how you deliver either an app or a website to a user remotely, but there's plenty of good ways to do that already. You can even use boring old existing PKI.
You're not sending authorization "blind", though. You have to request the login from one device with a password, and approve it from another with a button push. In this way, only logins that you requested get sent to you, and only requests you approve get sent back, and both devices would have to be hacked by an attacker to intercept either part of the authentication process. Well, unless they both have your cracked password and inject malware on your mobile. Perhaps putting the button-pressy part on the hardware keyfob is safer :)
Even if none of this were cryptographically signed, look at the typical 2-factor SMS with this process. A user attempts a login and a text is sent to them with a code. The user then puts this code back into the login screen and presses return. If they could simply press a button on their phone they could approve the login without having to type the code in. Of course, we want to require a button press, because an automatic login means anyone who initiates the login (like an attacker with a stolen password) could log in automatically. And what i'm proposing is basically this, but with actual secure connections instead of SMSes or e-mails, and the ability to confirm on the device that the request was legit and not part of an elaborate phishing expedition.
All of this would work without a data connection because you could use QR codes to enter the challenge token into the device and it would spit out the response in a variety of formats.
I don't think FIDO conflicts with what you want to do. It simply doesn't mandate it.
If you wanted a 2nd channel confirmation like that, I suppose you could set up the service to link a mobile device (there might even eventually be some FIDO app that accepts FIDO challenge push notifications in a way that's not service-specific). Then FIDO would be used exclusively on the second channel (parenthentical stages 2, 3, 4 in your example). The web interface in that kind of setup would have nothing to do with FIDO.
I don't understand the MITM malware threat model you're envisioning that can hijack an in-band public key crypto exchange, but that can't simply hijack the session on the browser after you've completed (validly) the out of band verification.
Some of the complexity of FIDO is there to enable reasonably secure single-channel authentication (as might be expected, there are trade-offs between easy SSO and subdomain/origin policy security). But I think FIDO would still be valuable if you wanted to do out of band confirmation without a browser. The hardware dongles are standardized (although the requirements to unlock a key can vary from a button press like on the NEO to, hypothetically, biometrics in advanced dongles). Mobile apps would also be standardized, much like TOTP is now, so you could use any FIDO app with any FIDO dongle (or no dongle, if an app offers less secure on-phone secret storage). Without a hardware standard, you either have to store secrets on the mobile device, or you run into the existing problem of needing N hardware dongles for N services.
That means, for low-security applications, users can reuse passwords, or not have passwords, using only this second one-time-password factor, as long as they don't lose their FIDO dongle or FIDO-enabled mobile device (recovery protocols are at the discretion of different services, but a recovery code that you keep in a secure location is one way way to do it, or emails or text messages for less secure applications).
For high security applications, it avoids the annoying scrolling through a list of 2-factor accounts to get the right code, then typing it in manually.
Email or text message, even if secure (text messages are not, and emails are probably not) require internet access. Mobile internet access isn't always available when logging into a service from some other device that has a different internet connection. Similarly, the mobile network (for text messages) is not always available, either. Even if it's done through email, email service might be down; the machine used to login could be compromised so you wouldn't want to input your (hopefully very secure) email password on the same machine you're using to access some other service. If you don't have internet access via a separate more trusted device, the rationale for having 2 factor is weakened.
A good presentation on FIDO is here: http://www.yubico.com/2014/07/future-online-authentication/
There's nothing preventing a FIDO-enabled service from also using email or text message for users that don't have FIDO devices, and account recovery can be done via recovery code, text, email, backup FIDO device, phone call, or a combination. It's all up to the service.