3 ms·

Since the hard keys are tied to users and implement origin binding, even a sophisticated, real-time phishing operation like this cannot gather the information n

Since the hard keys are tied to users and implement origin binding, even a sophisticated, real-time phishing operation like this cannot gather the information necessary to log in to any of our systems. I'm struggling to figure out what this means and how it works. A cursory Googling didn't help.

mirashii 4y ago
https://webauthn.guide/ https://webauthn.guide/ has a lot of detail if you want to go into it, but what they're referencing here is the "rp" or "relying party" field that's used as part of the credential setup. This uses browser APIs to share the origin of the credentials stored with your hardware token to guarantee that your private key is only used when visiting that same service. This is as opposed to TOTP as a second factor where you're relying on the user to verify that they're not putting it into a phishing website.
elchief 4y ago
setup yubikey with domain.com login to domain.com enter username/password to domain.com, it then demands domain.com yubikey authn token. yubikey provides only if on domain.com login to fakedomain.com enter username/password to fakedomain.com, it then demands domain.com yubikey authn token. yubikey does not provide because not on domain.com. or it demands fakedomain.com token, but yubikey doesn't have it so, in that way, yubikeys (and similar) are immune to phishing, unlike say google authenticator
kevin_b_er 4y ago
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.
g_p 4y ago
Keys tied to users -- during registration, an authenticator generated a new ECDSA key locally, and offloads it to the PC, to be sent to the server. The public component is exported in plaintext and is the verifier data. The private component is sealed by symmetric encryption using a key held only on your device. Part of the sealing includes the canonical representation of the domain, protocol and port for the site in question. Origin binding -- When you visit a site you used before, the site sends you the encrypted blob offloaded private key. Your token verifies it and decrypts it, and signs a challenge using the key and sends that back to the server as a response, to be verified using the stored public key. Part of this unsealing process ties it to the domain, protocol and port of the origin site making the request, so if a phishing site acts as a relay, your token won't generate a valid response, since the phishing site origin differs and the offloaded private key won't decrypt. If you look at the threat model here, if your token and its implantations of crypto are secure, you really need to get rogue software onto the client device, which can send arbitrary requests over USB to your security token device, and trick the user into proceeding. At that point it's "game over" as you have code execution on the endpoint and there's other ways to achieve your goals from there.

mirashii 4y ago

https://webauthn.guide/ https://webauthn.guide/ has a lot of detail if you want to go into it, but what they're referencing here is the "rp" or "relying party" field that's used as part of the credential setup. This uses browser APIs to share the origin of the credentials stored with your hardware token to guarantee that your private key is only used when visiting that same service. This is as opposed to TOTP as a second factor where you're relying on the user to verify that they're not putting it into a phishing website.

elchief 4y ago

setup yubikey with domain.com login to domain.com enter username/password to domain.com, it then demands domain.com yubikey authn token. yubikey provides only if on domain.com login to fakedomain.com enter username/password to fakedomain.com, it then demands domain.com yubikey authn token. yubikey does not provide because not on domain.com. or it demands fakedomain.com token, but yubikey doesn't have it so, in that way, yubikeys (and similar) are immune to phishing, unlike say google authenticator

kevin_b_er 4y ago

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.

g_p 4y ago

Keys tied to users -- during registration, an authenticator generated a new ECDSA key locally, and offloads it to the PC, to be sent to the server. The public component is exported in plaintext and is the verifier data. The private component is sealed by symmetric encryption using a key held only on your device. Part of the sealing includes the canonical representation of the domain, protocol and port for the site in question. Origin binding -- When you visit a site you used before, the site sends you the encrypted blob offloaded private key. Your token verifies it and decrypts it, and signs a challenge using the key and sends that back to the server as a response, to be verified using the stored public key. Part of this unsealing process ties it to the domain, protocol and port of the origin site making the request, so if a phishing site acts as a relay, your token won't generate a valid response, since the phishing site origin differs and the offloaded private key won't decrypt. If you look at the threat model here, if your token and its implantations of crypto are secure, you really need to get rogue software onto the client device, which can send arbitrary requests over USB to your security token device, and trick the user into proceeding. At that point it's "game over" as you have code execution on the endpoint and there's other ways to achieve your goals from there.