4 ms·

Solely going by GP's summary, nothing needs to be 'registered with the hardware' because the public/private keypair is deterministically generated on-the-fly, c

Solely going by GP's summary, nothing needs to be 'registered with the hardware' because the public/private keypair is deterministically generated on-the-fly, cheaply, with a PRNG every time it's needed. Only two things are ever in the nonvolatile storage on the device: the secret key used as entropy to generate those keypairs, and the single global counter. The system makes it impossible for phishing sites to log in to your account using your credentials. That's the threat model it guards against. Entering 'secret information' that isn't user credentials just plain isn't part of it. Though wouldn't anyone phished by e.g. FakeGmail already get suspicious if they don't see any of their actual emails that they remember from the last time they logged in to Gmail?

SilasX 8y ago
>The system makes it impossible for phishing sites to log in to your account using your credentials. So it's an additional factor for authentication, not a way of identifying fraudulent sites to the user? Okay, but you also said: >Entering 'secret information' that isn't user credentials just plain isn't part of it. Which is it? >Entering 'secret information' that isn't user credentials just plain isn't part of it. Though wouldn't anyone phished by e.g. FakeGmail already get suspicious if they don't see any of their actual emails that they remember from the last time they logged in to Gmail? You would think, but people have definitely entered information in similar circumstances. Also, there's always "sorry, server problem showing your emails, feel free to send in the mean time".
- sigmar 8y ago
  >So it's an additional factor for authentication, not a way of identifying fraudulent sites to the user? It doesn't identify fraudulent sites (tls is the tool for that). but it won't give a properly signed login response for gmail.com to a request from the site fakegmail.com. That's a poorly worded answer to your question, but here are some slides I made to explain the specification: https://docs.google.com/presentation/d/1AkcTHahME5xY-FExm6vNVJwTSU_8u106S5DRjjHXFYk/edit?usp=sharing https://docs.google.com/presentation/d/1AkcTHahME5xY-FExm6vN...
- crunchatized 8y ago
  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”.

SilasX 8y ago

>The system makes it impossible for phishing sites to log in to your account using your credentials. So it's an additional factor for authentication, not a way of identifying fraudulent sites to the user? Okay, but you also said: >Entering 'secret information' that isn't user credentials just plain isn't part of it. Which is it? >Entering 'secret information' that isn't user credentials just plain isn't part of it. Though wouldn't anyone phished by e.g. FakeGmail already get suspicious if they don't see any of their actual emails that they remember from the last time they logged in to Gmail? You would think, but people have definitely entered information in similar circumstances. Also, there's always "sorry, server problem showing your emails, feel free to send in the mean time".

sigmar 8y ago
>So it's an additional factor for authentication, not a way of identifying fraudulent sites to the user? It doesn't identify fraudulent sites (tls is the tool for that). but it won't give a properly signed login response for gmail.com to a request from the site fakegmail.com. That's a poorly worded answer to your question, but here are some slides I made to explain the specification: https://docs.google.com/presentation/d/1AkcTHahME5xY-FExm6vNVJwTSU_8u106S5DRjjHXFYk/edit?usp=sharing https://docs.google.com/presentation/d/1AkcTHahME5xY-FExm6vN...
crunchatized 8y ago
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”.