100 ms·

Something you know is long gone, even passwords right now are something you have: your password manager. Unlike passwords, passkeys use public key cryptography

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.

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.