Passkeys now support external providers(developer.apple.com)
developer.apple.com
Passkeys now support external providers
https://developer.apple.com/passkeys/
184 comments
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-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/)
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-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).
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/)
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-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).
That is by far the best explanation I've seen of Passkey or FIDO for that matter. Thank you.
> 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.
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.
By the same token, if the server can be tricked into storing the wrong password, authentication is defeated. However, with passkeys, even downloading the entire database doesn't give the attacker any useful credential information. This is in contrast to today, where a database download gives you salted & encrypted passwords that are (generally) knowable (given enough time). I'll take passkeys over passwords any day.
This is my view as well. I think in the more technical crowds but outside of people who actively deal in identity and authentication daily, there seems to be this fixation on the marketing of passkeys that focuses on the FIDO component, and this muddies the virtues of the specification.
Many focus too much on the (potential) MFA use case rather than the idea that we can use effectively the same tech as in Yubikeys (etc) to make phishing resistant authenticators everywhere.
The (IMO) messy rollout by the major platforms really doesn’t help either. They absolutely could have spent a little more time baking the UX and designing edge case mitigations, but they didn’t.
Many focus too much on the (potential) MFA use case rather than the idea that we can use effectively the same tech as in Yubikeys (etc) to make phishing resistant authenticators everywhere.
The (IMO) messy rollout by the major platforms really doesn’t help either. They absolutely could have spent a little more time baking the UX and designing edge case mitigations, but they didn’t.
I think that is why it is both good and bad that Apple have effectively taken the lead in the rollout. They are great at UX and keeping an eye out for edge cases and trying to sand down the worst sorts of gotchas. If anyone can make sure that Passkeys feel good to the average user it is probably Apple.
On the flipside, that early lead also led to so many of the misconceptions about Passkeys that people have. People think it by nature has to be a locked, walled garden, because Apple has the lead and loves walled gardens when it has the lead.
I think that's why this newest rollout announcement is such great news (which we knew was coming, but wasn't obvious to some of those misconceptions from Apple being in the lead): complete integration with the larger ecosystem of password apps already in the App Store wild (use your 1Password passkeys just like you can use 1Password passwords), and a UX for grouping passkeys and sharing those groups with other contacts (that also helps with all the misconceptions about passkeys being some sort of crack down on password sharing).
These UX flows would have been great to have seen in the initial rollout to assuage a lot of fears about Passkeys. It is great to see them happening right now while it is still early enough to stop most of the FUD before it starts to get outside of the HN paranoia bubbles and into average consumer ears.
On the flipside, that early lead also led to so many of the misconceptions about Passkeys that people have. People think it by nature has to be a locked, walled garden, because Apple has the lead and loves walled gardens when it has the lead.
I think that's why this newest rollout announcement is such great news (which we knew was coming, but wasn't obvious to some of those misconceptions from Apple being in the lead): complete integration with the larger ecosystem of password apps already in the App Store wild (use your 1Password passkeys just like you can use 1Password passwords), and a UX for grouping passkeys and sharing those groups with other contacts (that also helps with all the misconceptions about passkeys being some sort of crack down on password sharing).
These UX flows would have been great to have seen in the initial rollout to assuage a lot of fears about Passkeys. It is great to see them happening right now while it is still early enough to stop most of the FUD before it starts to get outside of the HN paranoia bubbles and into average consumer ears.
The point is that a hacker can’t use the public keys obtained in a data breach to access your accounts on other services. This is a common problem when a lot of people use the same email and password for many different sites.
Yes, but that's not a leak
And how might this happen?
account recovery process
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?
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.
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).
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.
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.
Plaid also relies on entering bank passwords on neobank sites and is widely used.
> 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.
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.
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.
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.
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.
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.
> 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.
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.
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?
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?
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.
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.
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.
The Yubikey can act in HMAC challenge mode, though, but that's not the mode used on the web.
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]
[deleted]
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
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.
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
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.
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.
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://github.com/w3c/webauthn/issues/1667
https://www.w3.org/TR/secure-payment-confirmation/ https://github.com/w3c/webauthn/issues/1667
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?
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?
If your bank doesn't use something like OAuth they do store your login credentials. If your bank does use OAuth or similar Plaid still has to store the access token, which hopefully your bank has given a read-only scope.
They can definitely encrypt the credentials, they just also have to make it simple for their backend to decrypt it when they need access to your bank, which defeats a lot of the security there. (It's still better than just storing it in plaintext).
https://support-my.plaid.com/hc/en-us/articles/4410324401047...
> In other cases, when you link a financial institution to an app via Plaid, you provide your login credentials to us. We store those credentials and use them to collect the data to power the services you’ve chosen and, when requested, securely share it with the app you’re using and establish a secure connection that you control. We then help keep your data safe and private with best-in-class encryption protocols.
They can definitely encrypt the credentials, they just also have to make it simple for their backend to decrypt it when they need access to your bank, which defeats a lot of the security there. (It's still better than just storing it in plaintext).
https://support-my.plaid.com/hc/en-us/articles/4410324401047...
> In other cases, when you link a financial institution to an app via Plaid, you provide your login credentials to us. We store those credentials and use them to collect the data to power the services you’ve chosen and, when requested, securely share it with the app you’re using and establish a secure connection that you control. We then help keep your data safe and private with best-in-class encryption protocols.
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).
I’m not sure how it even works with second factors (I’ve never looked).
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...
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.
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.
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.
IIRC Yodlee and Mint do (did?) about the same thing, for banks without a formal API.
From my understanding in recent years Mint uses a lot more of the Quicken/QuickBooks semi-formal APIs when formal APIs don't exist. My understanding is that is one of the few, biggest benefits of Mint being bought by Intuit because that 200-pound gorilla has always had a surprising number of special read only APIs and export dump tools from even the quirkiest, smallest banks because of how ubiquitous their tax software is (and how many users would rebel if they didn't have easy access in Quicken or QuickBooks).
This is one of my (numerous) top complaints about Plaid. From the start they’ve been more about working against than working with banks, and that’s sort of obvious still today.
My credit union doesn’t give a flying fuck about Plaid and it’s a constant cat and mouse game that amuses me to watch. My credit union doesn’t have a path to online banking without per-session MFA.
I think banks should be required to provide a user-opt-in OAuth API for read-only access, but not so that companies like Plaid can pilfer your data.
My credit union doesn’t give a flying fuck about Plaid and it’s a constant cat and mouse game that amuses me to watch. My credit union doesn’t have a path to online banking without per-session MFA.
I think banks should be required to provide a user-opt-in OAuth API for read-only access, but not so that companies like Plaid can pilfer your data.
> From the start they’ve been more about working against than working with banks...
At the very beginning sure, but very quickly Plaid built out a team to try and work with banks. Banks were the biggest roadblock to OAuth, most banks have (had) zero appetite to provide a good experience for users to delegate programmatic access to their own user data. Banks see user financial data as their own and _not_ belonging to their users (as it legally does).
However Plaid has made in-roads at many large institutions, and now supports OAuth, or OAuth-like, access at all (nearly all?) major US financial institutions.
Plaid never liked working against banks, that just made everything worse for everybody involved.
> My credit union doesn’t have a path to online banking without per-session MFA. This obviously kills async products at Plaid, like continuous transaction data, but doesn't block sync products like Auth (account and routing data).
In fact, Plaid made a huge push to increase the amount of MFA encountered on their platform. When banks or credit unions didn't offer MFA, or didn't allow users to enforce MFA on every login, Plaid would attempt to force it through a variety of mechanisms to ensure a bad actor would encounter MFA on Plaid even if the bank would otherwise let them through their actual website.
However Plaid has made in-roads at many large institutions, and now supports OAuth, or OAuth-like, access at all (nearly all?) major US financial institutions.
Plaid never liked working against banks, that just made everything worse for everybody involved.
> My credit union doesn’t have a path to online banking without per-session MFA. This obviously kills async products at Plaid, like continuous transaction data, but doesn't block sync products like Auth (account and routing data).
In fact, Plaid made a huge push to increase the amount of MFA encountered on their platform. When banks or credit unions didn't offer MFA, or didn't allow users to enforce MFA on every login, Plaid would attempt to force it through a variety of mechanisms to ensure a bad actor would encounter MFA on Plaid even if the bank would otherwise let them through their actual website.
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.
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.
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.
That just means the auth service needs to have a stable domain, not necessarily the whole app
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.
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.
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.
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.
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
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
That's good to hear. If cross-platform sync is possible, passkeys are definitely a better option for the 95% of crud that currently lives in browsers' password managers.
You mean this is annoying?
google.com (never save)
google.com (Jane.Doe)
google.com (Jane.Doe) (Grandma use this one)
google.com (never save)
google.com (Jane.Doe) (password missing)
google.com (Jane.Doe) *Your password may have been exposed in an online breach.
I fully agree with you. Passkeys solve a lot of usability problems, especially for the less technically adept, while solving so many password problems.
Edit: formatting nightmares
google.com (never save)
google.com (Jane.Doe)
google.com (Jane.Doe) (Grandma use this one)
google.com (never save)
google.com (Jane.Doe) (password missing)
google.com (Jane.Doe) *Your password may have been exposed in an online breach.
I fully agree with you. Passkeys solve a lot of usability problems, especially for the less technically adept, while solving so many password problems.
Edit: formatting nightmares
> 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.
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.
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.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.
Here's a link to Yubico with a visual diagram of how passkeys work: 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.
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.
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.
It's very similar to how TPMs work. Discoverable keys were originally called resident keys because regular keys were almost always encrypted in the key handle and sent to the RP.
If you don't trust a system to encrypt why would you trust it to generate keys with correct random or sign without leaking key data?
The encrypted private key isn't any more likely to be a weak link than the other things a token could do wrong.
If you don't trust a system to encrypt why would you trust it to generate keys with correct random or sign without leaking key data?
The encrypted private key isn't any more likely to be a weak link than the other things a token could do wrong.
This is just plain wrong. The server only ever stores your public key, private keys are stored on the clients. Everything else would defeat the entire purpose.
It would not defeat the entire purpose.
"non-discoverable" WebAuthn keys aren't part of "passkeys", apparently, but they locally encrypt the per-site data, including the private key, and then give that encrypted data to the server to store.
"non-discoverable" WebAuthn keys aren't part of "passkeys", apparently, but they locally encrypt the per-site data, including the private key, and then give that encrypted data to the server to store.
No, it is technically correct for nondiscoverable mode. Naturally, there should be low value in breaking the opacity of the stored key as it should be a private key only used with the server that holds it. (But it would still mean many sites requesting that you replace any token found to have such a defect.)
Not sure why reality is so controversial, here are references for anyone who wants to know how a (standard) unlimited fido hardware token works:
https://security.stackexchange.com/questions/237271/where-ar...
OTOH for resident keys they usually support 50-100.
https://security.stackexchange.com/questions/237271/where-ar...
OTOH for resident keys they usually support 50-100.
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.
The private key never leaves your device except to be encrypted and synced to your other devices using iCloud Keychain.
[deleted]
i'm pretty sure you're wrong. or at least, you're directly contradicted by the apple docs, which say "The other key is private, and is what is needed to actually sign in. The server never learns what the private key is." https://support.apple.com/en-ca/HT213305
the basic claim about being able to store "infinite" passkeys on a USB is also directly contradicted by the yubikey docs, which say they can store 25: https://www.yubico.com/blog/a-yubico-faq-about-passkeys/
the basic claim about being able to store "infinite" passkeys on a USB is also directly contradicted by the yubikey docs, which say they can store 25: https://www.yubico.com/blog/a-yubico-faq-about-passkeys/
Originally seen via https://reddit.com/r/Bitwarden/comments/141uxz1/iosipados_17...
This is big news as vendor lock in and inability to use our own sync was one of the biggest issues bought up whenever Passkeys are discussed. Apple are now allowing external sync fabrics such as password managers.
This is big news as vendor lock in and inability to use our own sync was one of the biggest issues bought up whenever Passkeys are discussed. Apple are now allowing external sync fabrics such as password managers.
I'm very eager to see what Bitwarden does here, they're the first big[0] name that's actually Open Source that's on board. It's hard to take passkeys seriously when the vast majority of implementations are completely proprietary.
Seeing what Bitwarden comes up with and seeing whether or not the process for self-hosted Bitwarden accounts is actually seamless and works on platforms like desktop Linux -- to me, that's going to be a really big test of whether passkeys can credibly be claimed to be actually cross-platform.
[0]: I do think there have been some smaller proof-of-concepts, but... there's a difference of scale here.
Seeing what Bitwarden comes up with and seeing whether or not the process for self-hosted Bitwarden accounts is actually seamless and works on platforms like desktop Linux -- to me, that's going to be a really big test of whether passkeys can credibly be claimed to be actually cross-platform.
[0]: I do think there have been some smaller proof-of-concepts, but... there's a difference of scale here.
Yeah, this is awesome. The devil's in the details though, do we know anything about exactly how they plan to support external providers? I'm cautiously optimistic; at least on the surface this sounds like exactly what I was hoping for.
> Password manager apps can save and offer passkeys on iOS, iPadOS, and macOS.
No reason to believe this would work differently than the existing affordances for 3rd party apps to offer passwords, which works well today
No reason to believe this would work differently than the existing affordances for 3rd party apps to offer passwords, which works well today
So I will be able to copy-paste some string from my password manager to my browser in order to complete the passkey handshake? Or does this mean that my password manager must support my browser of choice on my platform of choice with some opaque plugin that cannot be disabled (eg, 1pw on macos today)?
On iOS for passwords, this is a systemwide system that allows any app to register as a password provider and any password field to receive those passwords via the system keyboard.
I would assume that the system passkey interface will handle the receiving app, and the sharing app will register with the system (NOT with the browser or app, although this doesn't preclude doing that as well) to vend passkeys.
I would assume that the system passkey interface will handle the receiving app, and the sharing app will register with the system (NOT with the browser or app, although this doesn't preclude doing that as well) to vend passkeys.
I mean apple has a tried and true playbook for supporting external providers, I'm not worried
charge them random % of revenue, force them to funnel all transactions through apple, let random junior employees disable the 3rd party's bugfixes for reasons(tm), and eventually refuse to license new entrants because there are too many flashlight apps
I'm not worried
charge them random % of revenue, force them to funnel all transactions through apple, let random junior employees disable the 3rd party's bugfixes for reasons(tm), and eventually refuse to license new entrants because there are too many flashlight apps
I'm not worried
> Apple are *now* allowing external sync
There is no guarantee that this will be permanent. It can be revoked citing x number of reasons.
Also, lets wait until the implementation details are available. If it requires providers having a native app on the device where Apple has control on who and what to allow, there's only an illusion of choice.
There is no guarantee that this will be permanent. It can be revoked citing x number of reasons.
Also, lets wait until the implementation details are available. If it requires providers having a native app on the device where Apple has control on who and what to allow, there's only an illusion of choice.
Pretty sure "now" in this context means "starting now".
Once people start relying on this, it will take a lot more than just citing reasons to revoke it without causing massive blowback.
Once people start relying on this, it will take a lot more than just citing reasons to revoke it without causing massive blowback.
I don't mean revoking 3rd party support entirely.
We don't know the implementation details yet but if this requires Apple vetting and whitelisting the providers then it can always be revoked for technical, business, political or any other reasons.
We don't know the implementation details yet but if this requires Apple vetting and whitelisting the providers then it can always be revoked for technical, business, political or any other reasons.
I would expect this to be modelled after the API for password managers, in which case there's no vetting or whitelisting. Or if there is, it's pretty open as a lot of software uses it, both closed and open source.
So far, no one has commented on this large downside of passkeys: that it will promote the ease of sites to require login since it's much easier to generate a passkey than to remember a new password or even store it.
Thus, passkeys lubricate the path towards an ever-increasing login-based society where it becomes much easier to track and monitor your online behaviour. Although it has the benefit of making our existing lives easier by removing the need to remember our banking passwords, it also will bring us further into the realm of technology by making more and more services log-in based.
A greater ease of making a log-in based service means more revenue, more profit for Apple, and a greater integration of technology into our lives. Few people realize this because we have been conditioned to believe that new technology is solely for our benefit.
In reality, Apple is not concerned with our benefit. They are concerned with profit and making technology more efficient to accomplish that end. So although passkeys might seem nice, there is a serious downside to this technology.
Thus, passkeys lubricate the path towards an ever-increasing login-based society where it becomes much easier to track and monitor your online behaviour. Although it has the benefit of making our existing lives easier by removing the need to remember our banking passwords, it also will bring us further into the realm of technology by making more and more services log-in based.
A greater ease of making a log-in based service means more revenue, more profit for Apple, and a greater integration of technology into our lives. Few people realize this because we have been conditioned to believe that new technology is solely for our benefit.
In reality, Apple is not concerned with our benefit. They are concerned with profit and making technology more efficient to accomplish that end. So although passkeys might seem nice, there is a serious downside to this technology.
How? you make claims that seem to have no substance. What extra vector does Passkeys add for tracking? I don't see any.
Passkeys are an origin-bound login mechanism. Worst case is that somebody places a first-party cookie to keep you logged in after you authenticated with a passkey. which they and will already do today without your consent or without logging in. (First-party session cookies don't even need a cookie wall. They're considered "necessary" processing)
Passkeys are an origin-bound login mechanism. Worst case is that somebody places a first-party cookie to keep you logged in after you authenticated with a passkey. which they and will already do today without your consent or without logging in. (First-party session cookies don't even need a cookie wall. They're considered "necessary" processing)
Passkeys do not help track people between sites, but if they are used in places that passwords never were, it might increase tracking within a site.
Hacker News, for instance, allows non-logged-in read-only usage. If Hacker News decided that Passkeys were so easy for the user that non-logged-in usage would be eliminated, then some degree of privacy would be lost.
Personally, I don't think it is that much of a risk. I DO worry about putting too much control in the hands of Apple and Google.
Hacker News, for instance, allows non-logged-in read-only usage. If Hacker News decided that Passkeys were so easy for the user that non-logged-in usage would be eliminated, then some degree of privacy would be lost.
Personally, I don't think it is that much of a risk. I DO worry about putting too much control in the hands of Apple and Google.
> If Hacker News decided that Passkeys were so easy for the user that non-logged-in usage would be eliminated, then some degree of privacy would be lost.
Not if you the user generates a new login upon every visit, which should be trivial.
Not if you the user generates a new login upon every visit, which should be trivial.
If sites started going Passkey only even for "guest" access, you'd quickly see a rise in Passkey managers that quickly generate throwaway passkeys and you'd also see a rise in "globally shared" anonymous group passkeys, just as people already do today to get around paywalls and some walled gardens with passwords and "phone memberships" at rewards clubs (the notorious Jenny's Number being a common one there). The techniques don't really change that much. Passkeys really don't have any more identifying information than passwords or phone numbers and temporary anonymous passkeys or over-shared passkeys are likely to be a thing in some places as soon as they are seen as necessary.
With 3rd party cookies going away, companies now need your email address to effectively track you.
Tracking you via your email address is actually better than using cookies (for the advertiser) because it works cross-device and cross-browser.
Any mechanism that makes it easier to login to sites will promote the usage of email addresses for tracking purposes. Think retargeting and conversion tracking (no longer needing to be cookie-based).
Passkeys = quicker and faster to get a user's email address.
Email address = even better than "super cookies"
Tracking you via your email address is actually better than using cookies (for the advertiser) because it works cross-device and cross-browser.
Any mechanism that makes it easier to login to sites will promote the usage of email addresses for tracking purposes. Think retargeting and conversion tracking (no longer needing to be cookie-based).
Passkeys = quicker and faster to get a user's email address.
Email address = even better than "super cookies"
But Apple offer this service where they make a fresh proxy email for you which is unique to the service. Why would they do that if they want to enable cross-service tracking via email address?
I use 1password + fastmail for exactly this. The integration is better than Apple IMHO.
Do 1password/fastmail have functionality built in for this or do you just manually generate your emails based off a wildcard?
> Passkeys = quicker and faster to get a user's email address.
Using passkeys doesn't give a site your email address. The site would have to still ask for your email separately.
Using passkeys doesn't give a site your email address. The site would have to still ask for your email separately.
> Tracking you via your email address is actually better than using cookies (for the advertiser) because it works cross-device and cross-browser.
At least in the EU, you'll need express consent to do this.
At least in the EU, you'll need express consent to do this.
“Need” is a very strong word. Any potential fines will just be rolled into the costs of doing business, and if it’s found to still be worth it they’ll keep abusing user privacy as there is a net benefit profit-wise.
IIRC, the fines are some % of revenue. Basically enough to tap into margins.
Up to 4% of global turnover, so substantial.
From personal experience, businesses I've dealt with in the EU are eager to be compliant as long as it's applied across the board (ie, they aren't losing their competitive advantage).
From personal experience, businesses I've dealt with in the EU are eager to be compliant as long as it's applied across the board (ie, they aren't losing their competitive advantage).
If it is easier to do something, more websites will do it. Passkeys make it easier to make new logins, so more websites will do it. Just like seatbelts make people drive more dangerously.
If more websites require logins, they can track you more easily, simple as that. It has nothing to do with the engineering aspects of passkeys, and everything to do with the fact that technology which makes logins easier will encourage more login-based services.
You need to step away from the engineering details and look at things sociologically.
If more websites require logins, they can track you more easily, simple as that. It has nothing to do with the engineering aspects of passkeys, and everything to do with the fact that technology which makes logins easier will encourage more login-based services.
You need to step away from the engineering details and look at things sociologically.
Doesn’t Apple Pay make it easier to not log in to websites (by getting rid of their desire to save payment details or addresses to get through later checkouts faster)? I just don’t really see some grand pro-login plan implied by Apple’s actions.
You are right. Of course, I am not talking about a conscious plan by board members or employees, but the general emergent trend inherent to this type of technology. I did not mean to imply conscious action as we know it.
> So far, no one has commented on this large downside of passkeys: that it will promote the ease of sites to require login since it's much easier to generate a passkey than to remember a new password or even store it.
Actually, this ease of use may be beneficial to privacy. Sites don’t need user generated/remembered passwords to require a login, they can just use the sign in with Google/Facebook/Apple buttons. Because it is easier than remembering another password, users will typically use those options. Passkeys is more private than signing in with Google/Facebook/Apple, while also providing more privacy than those options.
Actually, this ease of use may be beneficial to privacy. Sites don’t need user generated/remembered passwords to require a login, they can just use the sign in with Google/Facebook/Apple buttons. Because it is easier than remembering another password, users will typically use those options. Passkeys is more private than signing in with Google/Facebook/Apple, while also providing more privacy than those options.
You are ignoring the other side of the equation: more sites with logins.
Then just create a new login each visit if it's so trivial.
I don’t think this makes sense.
Sites already desperately try to get people to log in. I don’t particularly see it as an advantage for Apple if eg the Reddit website or some random online shop makes you log in. If Apple are interested in selling ads, I think they should not want to make it easy to track people on websites through logins as that helps their competitors.
I generally model Apple as preferring that you use (and pay for/in) some app rather than a website, and logins are less necessary for apps where you can store information about your session and don’t need to regularly prompt the user for passwords. I think Apple would rather you don’t have some separate account you can log into on a website to eg pay for a service without in-app-purchases.
I mostly think of passkeys as a better version of the password manager: allowing users to do what they already want in a more secure way. If there is some subtle business advantage it is maybe that users would make new accounts rather than using sign-in with Google/Facebook, though I don’t know to what extent those features are valuable to Google/Facebook.
Sites already desperately try to get people to log in. I don’t particularly see it as an advantage for Apple if eg the Reddit website or some random online shop makes you log in. If Apple are interested in selling ads, I think they should not want to make it easy to track people on websites through logins as that helps their competitors.
I generally model Apple as preferring that you use (and pay for/in) some app rather than a website, and logins are less necessary for apps where you can store information about your session and don’t need to regularly prompt the user for passwords. I think Apple would rather you don’t have some separate account you can log into on a website to eg pay for a service without in-app-purchases.
I mostly think of passkeys as a better version of the password manager: allowing users to do what they already want in a more secure way. If there is some subtle business advantage it is maybe that users would make new accounts rather than using sign-in with Google/Facebook, though I don’t know to what extent those features are valuable to Google/Facebook.
"Authentication has to be messy and painful so it isn't adopted" is an odd take.
This also seems to be the polar opposite of most complaints about passkeys. The typical response is that they won't replace passwords because passwords are easy and accessible. Here you are saying that passkeys are easier. It can't be both.
This also seems to be the polar opposite of most complaints about passkeys. The typical response is that they won't replace passwords because passwords are easy and accessible. Here you are saying that passkeys are easier. It can't be both.
This is not high on my list of concerns about passkeys.
I worry about attestation, vendor lock-in, the spec process, etc... but (if attestation isn't a huge issue) easier account creation is not a huge deal because multiple-account creation will also get a lot easier.
If a system is requiring your passkey plus a metric to verify your identity (again, assuming attestation doesn't become a problem), then they're already in a position where asking for your email is not a big deal. So I don't see how passkeys change anything for them.
On the other hand, any account that would have asked for my email before now doesn't have to. And if attestation goes well and Apple continues rejecting it for roaming providers, they won't get any information other than my login credentials. I have disposable email addresses, but most people don't. Getting rid of a factor that essentially forces them to only have a single account with a service and makes it easier to track them across services -- getting rid of that is a good thing.
There's tons to be worried about with passkeys, but this is not something that worries me. What worries me is if attestation pushes its way into the roaming provider implementations and suddenly I can't create an account on a rooted phone anymore. But getting rid of extra verification/identity steps would be good for users and good for privacy. It would be great if I could sign up for a service just with a key and without an email address.
I worry about attestation, vendor lock-in, the spec process, etc... but (if attestation isn't a huge issue) easier account creation is not a huge deal because multiple-account creation will also get a lot easier.
If a system is requiring your passkey plus a metric to verify your identity (again, assuming attestation doesn't become a problem), then they're already in a position where asking for your email is not a big deal. So I don't see how passkeys change anything for them.
On the other hand, any account that would have asked for my email before now doesn't have to. And if attestation goes well and Apple continues rejecting it for roaming providers, they won't get any information other than my login credentials. I have disposable email addresses, but most people don't. Getting rid of a factor that essentially forces them to only have a single account with a service and makes it easier to track them across services -- getting rid of that is a good thing.
There's tons to be worried about with passkeys, but this is not something that worries me. What worries me is if attestation pushes its way into the roaming provider implementations and suddenly I can't create an account on a rooted phone anymore. But getting rid of extra verification/identity steps would be good for users and good for privacy. It would be great if I could sign up for a service just with a key and without an email address.
Each website gets a unique key. They are not signed or rooted in any trust. You can still pick any username you want for the account. What passkeys do is replace OTP and MFA. They live along SSO and do not replace it.
I think the first use cases of WebAuthn were targeted at MFA, but passkeys are definitely being advertised as replacing passwords as the primary/only factor (with the caveat that you'll also be expected to perform some sort of pin/bio authentication on the local device).
> passkeys lubricate the path towards an ever-increasing login-based society where it becomes much easier to track and monitor your online behaviour
This trend is already in motion thanks to the deprecation of 3rd party cookies and Apple's restriction of device identifiers, etc, on iOS.
For most advertisers these days, the only way to run retargeting campaigns or measure conversions is with 1st party data. That means people are no longer relying on cookies at all for much of their conversion tracking. Instead, email addresses are used.
This is (I think) an unintended side effect of stripping away cookies.
At least with cookies, you could delete them locally. But now so much tracking is done with first party data, cookies are playing much less of a role. And of course there's not an easy "delete all first party data" button in your browser because the data is (obviously) held outside the browser.
This trend is already in motion thanks to the deprecation of 3rd party cookies and Apple's restriction of device identifiers, etc, on iOS.
For most advertisers these days, the only way to run retargeting campaigns or measure conversions is with 1st party data. That means people are no longer relying on cookies at all for much of their conversion tracking. Instead, email addresses are used.
This is (I think) an unintended side effect of stripping away cookies.
At least with cookies, you could delete them locally. But now so much tracking is done with first party data, cookies are playing much less of a role. And of course there's not an easy "delete all first party data" button in your browser because the data is (obviously) held outside the browser.
It's a thought provoking angle you have here for sure. However, am I right that the implication of this direction of thinking is that we should stay with our current ways of doing authentication simply because them being too hard to use puts up a natural barrier? That some of the ways in which they are broken are intrinsically good?
It's a fair point, but I'm not that worried about more logins. We're already being pushed this way by Big Business wanting more and more users to mine/advertise towards.
I worry a little about normalizing on fingerprints, but not because tin-foil-hat thinking about tracking.
Those can certainly be ordered/forced by a judge, where passwords/codes are less well defined. I'm not up to anything shady, but I fear an authoritarian government.
Let's consider PINs, too. Those can be used instead. How many of these are people going to memorize? Many passphrases become one relatively easily guessed number on a device you can lose
Implementation details, surely - and I'm really green... but I worry about unintended consequences a lot
I worry a little about normalizing on fingerprints, but not because tin-foil-hat thinking about tracking.
Those can certainly be ordered/forced by a judge, where passwords/codes are less well defined. I'm not up to anything shady, but I fear an authoritarian government.
Let's consider PINs, too. Those can be used instead. How many of these are people going to memorize? Many passphrases become one relatively easily guessed number on a device you can lose
Implementation details, surely - and I'm really green... but I worry about unintended consequences a lot
If a site requires you to create a login just to view some content, could you just create a new login each time you visit? Also that would probably kill their Google ranking.
It's also a convenient workaround to synchronize information about your online-behavior, while still being able to state publicly that your browser-history is never processed to profile you.
Upvoting this because it's a view worth sharing (and I'm sure you'll be downvoted just because of your baseless claim that Apple is concerned about something as dirty as profit /s)
Upvoting this because it's a view worth sharing (and I'm sure you'll be downvoted just because of your baseless claim that Apple is concerned about something as dirty as profit /s)
Apple is making filthy amounts of money just from hardware and app sales.
All of their attempts at targeted advertising have been rounding errors at best.
And they know that complete unbreakable privacy is the place where Google (an ad company) can never ever fully follow no matter what kind of lip service they do in their keynotes about privacy.
All of their attempts at targeted advertising have been rounding errors at best.
And they know that complete unbreakable privacy is the place where Google (an ad company) can never ever fully follow no matter what kind of lip service they do in their keynotes about privacy.
all of apple's recent growth is coming from its content ("services") business, which means it's hot to track you for advertising purposes. passkeys provide another stone in their walled garden to be able to track you but keep others from doing so as effectively, which on balance contributes to its competitive advantage.
make no mistake that this is the direction apple is headed. it's been clear for the last 5 years or so, since hardware sales have leveled off. perhaps the goggles will dampen the velocity a bit, but i'm very skeptical that the AR/VR market is mature enough to have that effect in the near future.
make no mistake that this is the direction apple is headed. it's been clear for the last 5 years or so, since hardware sales have leveled off. perhaps the goggles will dampen the velocity a bit, but i'm very skeptical that the AR/VR market is mature enough to have that effect in the near future.
Passkeys are stored in your encrypted iCloud keychain. Apple doesn't see or process what websites you're logged into on their servers.
One thing I don't understand about offering passkey login for your email is how you would go about recovering an account if you lost access to the device which holds your passkey? Google states: "When you create a passkey, you opt in to a passkey-first, password-less sign-in experience.". This seems to imply that you will not be able to use your old password if you ever lost your phone. Do Google still offer backup passwords for recovery purposes if you switch to passkeys? Their site doesn't seem to explain this.
https://support.google.com/accounts/answer/13548313?hl=en#zi...
https://support.google.com/accounts/answer/13548313?hl=en#zi...
Think of passkeys as being the same as a password database. The provider can offer whatever recovery mechanism they want, and sites that use passkeys can continue to offer account recovery methods completely independent of their use of passkeys.
As for what Google does specifically with their implementation, I'm not sure. I personally plan to use KeepassXC's implementation, whenever that comes out, with my own custom database backup strategy.
As for what Google does specifically with their implementation, I'm not sure. I personally plan to use KeepassXC's implementation, whenever that comes out, with my own custom database backup strategy.
This is an area with the specs contrast with the vendors.
The WebAuthn specs recommends to register multiple passkeys/credentials per device and assume that once a credential is lost it might not be recoverable.
Apple and other vendors using keychains/wallets are effectively offering the option to delegate the recovery of the passkey to the recovery of the account with them (eg: the iCloud account).
In case it is of interest, we wrote a long blogpost on the topic: https://www.slashid.dev/blog/passkeys-security-implementatio...
The WebAuthn specs recommends to register multiple passkeys/credentials per device and assume that once a credential is lost it might not be recoverable.
Apple and other vendors using keychains/wallets are effectively offering the option to delegate the recovery of the passkey to the recovery of the account with them (eg: the iCloud account).
In case it is of interest, we wrote a long blogpost on the topic: https://www.slashid.dev/blog/passkeys-security-implementatio...
[deleted]
You can still use your password today on a Google account with passkeys. And account recovery via other means (depending on a lot of things) is still available.
It's too early to completely replace all methods with passkeys, but the hope is that as they gain better support and understanding websites will be able to make other methods rare/exceptional. For exceptional cases such as account recovery, as opposed to day-to-day account sign-in, there is room to apply a lot of other abuse signals and other methods to make it harder for attackers.
More here: https://security.googleblog.com/2023/05/so-long-passwords-th....
It's too early to completely replace all methods with passkeys, but the hope is that as they gain better support and understanding websites will be able to make other methods rare/exceptional. For exceptional cases such as account recovery, as opposed to day-to-day account sign-in, there is room to apply a lot of other abuse signals and other methods to make it harder for attackers.
More here: https://security.googleblog.com/2023/05/so-long-passwords-th....
[deleted]
[deleted]
Same way as you recover a password stored in your password manager. It's pretty much the same thing.
The way I do that is I memorise my password manager master key. How do I do that with a passkey?
Same way, your password manager will hold the passkey token instead of password. Recovering passkey is done the same as you recover your random generated password.
Email magic link, recovery codes, web of trust (recovery contacts), or remote government credentials proofing (ID.me, Stripe Identity, etc).
My method for judging the quality of software: Read the latest release notes, negate every statement, and think to yourself: "They were fine with it being like this until now."
Passkeys have been advertised as a superior replacement to passwords, but really fundamental issues remain unaddressed.
I have one (1) Windows PC and one (1) iDevice. Can I get these to sync? Will both be able to log me in to a Google Account? Or do I need an Android phone for that? Can I use an iDevice to authenticate with an Azure AD app? Can I recover the passkeys on a lost iDevice without having to pay Apple for a new device to restore the backup? Etc...
I guarantee many more release notes that could be summarised as: "Now supports a common scenario!"
Passkeys have been advertised as a superior replacement to passwords, but really fundamental issues remain unaddressed.
I have one (1) Windows PC and one (1) iDevice. Can I get these to sync? Will both be able to log me in to a Google Account? Or do I need an Android phone for that? Can I use an iDevice to authenticate with an Azure AD app? Can I recover the passkeys on a lost iDevice without having to pay Apple for a new device to restore the backup? Etc...
I guarantee many more release notes that could be summarised as: "Now supports a common scenario!"
> I have one (1) Windows PC and one (1) iDevice. Can I get these to sync? Or do I need an Android phone for that?
Yes. In Chromium-based browsers, at least. Your browser will display a QR code which you scan with your phone. Your phone will display a list of accounts you can sign in with, you select one, authenticate, and you're logged in. Firefox support isn't here yet.
Yes. In Chromium-based browsers, at least. Your browser will display a QR code which you scan with your phone. Your phone will display a list of accounts you can sign in with, you select one, authenticate, and you're logged in. Firefox support isn't here yet.
Passkey proponents have played really fast and loose with the word "sync" in my experience. No reasonable outside observer would call this syncing, it's cross-device sign-in.
It's like saying you can sync your OTP-provider to your desktop computer because when you go to log into a website you manually copy the code into a form. That's not how most people understand the word "sync."
What people are excited about here (assuming the details are good) is actual sync -- the ability to take your iCloud passkeys and literally move them to a new device outside of Apple's ecosystem as a mass operation rather than site-by-site. And that's really good and I'm excited about it and I hope that it addresses all of my issues. But its frustrating to see people still misrepresenting what's capable with the ecosystem today even under a positive announcement that signals that the actual concerns are getting addressed.
It's so weird, I don't know of any other open standard I've seen where the proponents are so creative about acting like the ecosystem already supports things that aren't supported yet, and it's a huge reason why I remain skeptical of the passkey ecosystem -- because there are good-faith actors telling me to trust them but they're surrounded by people who are straight-up giving incorrect answers to basic questions like "is sync supported." I don't get it. If the limitations are going to be addressed, what is the value in pretending that they don't exist? How does the ecosystem benefit from that? All it does is decrease trust, to the point where I feel like I need to double-check every assurance I get from FIDO advocates to make sure that they're not redefining words.
It's like saying you can sync your OTP-provider to your desktop computer because when you go to log into a website you manually copy the code into a form. That's not how most people understand the word "sync."
What people are excited about here (assuming the details are good) is actual sync -- the ability to take your iCloud passkeys and literally move them to a new device outside of Apple's ecosystem as a mass operation rather than site-by-site. And that's really good and I'm excited about it and I hope that it addresses all of my issues. But its frustrating to see people still misrepresenting what's capable with the ecosystem today even under a positive announcement that signals that the actual concerns are getting addressed.
It's so weird, I don't know of any other open standard I've seen where the proponents are so creative about acting like the ecosystem already supports things that aren't supported yet, and it's a huge reason why I remain skeptical of the passkey ecosystem -- because there are good-faith actors telling me to trust them but they're surrounded by people who are straight-up giving incorrect answers to basic questions like "is sync supported." I don't get it. If the limitations are going to be addressed, what is the value in pretending that they don't exist? How does the ecosystem benefit from that? All it does is decrease trust, to the point where I feel like I need to double-check every assurance I get from FIDO advocates to make sure that they're not redefining words.
my mistake
That's not what I mean by "sync". If I don't have the phone with me, I can't authenticate.
Also, I use Firefox exclusively.
This is precisely what I mean: common scenarios are not yet supported.
Also, I use Firefox exclusively.
This is precisely what I mean: common scenarios are not yet supported.
You’re somewhat missing the point of what passkeys are. Instead of the something you know part, i.e. a password, the authentication is done by something you have. Your common use case is only common to single factor password authentication. It’s not a situation that is allowed for in passkey’s security model.
> I have one (1) Windows PC and one (1) iDevice. Can I get these to sync?
"Why? Where's the profit for us in that case?"
"Why? Where's the profit for us in that case?"
Easy. Think of passkeys as per-device credentials. You can have (1) windows PC credential and (1) iDevice credential, and register both with Google and Azure.
> Will both be able to log me in to a Google Account? Or do I need an Android phone for that?
Yes and no, respectively.
Yes and no, respectively.
There is only this blurb to go on at the moment:
"Passkeys can now be synced using external providers..."
so it's hard to say exactly what it will mean for user control and choice. Which external providers? Will users be able to access and store their own private keys in compatible apps of their choosing? If so, aren't we largely back to passwords?
"Passkeys can now be synced using external providers..."
so it's hard to say exactly what it will mean for user control and choice. Which external providers? Will users be able to access and store their own private keys in compatible apps of their choosing? If so, aren't we largely back to passwords?
> aren't we largely back to passwords?
A password is a shared secret. Even if it's hashed on the server side, one could brute force it if a weak algorithm is used, or MiTM the service to get the plaintext when the user logs in.
Passkeys / webauthn utilizes public key cryptography. I'm only ever giving them a (by the spec, unique to the combo of me and the site in question) public key to which I hold the private key pair.
Authentication doesn't involve transmission of these, it's challenge based where you prove you have access to the corresponding private key.
A password is a shared secret. Even if it's hashed on the server side, one could brute force it if a weak algorithm is used, or MiTM the service to get the plaintext when the user logs in.
Passkeys / webauthn utilizes public key cryptography. I'm only ever giving them a (by the spec, unique to the combo of me and the site in question) public key to which I hold the private key pair.
Authentication doesn't involve transmission of these, it's challenge based where you prove you have access to the corresponding private key.
> aren't we largely back to passwords?
Key based authentication is a huge security improvement over passwords (especially for reducing phishing risks) even without the device-bound restrictions.
I'm strongly opposed to hardware-bound keys as a mass standard for most users, but key based authentication is great. One big advantage is that during the login process, sites "prove" their identity to you.
This is a security improvement that you could previously only really get with browser extensions and password managers, and even there it wasn't great because those extensions didn't work consistently across all sites and often failed at autofill, so a website failing to pull up your password manager might not actually be interpreted as a red flag. And there are other advantages too around account security for service providers, etc... none of which require attestation or hardware-bound keys.
Key based authentication is a huge security improvement over passwords (especially for reducing phishing risks) even without the device-bound restrictions.
I'm strongly opposed to hardware-bound keys as a mass standard for most users, but key based authentication is great. One big advantage is that during the login process, sites "prove" their identity to you.
This is a security improvement that you could previously only really get with browser extensions and password managers, and even there it wasn't great because those extensions didn't work consistently across all sites and often failed at autofill, so a website failing to pull up your password manager might not actually be interpreted as a red flag. And there are other advantages too around account security for service providers, etc... none of which require attestation or hardware-bound keys.
Passkeys still involve storing a secret, which I think is fundamentally what all security/authentication is built around. Passkey eliminates a lot of the issues with passwords (transmitting the plain text to the app, password reuse, simple passwords).
If you've been using a password manager with randomly generated passwords you've already addressed some of these issues so the benefits of using passkeys over passwords is reduced.
If you've been using a password manager with randomly generated passwords you've already addressed some of these issues so the benefits of using passkeys over passwords is reduced.
That's great to see! I just tried out 1Password's beta browser extension which has passkeys support, and the UX is super seamless. Played around with it on https://www.passkeys.io/
I'm really hopeful about this, a lot more than any of the previous iterations of the FIDO stuff. I worked at a company that was an early adopter/implementer of the original FIDO U2F spec, and it had major UX problems, enough that I couldn't see it ever being used by the general public (who the heck would carry a USB key with them?? and this only works with desktops/laptops, sure Bluetooth support, but ehhh), but with this, synced to your password manager of choice, that's A LOT better.
The passkey is usable anywhere (signed up on my desktop, hopped over to my laptop and signed in there with the same passkey). I can't use it from my Android phone yet, but that will come soon I'm sure when 1Password adds support to the mobile apps + Google does the same as Apple here with adding proper Android integration.
On Android I can still only use a USB/NFC/Bluetooth security key, or "my lock screen" (i.e. on-device security key, not passkeys) so far. If I click on "Sign in with a passkey" it says I have no passkeys via an Android system dialog, but if I sign in with my email it lets me use my "security key" (i.e. biometric lock screen prompt).
I'm really hopeful about this, a lot more than any of the previous iterations of the FIDO stuff. I worked at a company that was an early adopter/implementer of the original FIDO U2F spec, and it had major UX problems, enough that I couldn't see it ever being used by the general public (who the heck would carry a USB key with them?? and this only works with desktops/laptops, sure Bluetooth support, but ehhh), but with this, synced to your password manager of choice, that's A LOT better.
The passkey is usable anywhere (signed up on my desktop, hopped over to my laptop and signed in there with the same passkey). I can't use it from my Android phone yet, but that will come soon I'm sure when 1Password adds support to the mobile apps + Google does the same as Apple here with adding proper Android integration.
On Android I can still only use a USB/NFC/Bluetooth security key, or "my lock screen" (i.e. on-device security key, not passkeys) so far. If I click on "Sign in with a passkey" it says I have no passkeys via an Android system dialog, but if I sign in with my email it lets me use my "security key" (i.e. biometric lock screen prompt).
> who the heck would carry a USB key with them??
> but with this, synced to your password manager of choice, that's A LOT better
While I agree with your general point that passkeys are great, I strongly disagree with these specific points. It's much easier for me to carry a small usb-key everywhere than it is to carry a big-ass phone (I often leave it at home) or my own computer.
With a yubikey on my keychain, I can log into my company's AzureAD from any computer. In a pinch, this also works on a phone if it has an NFC reader. It used to work fine on my iphone 7.
Another use case is specifically not wanting anything company-related on my own computing device. My personal phone isn't enrolled in the company's AzureAD, I don't have their 1passwork vault there, etc.
> but with this, synced to your password manager of choice, that's A LOT better
While I agree with your general point that passkeys are great, I strongly disagree with these specific points. It's much easier for me to carry a small usb-key everywhere than it is to carry a big-ass phone (I often leave it at home) or my own computer.
With a yubikey on my keychain, I can log into my company's AzureAD from any computer. In a pinch, this also works on a phone if it has an NFC reader. It used to work fine on my iphone 7.
Another use case is specifically not wanting anything company-related on my own computing device. My personal phone isn't enrolled in the company's AzureAD, I don't have their 1passwork vault there, etc.
I'm talking about the "personal use" usecase and not the professional/business usecase. I agree with the value of security keys as being a physical token with low/no risk of leaking. But for personal use there's no way I can make that work for me day-to-day, even less of a chance I could get my parents bought-in on that idea. And I've tried, as someone who actually developed software to interface with this tech directly. I always have my phone with me, but if not, I can always login to my cloud-synced password manager in a pinch. (Worth mentioning, I don't have the same paranoia as some regarding cloud-synced vaults when done right, big reason I left that aforementioned company).
> who the heck would carry a USB key with them??
Why not? I do this. It's no different from any other physical key like a door key, and I keep it on the same keychain too...
> The passkey is usable anywhere (signed up on my desktop, hopped over to my laptop and signed in there with the same passkey).
I don't see how this conflicts with physical tokens like Yubikeys? The tokens help you "remember" the key like how a physical door key helps you "remember" the bitting (which is the real authentication info).*
Just like passkeys, U2F can also be done using a virtual U2F device if you so choose (https://github.com/bulwarkid/virtual-fido). And presumably you could create an off-device portable token to store passkeys...
The real problem at the end of the day is just consistent adoption. There's still a ton of 2FA services that don't accept U2F and only use SMS or email codes...
*: This is a simplified take on things but at a high level that's what's happening.
Why not? I do this. It's no different from any other physical key like a door key, and I keep it on the same keychain too...
> The passkey is usable anywhere (signed up on my desktop, hopped over to my laptop and signed in there with the same passkey).
I don't see how this conflicts with physical tokens like Yubikeys? The tokens help you "remember" the key like how a physical door key helps you "remember" the bitting (which is the real authentication info).*
Just like passkeys, U2F can also be done using a virtual U2F device if you so choose (https://github.com/bulwarkid/virtual-fido). And presumably you could create an off-device portable token to store passkeys...
The real problem at the end of the day is just consistent adoption. There's still a ton of 2FA services that don't accept U2F and only use SMS or email codes...
*: This is a simplified take on things but at a high level that's what's happening.
> Why not? I do this.
Again, you are not the general public. You're a highly technical person. My dad/grandma would never. That's the point.
Again, you are not the general public. You're a highly technical person. My dad/grandma would never. That's the point.
Are you saying they don't use any physical keys? That would be surprising to me...
I've found it really easy to teach non-technical people how to use U2F tokens. Just tell them it's like a door key but instead of plugging it in and turning, you plug it in and touch. That's all there is. It's been much more intuitive* to my older family members than SMS codes (that sometimes get lost), authenticator apps (that have a huge list of services from which you need to quickly find the one you want and type the code), or password managers (that either cost money or are difficult to set up across devices).
*: I know this because I've never had to do "tech support" for family members that have accounts set up to use U2F tokens, but I have had plenty of calls related to "not getting the SMS code" or "the (insert brand) password manager isn't filling in the password for my account!"
I've found it really easy to teach non-technical people how to use U2F tokens. Just tell them it's like a door key but instead of plugging it in and turning, you plug it in and touch. That's all there is. It's been much more intuitive* to my older family members than SMS codes (that sometimes get lost), authenticator apps (that have a huge list of services from which you need to quickly find the one you want and type the code), or password managers (that either cost money or are difficult to set up across devices).
*: I know this because I've never had to do "tech support" for family members that have accounts set up to use U2F tokens, but I have had plenty of calls related to "not getting the SMS code" or "the (insert brand) password manager isn't filling in the password for my account!"
The difference is that I can know with significant certainty that shoving my house key in a random lock won't copy the form of my key and send it to a 3D printer where a thief will get it and use it to access my house.
How can I know that won't happen when I use my USB dongle on a random coffee shop public computer?
How can I know that won't happen when I use my USB dongle on a random coffee shop public computer?
This is exactly what U2F protects you from!
You can actually safely plug U2F tokens into random computers and rest assured that the keys inside cannot be cloned. This provides security guarantees above and beyond that of physical keys! In fact, an untrusted computer can't* even MITM the authentication process of U2F, unlike with SMS codes! (Of course, an untrusted computer could fake the UI to try and exfiltrate other info from you, but that's beyond the scope of authentication itself.)
The worst a malicious client can do to a U2F token is to fry it :-)
*: There's some asterisks here, but if you want to know the details check out the U2F spec or this https://www.yubico.com/blog/creating-unphishable-security-ke... for a more accessible explanation. Banking-grade U2F/similar tokens actually behave like hardware crypto wallets and will show the auth request metadata on an internal screen, in case the device you are plugging into is completely untrustworthy.
You can actually safely plug U2F tokens into random computers and rest assured that the keys inside cannot be cloned. This provides security guarantees above and beyond that of physical keys! In fact, an untrusted computer can't* even MITM the authentication process of U2F, unlike with SMS codes! (Of course, an untrusted computer could fake the UI to try and exfiltrate other info from you, but that's beyond the scope of authentication itself.)
The worst a malicious client can do to a U2F token is to fry it :-)
*: There's some asterisks here, but if you want to know the details check out the U2F spec or this https://www.yubico.com/blog/creating-unphishable-security-ke... for a more accessible explanation. Banking-grade U2F/similar tokens actually behave like hardware crypto wallets and will show the auth request metadata on an internal screen, in case the device you are plugging into is completely untrustworthy.
A random lock (or a street-level camera FWIW [1]) would be better positioned to extract enough data to reproduce the key.
U2F tokens are "Trusted Platform Modules" of sorts. The keys themselves are never visible to the devices you plug them in. They are capable of answering challenge/responses, and having the URL part of the challenge prevents phishing[2].
I am much more comfortable not typing any password on a public computer.
[1]: https://www.wired.com/2015/09/lockpickers-3-d-print-tsa-lugg...
[2]: https://en.wikipedia.org/wiki/Universal_2nd_Factor#Advantage...
U2F tokens are "Trusted Platform Modules" of sorts. The keys themselves are never visible to the devices you plug them in. They are capable of answering challenge/responses, and having the URL part of the challenge prevents phishing[2].
I am much more comfortable not typing any password on a public computer.
[1]: https://www.wired.com/2015/09/lockpickers-3-d-print-tsa-lugg...
[2]: https://en.wikipedia.org/wiki/Universal_2nd_Factor#Advantage...
Okay.
How is that different from a password? How can you know that when you type your password into a random coffee shop public computer that the computer isn't running a keylogger and sending your credentials to criminals?
How is that different from a password? How can you know that when you type your password into a random coffee shop public computer that the computer isn't running a keylogger and sending your credentials to criminals?
> I can know with significant certainty that shoving my house key in a random lock won't copy the form of my key and send it to a 3D printer
Are you sure? https://www.minutekey.com/products/key-copy-kiosk/
Are you sure? https://www.minutekey.com/products/key-copy-kiosk/
You are literally wrong on both cases: A normal key can be quite easily copied and a yubikey or similar security key cannot be copied.
I did a WebAuthn implementation at work and the UX for WebAuthn was fucking awful. Especially on macOS, every browser had a completely separate implementation of WebAuthn, and if you used the Touch ID as a WebAuthn device, you basically could not see it anywhere and deleting it was also a pain in the ass. On Chrome, you basically had to just delete all of your passwords for the last N days to get rid of them.
On Windows, I think all browsers handled it centrally with Windows Hello, but even there the WebAuthn devices just kinda disappear into the ether once you register them, and deleting them had to be done through the command-line. There were also weird ass bugs where the UI would behave completely differently depending on whether or not you had Windows Hello login in use, so websites would need to engineer around it.
Haven't played around with passkeys key, but I imagine the only direction to go is up.
On Windows, I think all browsers handled it centrally with Windows Hello, but even there the WebAuthn devices just kinda disappear into the ether once you register them, and deleting them had to be done through the command-line. There were also weird ass bugs where the UI would behave completely differently depending on whether or not you had Windows Hello login in use, so websites would need to engineer around it.
Haven't played around with passkeys key, but I imagine the only direction to go is up.
Yeah. With 1Password it's just another item like a password, but named "passkey". And in the browser when you set it up or use it, you get a little overlay on the website in the top-right and you click on it. That's it. Super simple, no faff, full visibility.
Is the whole idea of syncing passkeys a bad idea? Or at least a less secure idea. Someone explained to me that passkeys are hardware backed, each passkey is stored on device and tied to the hardware, so even if someone managed to get access to it, they would also need the hardware to get it to work. These software based keys that can be synced are less secure as a result. Then it just becomes like a password again.
I need to read up a bit more on passkeys in general tbh.
I need to read up a bit more on passkeys in general tbh.
Passkeys as a brand include both hardware-backed keys that can't be exported and are device-specific. These can be used for things like 2FA/MFA-type scenarios. They also involve a lot of site-specific keys that may not be hardware-backed and syncable. The neat fun thing is that they can be synced with hardware-backed keys for strong E2E between a user's enrolled devices and only the user's enrolled devices (plus maybe a hard to use recovery key). (That's basically how iCloud's Password/Passkey store and a lot of iCloud E2E in general seems to work.)
Passkeys in general, especially the focus on a lot of site-specific E2E shared ones, are very much "just like a password", but as the sibling comment points out, the switch to PKI alone is a huge security win and would stop a lot of the haveibeenpwned sorts of leaks and the overall attractiveness to crackers to break into various company's password databases, because only having a public key is a lot less useful than a salted/hashed password that might be broken or found in a rainbow table.
Passkeys in general, especially the focus on a lot of site-specific E2E shared ones, are very much "just like a password", but as the sibling comment points out, the switch to PKI alone is a huge security win and would stop a lot of the haveibeenpwned sorts of leaks and the overall attractiveness to crackers to break into various company's password databases, because only having a public key is a lot less useful than a salted/hashed password that might be broken or found in a rainbow table.
It is less secure, but more convenient. You can pick either option. Or you can have both with delegation ("your husband is trying to log in as you on www.google.com, allow?").
I think passkeys + 2FA is enough. Just enforce 2FA for any important service and it will be fine, if you don't force it then people who aren't as tech savvy will not do it or people may forget.
For anything non-important I actually use sign in with Google, so.
For anything non-important I actually use sign in with Google, so.
1. article says nothing about external identity providers. which is what everyone here wants. still fully locked in.
2. it only hints at the UI being open to other apps, approved in the app store of course, using their new undocumented api
3. the sharing features will probably happens over their central control. not over the UI implementers.
so many misconceptions in these comments. specially mixing up passkeys with in device keys
2. it only hints at the UI being open to other apps, approved in the app store of course, using their new undocumented api
3. the sharing features will probably happens over their central control. not over the UI implementers.
so many misconceptions in these comments. specially mixing up passkeys with in device keys
It starts out saying "Passkeys can now be synced using external providers", how does it say nothing about external providers? I'd love to see the detail as well but, lacking that, there is nothing in the article that says these takes are correct and the others misconceptions either.
This is a smart move by Apple. Authentication infrastructure is necessarily cross platform. It doesn’t generate revenue for Apple, but the lack of cross platform auth would limit enterprise adoption of Apple products.
Passkeys (otherwise known as WebAuthn) isn’t an Apple specific standard though.
Absolutely. 1Password is betting heavily on being the passkey clearing house for enterprise. I think what Apple is doing here is saying that companies like 1Password can do this for their flavor of WebAuthn too.
> It doesn’t generate revenue for Apple,
but it creates lock-in, if all your credentials are in a iCloud keychain, you're encouraged to get a phone that can sync with your ipad, laptop, and desktop.
Manually find and re-sync your stuff from firefox-on-desktop to chrome-on-mobile to safari-on-ipad is a major PITA.
but it creates lock-in, if all your credentials are in a iCloud keychain, you're encouraged to get a phone that can sync with your ipad, laptop, and desktop.
Manually find and re-sync your stuff from firefox-on-desktop to chrome-on-mobile to safari-on-ipad is a major PITA.
And it creates nicely labeled and synchronized information of when and how often a user logged into a eCommerce service/Streaming portal/..., while still being able to state that your browser history is never processed for profiling...
Good news. Lock-in was one of the biggest issues with passkeys. I think we will see a bunch of well known password managers adding passkey support soon.
Is there any standard for this integration/interoperability? What about moving from one provider/app to another?
Is there any standard for this integration/interoperability? What about moving from one provider/app to another?
you fell for it.
the article says nothing to that end. still full locked in.
the UI will allow implementations... via app stores approved apps using their OS apis. for sure.
the article says nothing to that end. still full locked in.
the UI will allow implementations... via app stores approved apps using their OS apis. for sure.
I'm totally in if passkeys come without middle men, especially like Google and Apple. Otherwise I'm totally out. No trust in these guys, they are as capricious as Roman emperors and will eventually do their usual stuff: lock in and collusion.
I've got a big problem with the attestation feature even existing in the spec. I know Apple plans to "zero it out" but if that changed sites could lock out non approved devices. I'd vastly prefer it wasn't part of the spec at all rather than relying upon the whims of a single megacorporation. If they ever drop that cover things will gradually become defacto locked to middlemen anyway.
This is a great point. I'm really happy about Apple's plans, but I have a hard time taking it at face value that there's nothing to worry about here if there's resistance to putting that plan into the spec itself.
Because I start to get suspicious any time a company says, "we're not going to do X, but we absolutely refuse to commit in any meaningful way to not doing X."
There's an implication there. I feel the same way about syncing, honestly:
"Everyone is going to support 3rd-pary sync."
"Can we put it in the spec that they have to?"
"Well, that would be overreaching..."
I think there are a lot of people who have genuinely good intentions, but it still makes me pretty nervous. If we could just trust every company to magically work things out and be compatible with everyone, we wouldn't need industry specifications in the first place. I think it's appropriate to try and standardize the baseline mechanisms users should have to control their keys and preserve their privacy.
Because I start to get suspicious any time a company says, "we're not going to do X, but we absolutely refuse to commit in any meaningful way to not doing X."
There's an implication there. I feel the same way about syncing, honestly:
"Everyone is going to support 3rd-pary sync."
"Can we put it in the spec that they have to?"
"Well, that would be overreaching..."
I think there are a lot of people who have genuinely good intentions, but it still makes me pretty nervous. If we could just trust every company to magically work things out and be compatible with everyone, we wouldn't need industry specifications in the first place. I think it's appropriate to try and standardize the baseline mechanisms users should have to control their keys and preserve their privacy.
Exactly. Middle men are not needed. Passkeys can and should be handled by an open specification. In this way, passkeys will be decentralized and can be supported by anyone and everywhere.
Users should decide by themselves where they want to store the authenticator: be it a separate device or a password manager running on their computer. Authenticator is just an algorithm that uses key material from elsewhere (biometrics, master password, whatever user prefers) to perform the authentication.
Tying the whole thing to a couple of corps is cringy and creepy at the same time. There must be an open standard where everyone can participate.
Users should decide by themselves where they want to store the authenticator: be it a separate device or a password manager running on their computer. Authenticator is just an algorithm that uses key material from elsewhere (biometrics, master password, whatever user prefers) to perform the authentication.
Tying the whole thing to a couple of corps is cringy and creepy at the same time. There must be an open standard where everyone can participate.
My main concern with passkeys is I'm not aware of a way to pre-authorize someone who doesn't yet have an account. For example, with email I can just grant X access to anyone who can prove they have access to Y email address. But passkeys don't have a single public handle like this. This isn't such a big deal with centralized services where everyone is likely to already have an account, but might pose a problem for selfhosted services. Still, I like passkeys and wish there was a way to have my cake and eat it too.
Until I can export a passkey to KeePassXC I won't use it. How do you recover your account if you're locked out? Or if Google decides to ban you?
Hopefully this comes to Strongbox soon!
Interesting, but can someone tell us what this implies wrt. authorities? If someone gets your iPhone and forces you to press your finger on the TouchID, he gets all your passwords no? While with a general master password you could just pretend to have forgotten it?
In good news, a somewhat recent CBP case recently ruled in favor of Touch ID coercion needing a warrant and may be the start of a wave of change in court precedents to stop authorities from abusing biometric loopholes. One court win does not set a new precedent, of course, but it is hope that change may come.
Whichever way you look at it, in every sense, password managers are a really bad, bad idea.
Besides that, it is not needed to force you to press your finger; the delinquent needs only to have access to the device for to fool the sensor with a brute force, 2 hours in the worse of the cases with the simplest techniques. Although its easier to take your finger prints from a glass or something you used for to avoid the wait, or directly cut your finger if its a psychopathic criminal.
And in all the cases, once your fingerprint gets public it gets compromised until the end of the times, of course, you can not "change the passw".
This without talking about software infection with a remote attack.
Besides that, it is not needed to force you to press your finger; the delinquent needs only to have access to the device for to fool the sensor with a brute force, 2 hours in the worse of the cases with the simplest techniques. Although its easier to take your finger prints from a glass or something you used for to avoid the wait, or directly cut your finger if its a psychopathic criminal.
And in all the cases, once your fingerprint gets public it gets compromised until the end of the times, of course, you can not "change the passw".
This without talking about software infection with a remote attack.
I don't mean this personal, but I find it very very hard to deal with people like you in professional contexts. You focus on a 0.01% problem and make an absolute statement ("in every sense, password managers are a really bad, bad idea"), while completely ignoring that for everybody else, password managers (and even more so passkeys) will prevent real problems like their bank account being emptied.
> Whichever way you look at it, in every sense, password managers are a really bad, bad idea.
Okay, how about, the actual problem they solved: Reusing a single, simple password on every site, shared behind an email login.
That doesn’t sound like a really, really bad idea.
Okay, how about, the actual problem they solved: Reusing a single, simple password on every site, shared behind an email login.
That doesn’t sound like a really, really bad idea.
At what point did password managers invent the idea of using a different password for each account? That is computing basics from the beginning. They didn't solve a problem, they just increased the lottery prize if the master password gets compromised.
Every body can continue down-voting, but that fact is not going to change.
Every body can continue down-voting, but that fact is not going to change.
> At what point did password managers invent the idea of using a different password for each account?
They didn't invent the idea.
They just made it useable for people who have a lot of different accounts.
I've got nearly 500 accounts, and based on a comment thread a while back where someone asked here how many accounts people have in their password managers I'm on the low side.
They didn't invent the idea.
They just made it useable for people who have a lot of different accounts.
I've got nearly 500 accounts, and based on a comment thread a while back where someone asked here how many accounts people have in their password managers I'm on the low side.
No, the lottery prize is exactly the same: Access to every site in the list.
The lottery chances have, however, dramatically changed, from no longer relying on the ongoing security practices of every single website you have ever signed into once being eternally a risk to breaching every single other website you have ever signed into.
Perhaps you alone can remember a cryptographically secure password for every website. But I’d more suspect your downvotes come from the impression you give of apparent inexperience combined with what looks like a child-like propensity to bluster.
The lottery chances have, however, dramatically changed, from no longer relying on the ongoing security practices of every single website you have ever signed into once being eternally a risk to breaching every single other website you have ever signed into.
Perhaps you alone can remember a cryptographically secure password for every website. But I’d more suspect your downvotes come from the impression you give of apparent inexperience combined with what looks like a child-like propensity to bluster.
Password managers did not invent this idea, but we can observe people consistently reusing passwords when they don't have a password manager. It is just undeniable at this point that users cannot be expected to consistently create strong and unique passwords for each service.
> if the master password get compromised.
... and if a copy of the password wallet has been obtained.
... and if a copy of the password wallet has been obtained.
I would argue that password managers are not a "in every sense a really bad, bad idea" for a lot of reasons.
Let's look at password reuse for example. As soon as you have more than a few dozen logins, the possibilities are mostly either reusing one or few passwords, or writing them down.
Reusing is objectively bad, and for writing them down, the password manager makes it easy to use a really long and random password, which would make it tedious to write down.
Let's look at password reuse for example. As soon as you have more than a few dozen logins, the possibilities are mostly either reusing one or few passwords, or writing them down.
Reusing is objectively bad, and for writing them down, the password manager makes it easy to use a really long and random password, which would make it tedious to write down.
Password managers makes the user life easier, at a big price if the master password gets compromised, as all the passwords get compromised at same time, in an unified way that by other methods would require much more specialization and effort for to gather together.
If that passwords are stored in internet even worst, one can take for sure those passw-managing servers are juicy targets, it is a countdown until the server will get compromised.
If the user is only storing the pass of chat forums, I think then is one thing the attacker probably will ignore, if the reverse engineering of one of those sites using user's name is not in the secondary target list.
Anyway, to use a unique password for every server, account, etc is a must do from the beginning of time, even for the temporal forum one had to register for to use a few minutes. It is the first computing directive. It's just the password managers are not accomplishing the objective of such directive.
If that passwords are stored in internet even worst, one can take for sure those passw-managing servers are juicy targets, it is a countdown until the server will get compromised.
If the user is only storing the pass of chat forums, I think then is one thing the attacker probably will ignore, if the reverse engineering of one of those sites using user's name is not in the secondary target list.
Anyway, to use a unique password for every server, account, etc is a must do from the beginning of time, even for the temporal forum one had to register for to use a few minutes. It is the first computing directive. It's just the password managers are not accomplishing the objective of such directive.
Just because something is a "first computing directive", that doesn't mean people do it. If you're capable of remembering hundreds of high-entropy passwords, more power to you, but that approach doesn't work for most people. Password managers are better than reusing passwords between services, which in the real world, is the alternative.
I have hundreds of sites in my password database. Can you remember hundreds of random 32 character strings? I can't and I think there are very few humans who can
How do you remember unique, strong passwords for a couple dozen sites?
> once your fingerprint gets public it gets compromised until the end of the times
I'll just respond to this, as the other commenters are doing a fine job of addressing your other claims.
Your passwords aren't encrypted with biometric data of any kind on Apple devices (and I suspect that's true of Android as well). Simplifying a bit here, but it's broadly accurate: your biometric doesn't unlock your entire password database, it unlocks the stored secrets needed to decrypt your password database. iOS (and, likely, Android) devices have a simple way to force a passcode/password to be entered rather than using biometric data to unlock the device.
On iOS, activating the Emergency SOS feature (without subsequently calling emergency services) and then locking the device as normal (with the power button) will require the first factor (your passcode/password) at the next unlock attempt. No amount of finger-cutting or face-slicing can get past it. It's been that way for six years now, and was famously referred to as "the cop button" when iOS 11 introduced the feature.
I'll just respond to this, as the other commenters are doing a fine job of addressing your other claims.
Your passwords aren't encrypted with biometric data of any kind on Apple devices (and I suspect that's true of Android as well). Simplifying a bit here, but it's broadly accurate: your biometric doesn't unlock your entire password database, it unlocks the stored secrets needed to decrypt your password database. iOS (and, likely, Android) devices have a simple way to force a passcode/password to be entered rather than using biometric data to unlock the device.
On iOS, activating the Emergency SOS feature (without subsequently calling emergency services) and then locking the device as normal (with the power button) will require the first factor (your passcode/password) at the next unlock attempt. No amount of finger-cutting or face-slicing can get past it. It's been that way for six years now, and was famously referred to as "the cop button" when iOS 11 introduced the feature.
Any details on how passkeys sync using external providers?
next headline -- Passkeys now require external providers
update this dev news announcement actually opens the setup a bit more, instead of close it down a bit more. However the whole Apple walled garden and always-on networking is not a happy thing from this desk
update this dev news announcement actually opens the setup a bit more, instead of close it down a bit more. However the whole Apple walled garden and always-on networking is not a happy thing from this desk
I still want to see more details. That being said, extremely positive news. Vendor lock-in is one of the biggest issues with passkeys and one of the biggest reasons I haven't been able to get on board with them and why I usually end up advocating against them whenever they come up.
Between this and Apple blocking attestation efforts for mobile passkeys, it gives me more confidence that this could turn into a standard that I want to use. I criticize the passkey standard pretty consistently, I would be very happy to eat crow on that.
I will say that it would go a long way to make this stuff part of the standard, I don't like how much these really critical pieces of passkey functionality are boiling down to "wait and see what vendors do." But I'm cautiously optimistic to see where things go. It is a really big deal for Apple to support 3rd-party providers and an even bigger deal for Apple to support sync with 3rd-party providers.
Between this and Apple blocking attestation efforts for mobile passkeys, it gives me more confidence that this could turn into a standard that I want to use. I criticize the passkey standard pretty consistently, I would be very happy to eat crow on that.
I will say that it would go a long way to make this stuff part of the standard, I don't like how much these really critical pieces of passkey functionality are boiling down to "wait and see what vendors do." But I'm cautiously optimistic to see where things go. It is a really big deal for Apple to support 3rd-party providers and an even bigger deal for Apple to support sync with 3rd-party providers.
> 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.