4 ms·

I'm not familiar with FIDO2's changes, but FIDO1/U2F stuff. What happens is the browser signs the request to the security token with the website URL. The secur

I'm not familiar with FIDO2's changes, but FIDO1/U2F stuff. What happens is the browser signs the request to the security token with the website URL. The security token's response based on the secret includes this as a result. So if you try to login to d0main.com instead of domain.com and get a U2F 2nd factor auth, the browser will generate a request based on d0main.com. Even if the malicious site, d0main.com, copied/repeated the public key info for the second factor auth request from domain.com, the browser would hash and sign the request as coming from d0main.com as a result. The resulting login token would not match up with what domain.com expected. The login would fail. So the beauty of this protocol is that, by having the browser be a trusted intermediary, you have to login to the correct website for the 2-factor U2F token to create the right response. You cannot be phished unless you can trick the browser as well into signing your malicious site's request with the real domain/url. This does not work with 'enter a code', sms, or those apps that prompt you to say you approve of the login. All of those are subject to an attack where the legitimate login system gets proxied by an attacker. Unsure how FIDO2 stuff changes this.

tialaramex 4y ago
FIDO2 can optionally support "usernameless" login. After enrolling, your authenticator can keep all the details it needs to authenticate you somewhere, and then "logging in" becomes go to the right site and use your fingerprint or whatever on the authenticator. No step where you type in an email address or anything like that, you are you and your authenticator knows exactly who that is. With FIDO1 nothing lives on the authenticator. If I drop my authenticator on the subway, and you find it, unless you somehow guess my identity and try to log in as me, the authenticator gives you no clue (I mean if I wrote my name on it in Sharpie that would tell you, but the technology itself doesn't) and you can just use that authenticator, might as well, free authenticator. Probably a bad idea if you're Edward Snowden but for Mr Average it's safe. But with FIDO2 your actual credentials can live on the authenticator, which means it knows (in some sense) who you are. On the other hand this mode should be protected with a second factor (since the authenticator itself is no longer the second factor) such as a fingerprint sensor, or maybe a PIN lock. You got the effect of FIDO1 right, but the mechanism is a bit cleverer. On a cheap device this is relying on Authenticated Encryption. When a site says "Prove you're still you" to a FIDO1 authenticator it needs to provide a huge "Identifier". Well, for the cheap devices (maybe not an iPhone, but say a Yubikey) that "identifier" isn't really just a very large index into a table, they've only got a tiny amount of flash. Instead it's actually your private key for that website encrypted by the authenticator using its own symmetric key, and the AE is used to confirm it is the correct website. If it wasn't the key doesn't decrypt and that's exactly the same scenario as if you plugged in the wrong authenticator, a thing people do all the time. From the authenticator's point of view, suppose you've got a nice red authenticator and also a blue one. You have enrolled the blue one at Facebook but not the red. Let's see three scenarios 1a. You forget and try to use the red authenticator to sign in to the real Facebook 1b. Facebook says prove you're still some-huge-ID-made-by-the-blue-token-for-Facebook 1c. Your red token tries to decrypt the ID, using its own symmetric key, and the knowledge this is for facebook.com, the Authentication Encryption says... No. 1d. Your browser says nope, try a different token? 2a. You are being phished and try to use the blue authenticator to sign in to Fakebook 2b. Fakebook sends over the identifier from the real Facebook site, some-huge-ID-made-by-the-blue-token-for-Facebook 2c. Your blue token tries to decrypt the ID, using its own symmetric key, and the knowledge this is for fakebook.com, the Authentication Encryption says... No. 2d. Your browser says nope, try a different token? 3a. This time you remembered to use the blue authenticator to sign in to the real Facebook 3b. Facebook says prove you're still some-huge-ID-made-by-the-blue-token-for-Facebook 3c. Your blue token tries to decrypt the ID, using its own symmetric key, and the knowledge this is for facebook.com, the Authentication Encryption says... Yes. 3d. Your token can sign an "I'm still me" message for Facebook using the Private Key it got back with the Authenticated Encryption. You get into Facebook. To support all this, the remote sites should keep a list of up to say half a dozen authenticators you've enrolled, and it should hand over the full list on each sign-in. "Do you have any of these?". Your browser polls each authenticator with each ID, "Hey, authenticator, is this one yours?" if any of them say Yes, we're done, proof provided. Otherwise, tell the user none of the tokens worked, do they have others? For enrollment a similar strategy is used. The site hands over all the IDs it already has and the browser says "Hey, do you recognise these IDs?" if an authenticator recognises one of the IDs then we enrolled that one already, look for one that doesn't recognise any IDs, that one should be enrolled.

tialaramex 4y ago

FIDO2 can optionally support "usernameless" login. After enrolling, your authenticator can keep all the details it needs to authenticate you somewhere, and then "logging in" becomes go to the right site and use your fingerprint or whatever on the authenticator. No step where you type in an email address or anything like that, you are you and your authenticator knows exactly who that is. With FIDO1 nothing lives on the authenticator. If I drop my authenticator on the subway, and you find it, unless you somehow guess my identity and try to log in as me, the authenticator gives you no clue (I mean if I wrote my name on it in Sharpie that would tell you, but the technology itself doesn't) and you can just use that authenticator, might as well, free authenticator. Probably a bad idea if you're Edward Snowden but for Mr Average it's safe. But with FIDO2 your actual credentials can live on the authenticator, which means it knows (in some sense) who you are. On the other hand this mode should be protected with a second factor (since the authenticator itself is no longer the second factor) such as a fingerprint sensor, or maybe a PIN lock. You got the effect of FIDO1 right, but the mechanism is a bit cleverer. On a cheap device this is relying on Authenticated Encryption. When a site says "Prove you're still you" to a FIDO1 authenticator it needs to provide a huge "Identifier". Well, for the cheap devices (maybe not an iPhone, but say a Yubikey) that "identifier" isn't really just a very large index into a table, they've only got a tiny amount of flash. Instead it's actually your private key for that website encrypted by the authenticator using its own symmetric key, and the AE is used to confirm it is the correct website. If it wasn't the key doesn't decrypt and that's exactly the same scenario as if you plugged in the wrong authenticator, a thing people do all the time. From the authenticator's point of view, suppose you've got a nice red authenticator and also a blue one. You have enrolled the blue one at Facebook but not the red. Let's see three scenarios 1a. You forget and try to use the red authenticator to sign in to the real Facebook 1b. Facebook says prove you're still some-huge-ID-made-by-the-blue-token-for-Facebook 1c. Your red token tries to decrypt the ID, using its own symmetric key, and the knowledge this is for facebook.com, the Authentication Encryption says... No. 1d. Your browser says nope, try a different token? 2a. You are being phished and try to use the blue authenticator to sign in to Fakebook 2b. Fakebook sends over the identifier from the real Facebook site, some-huge-ID-made-by-the-blue-token-for-Facebook 2c. Your blue token tries to decrypt the ID, using its own symmetric key, and the knowledge this is for fakebook.com, the Authentication Encryption says... No. 2d. Your browser says nope, try a different token? 3a. This time you remembered to use the blue authenticator to sign in to the real Facebook 3b. Facebook says prove you're still some-huge-ID-made-by-the-blue-token-for-Facebook 3c. Your blue token tries to decrypt the ID, using its own symmetric key, and the knowledge this is for facebook.com, the Authentication Encryption says... Yes. 3d. Your token can sign an "I'm still me" message for Facebook using the Private Key it got back with the Authenticated Encryption. You get into Facebook. To support all this, the remote sites should keep a list of up to say half a dozen authenticators you've enrolled, and it should hand over the full list on each sign-in. "Do you have any of these?". Your browser polls each authenticator with each ID, "Hey, authenticator, is this one yours?" if any of them say Yes, we're done, proof provided. Otherwise, tell the user none of the tokens worked, do they have others? For enrollment a similar strategy is used. The site hands over all the IDs it already has and the browser says "Hey, do you recognise these IDs?" if an authenticator recognises one of the IDs then we enrolled that one already, look for one that doesn't recognise any IDs, that one should be enrolled.