3 ms·

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 s

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. A good presentation on FIDO is here: http://www.yubico.com/2014/07/future-online-authentication/ 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.

peterwwillis 12y ago
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?
- harshreality 12y ago
  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.)
  - peterwwillis 12y ago
    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.
    - harshreality 12y ago
      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.

peterwwillis 12y ago

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?

harshreality 12y ago
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.)
- peterwwillis 12y ago
  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.
  - harshreality 12y ago
    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.