3 ms·

Wouldn't these fall under the "something you know" factor? (It's something you gave during registration, versus something they gave to you, right?) If so, isn't

Wouldn't these fall under the "something you know" factor? (It's something you gave during registration, versus something they gave to you, right?) If so, isn't a public key just a really long password? Why not just let people use really long randomly-generated passwords stored in a password manager?

ecesena 4y ago
Something you know is long gone, even passwords right now are something you have: your password manager. Unlike passwords, passkeys use public key cryptography. The server (e.g. Github) only stores your public key. You have the private key (e.g. in your phone). If the server leaks data, there's no way for an attacker to reconstruct the private key. Moreover, kind of by design, you're going to have a different passkey per site. These two properties are very similar to using strong and unique passwords across sites that you can really trust. Note that with passwords you have to trust the site (to handle your password securely), with passkeys you get that for free. The real new property is phishing resistance. When you log in with a passkey, the hostname of the website that you're visiting is signed as part of the auth data that's sent to the server. If you're on github.com, your auth data will contain a signature on github.com; if you're on a phishing site fake-github.com, the data will contain fake-github.com -- the phisher/attacker will get this second data. If the phisher/attacker tries to reuse your auth data on the real github.com, the verification will fail (it's probably easier to picture than to explain...). With passwords, you get phished.
- postalrat 4y ago
  Something you know is often a pin to unlock your local stuff. Some hardware tokens (via webauthn) require a pin to work.
  - ecesena 4y ago
    I agree. I meant to say that you can no longer just have "something you know", you also need "something you have". Wether this is already or not 2FA it's a bit debatable. Apple says yes and I tend to agree. From the server's perspective, however, it can only verify 1 factor and it has to trust the client to implement the 2nd factor securely (whether it's a pin, fingerprint, face id, etc.)
  - g_p 4y ago
    In the current design of most security tokens, a PIN is not really a "something you know" factor per-se - it instead unlocks a "something you have" factor. That sounds counter-intuitive, but few (if any) security tokens actually include your user PIN in the cryptography. The same is generally (as far as I know) true in the smartcard space. You rely on hardware attacks being expensive, costly, detectable through physical damage, and not very likely to succeed, in order to protect the physical token. That physical token then (likely) holds the plaintext PIN, or a simple hash of it (which would likely be instantly crackable for numeric PINs). Therefore the PIN is really an access control mechanism for the "something you have" - an asymmetric signature from a hardware token, where access to generate the signature is controlled by the PIN, arguably doesn't actually incorporate the knowledge element in verification, since a compromised hardware token can still generate the signature without the PIN. (FWIW the user you replied to developed the software for a Webauthn key, so may be able to correct/elaborate on the above).
    - postalrat 4y ago
      The pin might be stored in plaintext but should be stored in some sort of secure location on a chip that can't be accessed physically or through brute force. One strategy to prevent brute force the chip may only allow X tries before wiping itself. So the "something you have" is only something you have if you also have the pin. There are already 2 factors baked in.
g_p 4y ago
There's 2 main reasons they differ from "something you know": 1) A passkey isn't phishable, as it's a digital signature that wraps the origin domain that is requesting the passkey. That means a phishing site can't "request" a valid passkey for another site, and replay it to gain access. This helps "normal users" who could be tricked into entering the MS/Google login on a credible-looking SSO portal, and approving the MFA request - a passkey will stop this. 2) You authenticate via a non-replayable signature. If the site's backend database is dumped, nothing is learned - nobody gets even a hash of a password. The stored data is guaranteed to be unique to that site (different public key for every account you make, even on the same site). You can't use it against other sites. If the site checks logs and can be confident the database wasn't tampered with, then after a compromise, they can continue to rely on webauthn logins - just because you saw someone's public key and encrypted offloaded private key doesn't help you log in as them. In contrast, with stored password hashes, users with weak or re-used passwords are at particular risk in this case, and you likely want to force them in through the reset password route, rather than let the attacker used a brute-forced or otherwise leaked password.

ecesena 4y ago

Something you know is long gone, even passwords right now are something you have: your password manager. Unlike passwords, passkeys use public key cryptography. The server (e.g. Github) only stores your public key. You have the private key (e.g. in your phone). If the server leaks data, there's no way for an attacker to reconstruct the private key. Moreover, kind of by design, you're going to have a different passkey per site. These two properties are very similar to using strong and unique passwords across sites that you can really trust. Note that with passwords you have to trust the site (to handle your password securely), with passkeys you get that for free. The real new property is phishing resistance. When you log in with a passkey, the hostname of the website that you're visiting is signed as part of the auth data that's sent to the server. If you're on github.com, your auth data will contain a signature on github.com; if you're on a phishing site fake-github.com, the data will contain fake-github.com -- the phisher/attacker will get this second data. If the phisher/attacker tries to reuse your auth data on the real github.com, the verification will fail (it's probably easier to picture than to explain...). With passwords, you get phished.

postalrat 4y ago
Something you know is often a pin to unlock your local stuff. Some hardware tokens (via webauthn) require a pin to work.
- ecesena 4y ago
  I agree. I meant to say that you can no longer just have "something you know", you also need "something you have". Wether this is already or not 2FA it's a bit debatable. Apple says yes and I tend to agree. From the server's perspective, however, it can only verify 1 factor and it has to trust the client to implement the 2nd factor securely (whether it's a pin, fingerprint, face id, etc.)
- g_p 4y ago
  In the current design of most security tokens, a PIN is not really a "something you know" factor per-se - it instead unlocks a "something you have" factor. That sounds counter-intuitive, but few (if any) security tokens actually include your user PIN in the cryptography. The same is generally (as far as I know) true in the smartcard space. You rely on hardware attacks being expensive, costly, detectable through physical damage, and not very likely to succeed, in order to protect the physical token. That physical token then (likely) holds the plaintext PIN, or a simple hash of it (which would likely be instantly crackable for numeric PINs). Therefore the PIN is really an access control mechanism for the "something you have" - an asymmetric signature from a hardware token, where access to generate the signature is controlled by the PIN, arguably doesn't actually incorporate the knowledge element in verification, since a compromised hardware token can still generate the signature without the PIN. (FWIW the user you replied to developed the software for a Webauthn key, so may be able to correct/elaborate on the above).
  - postalrat 4y ago
    The pin might be stored in plaintext but should be stored in some sort of secure location on a chip that can't be accessed physically or through brute force. One strategy to prevent brute force the chip may only allow X tries before wiping itself. So the "something you have" is only something you have if you also have the pin. There are already 2 factors baked in.

g_p 4y ago

There's 2 main reasons they differ from "something you know": 1) A passkey isn't phishable, as it's a digital signature that wraps the origin domain that is requesting the passkey. That means a phishing site can't "request" a valid passkey for another site, and replay it to gain access. This helps "normal users" who could be tricked into entering the MS/Google login on a credible-looking SSO portal, and approving the MFA request - a passkey will stop this. 2) You authenticate via a non-replayable signature. If the site's backend database is dumped, nothing is learned - nobody gets even a hash of a password. The stored data is guaranteed to be unique to that site (different public key for every account you make, even on the same site). You can't use it against other sites. If the site checks logs and can be confident the database wasn't tampered with, then after a compromise, they can continue to rely on webauthn logins - just because you saw someone's public key and encrypted offloaded private key doesn't help you log in as them. In contrast, with stored password hashes, users with weak or re-used passwords are at particular risk in this case, and you likely want to force them in through the reset password route, rather than let the attacker used a brute-forced or otherwise leaked password.