5 ms·

What contradiction? It just plain isn't part of the threat model. Was that not clear? Although, actually reading the spec, it can actually double as a bit of e

What contradiction? It just plain isn't part of the threat model. Was that not clear? Although, actually reading the spec, it can actually double as a bit of extra authenticator of the website. Any site has to first request registration (client uploads a new, unique, opaque key handle/'credential id' to the server, along with its matching public key) before it can request authentication (server provides credential id and challenge, client signs challenge). A credential ID is a unique nonce from the device's global counter, signed by a MAC. The real site will already have a registered credential ID, which the device will take, verify it, and use the nonce to HMAC the private key back into existence. A phishing site you've never visited before will have no credential ID. Any fake ones it tries to generate will be rejected since the MAC would be invalid. One from the real website won't be accepted either, because the MAC incorporates the website's domain, too. They'd have to get user consent to create a new key pair entirely, which a user could notice is completely different from what's normally requested at login. Then they'd have to consent again to actually authenticate. https://developers.yubico.com/U2F/Protocol_details/Key_generation.html https://developers.yubico.com/U2F/Protocol_details/Key_gener... https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-overview-v1.2-ps-20170411.html https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fid...

SilasX 8y ago
>A phishing site you've never visited before will have no credential ID. Any fake ones it tries to generate will be rejected since the MAC would be invalid. That was my original question: presumably there has to be some way for new websites to be registered on the system. Does it just categorically reject anything not on a predefined list? I mean, there are legit reasons to visit not-github! And new sites need to be added. In order to say something is “fake”, that has to be defined relative to some “real” site you intend to visit, and I don’t see how this system even represents that concept of “the real” site. Phishing works on the basis that the site looks like the trusted one except that I’ve never been to it. Put simply: I click on a link that takes me to a site I’ve never been to. Where does this system intervene to keep me from trusting it with information that I intend to give to different site, given that the new site looks like the trusted one, and my computer sees it as “just another new site”? >What contradiction? It just plain isn't part of the threat model. Was that not clear? Not at all. You said it “stops phishing sites from using your credentials to log in”. That implies some other secret that’s necessary to log in (making the original credentials worthless in isolation), and yet the next quote rejected that. If you were just repeating a generic statement of the the system’s goals, which wasn’t intended to explain how it accomplishes them, then I apologize for misunderstanding, but them I’m not sure how that was supposed to clarify anything. Late edit: as in the other thread, I think I’m just being thrown off by this being mislabeled as a phishing countermeasure, when it’s just another factor in authentication that also makes use of phished credentials harder. Not the same as direct “detection of fake sites”.
- crunchatized 8y ago
  There doesn't technically have to be a way to register new sites. There is, but theoretically there never actually had to be, given keys are generated deterministically on-demand, using the website's domain name effectively as a salt. There's no system with a list of websites. The signed challenge-response you give to the phishing site cannot be forwarded to the real site and accepted, because you used the domain name as part of your response, and as part of key generation, so it doesn't match. That's all that meant. 'Credentials' included the use of a public/private key, not just the typed password.
  - tialaramex 8y ago
    No! Registration is important. What you've described would be subject to an enumeration attack. During Registration the Relying Party (web site) picks some random bytes, and sends those to the Client (browser). The Client takes those bytes, and it hashes them with the site's domain name, producing a bunch of bytes that are sent to the Security Key for the registration. The Security Key mixes those bytes with random bytes of its own, and produces an entirely random private elliptic curve key, let's call this A, the Security Key won't remember what it is for very long. It uses that private key to make a public key B, and then it _encrypts_ key A with its own secret key (let's call that S, it's an unchangeable AES secret key baked inside the Security Key) to produce E The Security Key sends back E, B to the Client, which relays them to the Relying Party, which keeps them both. Neither the Client nor the Relying Party know it, but they actually have the private key, just it's encrypted with a secret key they don't know and so it's useless to them. When signing in, E is sent back to the Client, which gives it to the Security Key, which decrypts it to find out what A was again and then uses A to sign proof of control with yet more random bytes from the Relying Party. This arrangement means if Sally, Rupert and Tom all use the same Security Key to sign into Facebook, Facebook have no visibility of this fact, and although Rupert could use that Key to get into Sally's account, the only practical way to "steal" the continued ability to do so would be to steal the physical Security Key, none of the data getting sent back and forth in his own browser can be used to mimic that.
    - 8y ago

SilasX 8y ago

>A phishing site you've never visited before will have no credential ID. Any fake ones it tries to generate will be rejected since the MAC would be invalid. That was my original question: presumably there has to be some way for new websites to be registered on the system. Does it just categorically reject anything not on a predefined list? I mean, there are legit reasons to visit not-github! And new sites need to be added. In order to say something is “fake”, that has to be defined relative to some “real” site you intend to visit, and I don’t see how this system even represents that concept of “the real” site. Phishing works on the basis that the site looks like the trusted one except that I’ve never been to it. Put simply: I click on a link that takes me to a site I’ve never been to. Where does this system intervene to keep me from trusting it with information that I intend to give to different site, given that the new site looks like the trusted one, and my computer sees it as “just another new site”? >What contradiction? It just plain isn't part of the threat model. Was that not clear? Not at all. You said it “stops phishing sites from using your credentials to log in”. That implies some other secret that’s necessary to log in (making the original credentials worthless in isolation), and yet the next quote rejected that. If you were just repeating a generic statement of the the system’s goals, which wasn’t intended to explain how it accomplishes them, then I apologize for misunderstanding, but them I’m not sure how that was supposed to clarify anything. Late edit: as in the other thread, I think I’m just being thrown off by this being mislabeled as a phishing countermeasure, when it’s just another factor in authentication that also makes use of phished credentials harder. Not the same as direct “detection of fake sites”.

crunchatized 8y ago
There doesn't technically have to be a way to register new sites. There is, but theoretically there never actually had to be, given keys are generated deterministically on-demand, using the website's domain name effectively as a salt. There's no system with a list of websites. The signed challenge-response you give to the phishing site cannot be forwarded to the real site and accepted, because you used the domain name as part of your response, and as part of key generation, so it doesn't match. That's all that meant. 'Credentials' included the use of a public/private key, not just the typed password.
- tialaramex 8y ago
  No! Registration is important. What you've described would be subject to an enumeration attack. During Registration the Relying Party (web site) picks some random bytes, and sends those to the Client (browser). The Client takes those bytes, and it hashes them with the site's domain name, producing a bunch of bytes that are sent to the Security Key for the registration. The Security Key mixes those bytes with random bytes of its own, and produces an entirely random private elliptic curve key, let's call this A, the Security Key won't remember what it is for very long. It uses that private key to make a public key B, and then it _encrypts_ key A with its own secret key (let's call that S, it's an unchangeable AES secret key baked inside the Security Key) to produce E The Security Key sends back E, B to the Client, which relays them to the Relying Party, which keeps them both. Neither the Client nor the Relying Party know it, but they actually have the private key, just it's encrypted with a secret key they don't know and so it's useless to them. When signing in, E is sent back to the Client, which gives it to the Security Key, which decrypts it to find out what A was again and then uses A to sign proof of control with yet more random bytes from the Relying Party. This arrangement means if Sally, Rupert and Tom all use the same Security Key to sign into Facebook, Facebook have no visibility of this fact, and although Rupert could use that Key to get into Sally's account, the only practical way to "steal" the continued ability to do so would be to steal the physical Security Key, none of the data getting sent back and forth in his own browser can be used to mimic that.
  - 8y ago