4 ms·

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

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
    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.

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
  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.