8 ms·

Of all the recent publications with regards to passkeys, FIDO2, WebAuthn, etc., finally there's one with a simple and concise summary of the benefits: > Strong

Of all the recent publications with regards to passkeys, FIDO2, WebAuthn, etc., finally there's one with a simple and concise summary of the benefits: > Strong credentials. Every passkey is strong. They’re never guessable, reused, or weak. > Safe from server leaks. Because servers only keep public keys, servers are less valuable targets for hackers. > Safe from phishing. Passkeys are intrinsically linked with the app or website they were created for, so people can never be tricked into using their passkey to sign in to a fraudulent app or website.

ljlolel 3y ago
The last one is a problem for a lot of use cases. Lots of sites have different domains (also for example when HBO max renamed to max). Plaid also relies on entering bank passwords on neobank sites and is widely used.
- gjulianm 3y ago
  AFAIK, passkeys aren't really linked to a domain. It's old-school public-key verification, the server stores your public key and uses it to verify the signature of a challenge they send to your device on login. As long as the different domains/apps can share the public key you should be able to login. And for things like Plaid, I think banks are moving towards OAuth-style permissions, where you login to your bank and authorize the connection. Under the hood, Plaid or other app can connect to the bank with limited permissions using API authorization keys. It's a different problem, I think.
  - tialaramex 3y ago
    > AFAIK, passkeys aren't really linked to a domain. It's old-school public-key verification, the server stores your public key and uses it to verify the signature of a challenge they send to your device on login. As long as the different domains/apps can share the public key you should be able to login. In principle the fancier systems with a user interface could add a feature where you can change the DNS names associated with a key it's storing. That sounds like a monumental pain in the backside, and of course the primary consequence would be it increases phishing because now your users can be tricked into allowing it - but sure, they could do that. For simpler devices like a Yubico Security Key, there is no such interface, they aren't storing any keys so there's no way to make such an association. The keys are bound to the DNS name and are actually stored (encrypted) by the sites you're actually authenticating to. So without a matching DNS name they're intentionally just useless nonsense.
    - vladvasiliu 3y ago
      I may be wrong here, but since the yubikey and similar don't actually store anything site-specific, it means they just respond to a challenge, right? What they prove is that they own a specific private key. So if the website bundles its domain in the challenge, it can make sure that the client signed the challenge for itself, and the client can verify that it signs the challenge for the current domain. So now, if the service's domain were to change, it would presumably be aware of it and incorporate it in the new challenge, which the client would sign, since it's browsing the correct domain, with the same private key used before. Is this not how it works?
      - heavyset_go 3y ago
        FIDO2 allows for things like resident keys, which the Yubikey can only hold so many of. The Yubikey can act in HMAC challenge mode, though, but that's not the mode used on the web.
        TheNewsIsHere 3y ago
        Most web based services don’t seem to be using the discoverable credentials either. So far only my Apple ID and Azure AD accounts are utilizing those.
        deleted 3y ago
        [deleted]
      - tialaramex 3y ago
        Nope, but I can see why you'd expect that because the actual design is very clever and so it's not obvious how this could work. What's inside the cheapest authenticators isn't a private key, after all they present a unique random public key for every single enrolment, so that couldn't work if they held a single private key. Instead it's a symmetric key (e.g. AES-256). Lets see how that's done: When you enrol at a site, the authenticator mints a completely random new public/private key pair (with Elliptic curve crypto it's really easy to pick random key pairs because with a few bit ops any random bits become a random key) and after signing the enrolment step, the authenticator encrypts its new private key using that secret symmetric key and the DNS name in an authenticated encryption mode and provides that encrypted value too. The browser, with the authenticator's help, puts together the final enrolment document, with a signature and it includes that encrypted private key as a Unique Identifier. All the Unique Identifiers in the protocol are huge random looking numbers, so the encrypted key blends right in with that. For a web site, you need to store the public key (obviously) and this unique unique identifier value. You have to do that for everybody, anyway, it's mandatory. You can't decrypt the identifier even if you were sure it's encrypted, you don't know the key, so all you can do is play it back when you want a user to authenticate. When it's played back, the authenticator takes the web site's DNS name, plus its own secret key, and decrypts the identifier to get back its private key, which it can now use to sign authentication messages. Of course if the DNS name is wrong, the decryption fails, which is exactly the same thing as happens if you try to use the wrong authenticator, or you're being phished, or a dozen other things - the authentication can't succeed.
  - detourdog 3y ago
    It is essentially kerberos only Apple has managed to grow a coherent ticketing system for all hardware, services, and users. Each Developer essentially has their own ticket signing system. Apple can revoke any ticket at any time and a developer can revoke their own tickets.
  - microtonal 3y ago
    AFAIK, passkeys aren't really linked to a domain. It's old-school public-key verification, the server stores your public key and uses it to verify the signature of a challenge they send to your device on login. As long as the different domains/apps can share the public key you should be able to login. The credentials are scoped to a relying party, which must be equal to the domain or registrable domain suffix: https://www.w3.org/TR/webauthn-2/#scope https://www.w3.org/TR/webauthn-2/#scope If this wasn't the case and it was old-school public-key verification, it would still be vulnerable to phishing, since the phishing site could just forward the challenges.
- ElFitz 3y ago
  I’ve never understood Plaid. Given what they do, they can’t possibly encrypt the credentials they’re given, let alone hash them, can they? And considering how most banks are set up, we are talking about the user’s only set of credentials. Which have the user’s permissions. Then there are all these fintech startups saying that they’re secure because they use Plaid to access all your financial life, all to provide you with centralised analytics or supposed financial advice. Sure it’s probably (one can hope) more secure than every single one of them rolling out their own hacked together equivalent. But still. Am I missing something?
  - masklinn 3y ago
    I don’t think you are, plaid is a horrible and completely insecure work around banks not providing programmatic access. I’m not sure how it even works with second factors (I’ve never looked).
    - squeaky-clean 3y ago
      If you have 2 factor enabled for each login you get told your account settings are incompatible with Plaid and have to disable 2fah. If it's only enabled for first time logins on a new browser/client Plaid ask you for the code. https://support-my.plaid.com/hc/en-us/articles/9098915502999-Your-account-settings-are-incompatible https://support-my.plaid.com/hc/en-us/articles/9098915502999... I don't know for sure how they do it, but it must just be a thousand custom forms and browser automations for each bank they support. And have to be updated whenever the bank updates.
      - masklinn 3y ago
        As far as I know that’s pretty much what it is yes, a bunch of per-bank scraping systems, which get updated when the bank decides to switch things up. IIRC Yodlee and Mint do (did?) about the same thing, for banks without a formal API.
        WorldMaker 3y ago
- tialaramex 3y ago
  Sure, the Big Boss will be extremely annoyed. Thanks to their innovative branding strategy they've grown New Brand from $0 to $150M revenue in just the first year of operation, a huge success. Did it cannibalise customers from Old Brand, which was $180M revenue and now is just $1M of residual revenue on its way to closing down? Sure, but don't do arithmetic, focus on the tremendous leadership. If authentication systems, like customers, think New Brand is just pointlessly confusing because it's different from Old Brand for no good reason, that undermines Big Boss's amazing strategy and makes it look like something a toddler would try, and that's not OK. However the nice thing when you have players like Google is that their technical people have got license from above to say "Fuck off" on technical issues without somebody who doesn't know the first thing about it overruling them because their golf buddy asked them to. So you're not going to see a way to override this behaviour and thus allow phishing even though I'm sure HBO execs would think that's fine. In terms of practical effect, what that means is that when they use WebAuthn outfits like HBO end up needing to keep login.old-brand.example working, even though supposedly old-brand.example was a completely different product and is now dead, because that's how users actually log into new-brand.example as they are in reality the exact same product.
- arianvanp 3y ago
  They're actively working on an extension on WebAuthn that supports these kind of 3D-Secure usecases. https://www.w3.org/TR/secure-payment-confirmation/ https://www.w3.org/TR/secure-payment-confirmation/ https://github.com/w3c/webauthn/issues/1667 https://github.com/w3c/webauthn/issues/1667
- madeofpalk 3y ago
  > Plaid also relies on entering bank passwords on neobank sites and is widely used. This is an anti-pattern, and is not worth supporting in new tech that's supposed to be "secure first". We already have tech for delegating authorization.
  - scott00 3y ago
    Plaid isn't a solution to a technical problem. It's a way to deal with the fact that banks don't want their customers to bypass their websites/apps and the cross-selling ads within.
    - TheNewsIsHere 3y ago
      In their defense, Plaid also very quickly demonstrated why you might not want an online bank access free for all. At least in privacy-centric terms.
- r00fus 3y ago
  Intuit Mint is not much different. Mint was forced by some banks to not use customer credentials, and instead request an OAuth token from the customer to allow read-only access. So Plaid/Mint have the tech, they just don't do it because of adoption issues at other banks.
- patmorgan23 3y ago
  That just means the auth service needs to have a stable domain, not necessarily the whole app
Rygian 3y ago
> Safe from server leaks. Because servers only keep public keys, servers are less valuable targets for hackers. It's still an attack scenario to keep in mind. If a server can be tricked into storing the wrong public key, authentication is defeated.
- markstos 3y ago
  And how might this happen?
  - milkshakes 3y ago
    account recovery process
    - bnj 3y ago
      Just chiming in to ask -- the immediate need for account recovery is in cases with lost or forgotten passwords. Am I right in assuming that account recovery becomes a much smaller attack surface when using passkeys? Or are there scenarios I'm overlooking?
      - judge2020 3y ago
        It’s mostly how sites will likely still allow full account recovery with just sms-based authentication, making account recovery the weakest link. It’s still required, though, in case someone e.g. signs up with a passkey on their Windows desktop then forgot to enroll one on their phone before taking a vacation.
      - whatusername 3y ago
        So you're covered for "forgotten" - but "lost" is still an issue. What happens when a user loses their passkey? (stolen phone, no backups, house fire, etc).
        bnj 3y ago
        Got it, thanks. A blind spot on my part there. It's funny how quickly the concept of losing access to a phone has taken root, I'm fortunate to have never had that happen to me and I need to remember how easily it could.
lost_tourist 3y ago
Are they safe from Apple shutting down your account? Seems like an all your eggs in one basket problem, with passwords I can back up and always retrieve them locally.
- TheNewsIsHere 3y ago
  Passkeys were designed from the start to enable portability if desired. The rollout has been a mess though, so it’s been very effective in causing a lot more confusion than needed. From the page: > What’s new > Now people can share passwords and passkeys from iCloud Keychain with their trusted contacts. *Password manager apps can save and offer passkeys on iOS, iPadOS, and macOS*. Enterprises can take advantage of passkeys thanks to Managed Apple ID support for iCloud Keychain. And administrators can manage which devices passkeys sync to using Access Management controls in Apple Business Manager and Apple School Manager. Emphasis is my own. Dashlane and 1Password both support passkeys, and you can export your data from both services. I am certain more will follow as more third party support arrives for managing passkeys.
  - kps 3y ago
    That emphasized sentence is key. Pessimistically, it could mean that password managers can ‘save’ only to the Apple OS passkey store, acting as an intermediary transport, without being able to provide cross-platform vendor-agnostic sharing.
    - TheNewsIsHere 3y ago
      1Password previously announced that mobile support for passkeys stored in 1Password was on its way later. I assume they had advanced knowledge of this announcement. I totally understand a pessimistic reading. In trying to roll out passkeys to everyone at once, and doing a poor job of UX and documentation clarity, all the major players bungled the 2022 launch. Not having some portability out of the gate absolutely caused unnecessary distrust about passkeys. But I strongly believe this won’t become a vendor lock-in playground. I have replied a lot about passkeys. I should disclose a former employer works in this space, but I’m not advocating for any particular company or product here, and I no longer have any inside knowledge relevant to the topic that isn’t already public. Edit: grammatical typo; disclosure clarification
labcomputer 3y ago
> Safe from server leaks. Because servers only keep public keys, servers are less valuable targets for hackers That’s not quite true, though. What is true is that the server does not have a plaintext copy of your private keys. That’s a crucial difference. The server has an encrypted copy of your private key, which your with token decrypts with its private key. That is how a usb key can store an unlimited number of U2F credentials: The USB key isn’t storing them at all. They are stored on the server you are authenticating to. What this also means is that if there is a backdoor in the crypto algorithm used by your token and an attacker gets a copy of the server’s U2F credentials, then you are at risk of having your private key stolen.
- kahnclusions 3y ago
  This is incorrect, according to Apple’s developer docs, which states that only the public key is sent to servers. They emphasise this as a benefit: your key can’t be leaked because servers only ever receive your public key. The private key never leaves your device except to be encrypted and synced to your other devices using iCloud Keychain.
- JulianK 3y ago
  The idea behind private keys is that they are private and never sent anywhere so I believe your assertion that the server knows anything about your private key is incorrect. Here's a link to Yubico with a visual diagram of how passkeys work: https://developers.yubico.com/Passkeys/How_passkeys_work.html https://developers.yubico.com/Passkeys/How_passkeys_work.htm... But fundamentally it's very similar to how all public/private stuff works. You send people the public key and sign stuff with the private key.
  - labcomputer 3y ago
    You may want to dig into the documentation a bit more. First, ask yourself a simple question: How can a Yubikey store an unlimited number of FIDO2/U2F credentials. The official Yubikey documentation literally claims that Yubikeys can do that. Not “a lot”. Not “more than you’ll ever need”. Not 10k. Not 10M. Not 10G. Unlimited. Gosh, maybe I should use a Yubikey for mass storage on the cheap! I wonder why nobody has done this? Second, you’ll want to dig into what is the contents of the “key handle” that is passed from the server, through the user agent, to the key. Hint: Despite the HN hive mind, I’m not wrong.
snagg 3y ago
We spent some time putting together a threat-model and taxonomy of attacks paths for Passkeys in case anybody is interested: https://www.slashid.dev/blog/passkeys-security-implementation/#security-and-threat-modeling https://www.slashid.dev/blog/passkeys-security-implementatio... Passkeys are definitely a leap forward in that we are shifting the bulk of the account takeover risk from the end users using weak passwords or clicking on phishing links to: 1) The server side implementation, including any mechanism for account recovery and support for multiple passkeys/auth factors 2) The browser enforcement checks (eg: this is what Chrome does: https://www.slashid.dev/blog/webauthn-antiphishing/ https://www.slashid.dev/blog/webauthn-antiphishing/) 3) The wallet/keychain/password manager holding the keys (there's a lot of variance here in terms of security guarantees, see recent password managers breaches. We wrote a bit about how Apple does it: https://www.slashid.dev/blog/passkeys-deepdive/#the-technical-details https://www.slashid.dev/blog/passkeys-deepdive/#the-technica...) 4) The authenticator itself (again, lots of variance here) All of which are harder to compromise vs the average end-user. There are still scenarios where the end-user could be targeted/tricked but they are fewer and harder to pull off (to name some: malware stealing the private keys and account takeovers on the password manager).
- rstuart4133 3y ago
  That is by far the best explanation I've seen of Passkey or FIDO for that matter. Thank you.

ljlolel 3y ago

The last one is a problem for a lot of use cases. Lots of sites have different domains (also for example when HBO max renamed to max). Plaid also relies on entering bank passwords on neobank sites and is widely used.

gjulianm 3y ago
AFAIK, passkeys aren't really linked to a domain. It's old-school public-key verification, the server stores your public key and uses it to verify the signature of a challenge they send to your device on login. As long as the different domains/apps can share the public key you should be able to login. And for things like Plaid, I think banks are moving towards OAuth-style permissions, where you login to your bank and authorize the connection. Under the hood, Plaid or other app can connect to the bank with limited permissions using API authorization keys. It's a different problem, I think.
- tialaramex 3y ago
  > AFAIK, passkeys aren't really linked to a domain. It's old-school public-key verification, the server stores your public key and uses it to verify the signature of a challenge they send to your device on login. As long as the different domains/apps can share the public key you should be able to login. In principle the fancier systems with a user interface could add a feature where you can change the DNS names associated with a key it's storing. That sounds like a monumental pain in the backside, and of course the primary consequence would be it increases phishing because now your users can be tricked into allowing it - but sure, they could do that. For simpler devices like a Yubico Security Key, there is no such interface, they aren't storing any keys so there's no way to make such an association. The keys are bound to the DNS name and are actually stored (encrypted) by the sites you're actually authenticating to. So without a matching DNS name they're intentionally just useless nonsense.
  - vladvasiliu 3y ago
    I may be wrong here, but since the yubikey and similar don't actually store anything site-specific, it means they just respond to a challenge, right? What they prove is that they own a specific private key. So if the website bundles its domain in the challenge, it can make sure that the client signed the challenge for itself, and the client can verify that it signs the challenge for the current domain. So now, if the service's domain were to change, it would presumably be aware of it and incorporate it in the new challenge, which the client would sign, since it's browsing the correct domain, with the same private key used before. Is this not how it works?
    - heavyset_go 3y ago
      FIDO2 allows for things like resident keys, which the Yubikey can only hold so many of. The Yubikey can act in HMAC challenge mode, though, but that's not the mode used on the web.
      - TheNewsIsHere 3y ago
        Most web based services don’t seem to be using the discoverable credentials either. So far only my Apple ID and Azure AD accounts are utilizing those.
        deleted 3y ago
        [deleted]
    - tialaramex 3y ago
      Nope, but I can see why you'd expect that because the actual design is very clever and so it's not obvious how this could work. What's inside the cheapest authenticators isn't a private key, after all they present a unique random public key for every single enrolment, so that couldn't work if they held a single private key. Instead it's a symmetric key (e.g. AES-256). Lets see how that's done: When you enrol at a site, the authenticator mints a completely random new public/private key pair (with Elliptic curve crypto it's really easy to pick random key pairs because with a few bit ops any random bits become a random key) and after signing the enrolment step, the authenticator encrypts its new private key using that secret symmetric key and the DNS name in an authenticated encryption mode and provides that encrypted value too. The browser, with the authenticator's help, puts together the final enrolment document, with a signature and it includes that encrypted private key as a Unique Identifier. All the Unique Identifiers in the protocol are huge random looking numbers, so the encrypted key blends right in with that. For a web site, you need to store the public key (obviously) and this unique unique identifier value. You have to do that for everybody, anyway, it's mandatory. You can't decrypt the identifier even if you were sure it's encrypted, you don't know the key, so all you can do is play it back when you want a user to authenticate. When it's played back, the authenticator takes the web site's DNS name, plus its own secret key, and decrypts the identifier to get back its private key, which it can now use to sign authentication messages. Of course if the DNS name is wrong, the decryption fails, which is exactly the same thing as happens if you try to use the wrong authenticator, or you're being phished, or a dozen other things - the authentication can't succeed.
- detourdog 3y ago
  It is essentially kerberos only Apple has managed to grow a coherent ticketing system for all hardware, services, and users. Each Developer essentially has their own ticket signing system. Apple can revoke any ticket at any time and a developer can revoke their own tickets.
- microtonal 3y ago
  AFAIK, passkeys aren't really linked to a domain. It's old-school public-key verification, the server stores your public key and uses it to verify the signature of a challenge they send to your device on login. As long as the different domains/apps can share the public key you should be able to login. The credentials are scoped to a relying party, which must be equal to the domain or registrable domain suffix: https://www.w3.org/TR/webauthn-2/#scope https://www.w3.org/TR/webauthn-2/#scope If this wasn't the case and it was old-school public-key verification, it would still be vulnerable to phishing, since the phishing site could just forward the challenges.
ElFitz 3y ago
I’ve never understood Plaid. Given what they do, they can’t possibly encrypt the credentials they’re given, let alone hash them, can they? And considering how most banks are set up, we are talking about the user’s only set of credentials. Which have the user’s permissions. Then there are all these fintech startups saying that they’re secure because they use Plaid to access all your financial life, all to provide you with centralised analytics or supposed financial advice. Sure it’s probably (one can hope) more secure than every single one of them rolling out their own hacked together equivalent. But still. Am I missing something?
- masklinn 3y ago
  I don’t think you are, plaid is a horrible and completely insecure work around banks not providing programmatic access. I’m not sure how it even works with second factors (I’ve never looked).
  - squeaky-clean 3y ago
    If you have 2 factor enabled for each login you get told your account settings are incompatible with Plaid and have to disable 2fah. If it's only enabled for first time logins on a new browser/client Plaid ask you for the code. https://support-my.plaid.com/hc/en-us/articles/9098915502999-Your-account-settings-are-incompatible https://support-my.plaid.com/hc/en-us/articles/9098915502999... I don't know for sure how they do it, but it must just be a thousand custom forms and browser automations for each bank they support. And have to be updated whenever the bank updates.
    - masklinn 3y ago
      As far as I know that’s pretty much what it is yes, a bunch of per-bank scraping systems, which get updated when the bank decides to switch things up. IIRC Yodlee and Mint do (did?) about the same thing, for banks without a formal API.
      - WorldMaker 3y ago
tialaramex 3y ago
Sure, the Big Boss will be extremely annoyed. Thanks to their innovative branding strategy they've grown New Brand from $0 to $150M revenue in just the first year of operation, a huge success. Did it cannibalise customers from Old Brand, which was $180M revenue and now is just $1M of residual revenue on its way to closing down? Sure, but don't do arithmetic, focus on the tremendous leadership. If authentication systems, like customers, think New Brand is just pointlessly confusing because it's different from Old Brand for no good reason, that undermines Big Boss's amazing strategy and makes it look like something a toddler would try, and that's not OK. However the nice thing when you have players like Google is that their technical people have got license from above to say "Fuck off" on technical issues without somebody who doesn't know the first thing about it overruling them because their golf buddy asked them to. So you're not going to see a way to override this behaviour and thus allow phishing even though I'm sure HBO execs would think that's fine. In terms of practical effect, what that means is that when they use WebAuthn outfits like HBO end up needing to keep login.old-brand.example working, even though supposedly old-brand.example was a completely different product and is now dead, because that's how users actually log into new-brand.example as they are in reality the exact same product.
arianvanp 3y ago
They're actively working on an extension on WebAuthn that supports these kind of 3D-Secure usecases. https://www.w3.org/TR/secure-payment-confirmation/ https://www.w3.org/TR/secure-payment-confirmation/ https://github.com/w3c/webauthn/issues/1667 https://github.com/w3c/webauthn/issues/1667
madeofpalk 3y ago
> Plaid also relies on entering bank passwords on neobank sites and is widely used. This is an anti-pattern, and is not worth supporting in new tech that's supposed to be "secure first". We already have tech for delegating authorization.
- scott00 3y ago
  Plaid isn't a solution to a technical problem. It's a way to deal with the fact that banks don't want their customers to bypass their websites/apps and the cross-selling ads within.
  - TheNewsIsHere 3y ago
    In their defense, Plaid also very quickly demonstrated why you might not want an online bank access free for all. At least in privacy-centric terms.
r00fus 3y ago
Intuit Mint is not much different. Mint was forced by some banks to not use customer credentials, and instead request an OAuth token from the customer to allow read-only access. So Plaid/Mint have the tech, they just don't do it because of adoption issues at other banks.
patmorgan23 3y ago
That just means the auth service needs to have a stable domain, not necessarily the whole app

Rygian 3y ago

> Safe from server leaks. Because servers only keep public keys, servers are less valuable targets for hackers. It's still an attack scenario to keep in mind. If a server can be tricked into storing the wrong public key, authentication is defeated.

markstos 3y ago
And how might this happen?
- milkshakes 3y ago
  account recovery process
  - bnj 3y ago
    Just chiming in to ask -- the immediate need for account recovery is in cases with lost or forgotten passwords. Am I right in assuming that account recovery becomes a much smaller attack surface when using passkeys? Or are there scenarios I'm overlooking?
    - judge2020 3y ago
      It’s mostly how sites will likely still allow full account recovery with just sms-based authentication, making account recovery the weakest link. It’s still required, though, in case someone e.g. signs up with a passkey on their Windows desktop then forgot to enroll one on their phone before taking a vacation.
    - whatusername 3y ago
      So you're covered for "forgotten" - but "lost" is still an issue. What happens when a user loses their passkey? (stolen phone, no backups, house fire, etc).
      - bnj 3y ago
        Got it, thanks. A blind spot on my part there. It's funny how quickly the concept of losing access to a phone has taken root, I'm fortunate to have never had that happen to me and I need to remember how easily it could.

lost_tourist 3y ago

Are they safe from Apple shutting down your account? Seems like an all your eggs in one basket problem, with passwords I can back up and always retrieve them locally.

TheNewsIsHere 3y ago
Passkeys were designed from the start to enable portability if desired. The rollout has been a mess though, so it’s been very effective in causing a lot more confusion than needed. From the page: > What’s new > Now people can share passwords and passkeys from iCloud Keychain with their trusted contacts. *Password manager apps can save and offer passkeys on iOS, iPadOS, and macOS*. Enterprises can take advantage of passkeys thanks to Managed Apple ID support for iCloud Keychain. And administrators can manage which devices passkeys sync to using Access Management controls in Apple Business Manager and Apple School Manager. Emphasis is my own. Dashlane and 1Password both support passkeys, and you can export your data from both services. I am certain more will follow as more third party support arrives for managing passkeys.
- kps 3y ago
  That emphasized sentence is key. Pessimistically, it could mean that password managers can ‘save’ only to the Apple OS passkey store, acting as an intermediary transport, without being able to provide cross-platform vendor-agnostic sharing.
  - TheNewsIsHere 3y ago
    1Password previously announced that mobile support for passkeys stored in 1Password was on its way later. I assume they had advanced knowledge of this announcement. I totally understand a pessimistic reading. In trying to roll out passkeys to everyone at once, and doing a poor job of UX and documentation clarity, all the major players bungled the 2022 launch. Not having some portability out of the gate absolutely caused unnecessary distrust about passkeys. But I strongly believe this won’t become a vendor lock-in playground. I have replied a lot about passkeys. I should disclose a former employer works in this space, but I’m not advocating for any particular company or product here, and I no longer have any inside knowledge relevant to the topic that isn’t already public. Edit: grammatical typo; disclosure clarification

labcomputer 3y ago

> Safe from server leaks. Because servers only keep public keys, servers are less valuable targets for hackers That’s not quite true, though. What is true is that the server does not have a plaintext copy of your private keys. That’s a crucial difference. The server has an encrypted copy of your private key, which your with token decrypts with its private key. That is how a usb key can store an unlimited number of U2F credentials: The USB key isn’t storing them at all. They are stored on the server you are authenticating to. What this also means is that if there is a backdoor in the crypto algorithm used by your token and an attacker gets a copy of the server’s U2F credentials, then you are at risk of having your private key stolen.

kahnclusions 3y ago
This is incorrect, according to Apple’s developer docs, which states that only the public key is sent to servers. They emphasise this as a benefit: your key can’t be leaked because servers only ever receive your public key. The private key never leaves your device except to be encrypted and synced to your other devices using iCloud Keychain.
JulianK 3y ago
The idea behind private keys is that they are private and never sent anywhere so I believe your assertion that the server knows anything about your private key is incorrect. Here's a link to Yubico with a visual diagram of how passkeys work: https://developers.yubico.com/Passkeys/How_passkeys_work.html https://developers.yubico.com/Passkeys/How_passkeys_work.htm... But fundamentally it's very similar to how all public/private stuff works. You send people the public key and sign stuff with the private key.
- labcomputer 3y ago
  You may want to dig into the documentation a bit more. First, ask yourself a simple question: How can a Yubikey store an unlimited number of FIDO2/U2F credentials. The official Yubikey documentation literally claims that Yubikeys can do that. Not “a lot”. Not “more than you’ll ever need”. Not 10k. Not 10M. Not 10G. Unlimited. Gosh, maybe I should use a Yubikey for mass storage on the cheap! I wonder why nobody has done this? Second, you’ll want to dig into what is the contents of the “key handle” that is passed from the server, through the user agent, to the key. Hint: Despite the HN hive mind, I’m not wrong.

snagg 3y ago

We spent some time putting together a threat-model and taxonomy of attacks paths for Passkeys in case anybody is interested: https://www.slashid.dev/blog/passkeys-security-implementation/#security-and-threat-modeling https://www.slashid.dev/blog/passkeys-security-implementatio... Passkeys are definitely a leap forward in that we are shifting the bulk of the account takeover risk from the end users using weak passwords or clicking on phishing links to: 1) The server side implementation, including any mechanism for account recovery and support for multiple passkeys/auth factors 2) The browser enforcement checks (eg: this is what Chrome does: https://www.slashid.dev/blog/webauthn-antiphishing/ https://www.slashid.dev/blog/webauthn-antiphishing/) 3) The wallet/keychain/password manager holding the keys (there's a lot of variance here in terms of security guarantees, see recent password managers breaches. We wrote a bit about how Apple does it: https://www.slashid.dev/blog/passkeys-deepdive/#the-technical-details https://www.slashid.dev/blog/passkeys-deepdive/#the-technica...) 4) The authenticator itself (again, lots of variance here) All of which are harder to compromise vs the average end-user. There are still scenarios where the end-user could be targeted/tricked but they are fewer and harder to pull off (to name some: malware stealing the private keys and account takeovers on the password manager).

rstuart4133 3y ago
That is by far the best explanation I've seen of Passkey or FIDO for that matter. Thank you.