Passkeys are WebAuthn under the hood; they don't store your credentials with a large company any more than using a hardware token stores your credentials with Yubikey.

Apple does some additional trickery to synchronize credentials between devices, but they get away with this because their devices have contained dedicated silicon for sensitive data management for years[1]. They have some user-facing documentation on how their passkey implementation is synchronized between devices without any secret disclosure here[2][3].

[1]: https://support.apple.com/guide/security/secure-enclave-sec5...

[2]: https://support.apple.com/en-us/HT213305

[3]: https://support.apple.com/guide/security/keychain-data-prote...

Apple can synchronize the passkey between devices. As far as I understand I cannot. So I don't really understand how this can be said to be a hardware security token. It seems pretty clear that it is as far as I am concerned, but that Apple has nothing constraining them from copying my passkeys. Which seems like the worst of both worlds.

>So I don't really understand how this can be said to be a hardware security token.

No one claimed it's a hardware security token, but the private keys are stored in iCloud Keychain, which is end-to-end encrypted. Apple cannot access your private keys even if iCloud is compromised by an external attacker or employee.

If you're curious about the security engineering, you should watch the "Synchronizing secrets" part of this Black Hat talk from 2016: https://youtu.be/BLGFriOKz6U?t=1353 or you should read the "Synchronization security" section of the "About the security of passkeys" support doc: https://support.apple.com/en-us/HT213305

But Appel could deactivate E2E encryption without your knowledge to get all your keys. For instance on request of government agencies.

This is indistinguishable from the "I don't trust my computer" threat model. Apple could also surreptitiously scrape your screen or copy your processes' memory.

It’s not, because law enforcement considers your computer as private property, while anything you upload on the cloud is seizable without warrant. I’m not joking, it was rapported on HN at the time of the Snowden leaks that NSA can legally monitor your data as long as you transmit it over the wire.

The difference is the effort it takes. Deactivating E2E is just a flag.

There is no need to mess with the E2E, the client installed on your machine is downloaded form their servers, they can just copy the data when it is decrypted locally.

I does not make sense to use a proprietary internet connected application on your machine and worry that that the servers might be nefarious.

If your threat model includes getting hacked by the government, then your only choice of OS would be some hardened open source OS with fully reproducible builds and no proprietary driver blobs installed.

And in which you have personally audited every line of code for extra confidence. /s

You can use 3rd party password managers to sync your passkeys however you please.

Apple has no access to keychain data: https://support.apple.com/en-us/HT213305

Could you give an example? That support article doesn't mention anything about it. I do recall reading something about that recently, but I read the article and it it made no mention of what syncing passkeys actually means. It sounds like theoretically I could write an app that uses the same APIs Apple uses to sync encrypted credentials between TPMs. But "however you please" sounds suspiciously like "however you please, as long as you don't sync it to anywhere Apple can't vouch for the safety of the keys."

Which again, seems like the worst of both worlds.

It has been a while since I have dug into it, but from what I remember it works roughly like this:

You login to iCloud which gives your device write access to iCloud storage. The device creates a private key inside the TPM, and uploads the public key. When you add a new device, one of your existing devices has to use its hardware key to sign your new devices key. It also must be signed by a second key derived from your iCloud password (so you). Apple doesn't go into the details on this, but I believe the originating TPM also signs the key with a chain of trust that goes back to Apple itself.

The keychain is encrypted locally and exported to iCloud. The key used to encrypt the keychain is also encrypted using the public keys of all trusted device keys in iCloud that have both a signature from another trusted device and from you.

As a user you can also just open up Keychain Access on a Mac and ask it to generate a CSV export of your entire iCloud keychain - which is how you would go about migrating to another password manager.

I'm sure that works for passwords. I am skeptical that it works with passkeys. It's unclear to me if the CSV will include passkeys. It's additionally unclear to me if I enroll in some website with a passkey stored in my Keychain, and then export and import that password into some other password manager, if the website will accept a login from the exported passkey. Definitely, there's the "attestation" piece and services might choose not to accept the passkey if the attestation has changed. You can blame the service - but it seems like an intentional design goal here. And it has been said that Apple didn't want attestation, maybe it will be removed, but it's there and it seems likely to be used.

Except that passkeys are treated as both a password and token at the same time. They are the sole thing needed to access a website, so you are absolutely storing your credentials with a large tech company.

When you use passkeys with either Apple's iCloud Keychain or Google Password Manager, the key material is end-to-end encrypted. Law enforcement cannot get your passkeys through these two big tech companies.

This is a great point. And to respond to the other part of the parent comment about storing "all their credentials with one of the large tech companies" — you don’t even need to do that, if you don’t want to.

Apple just extended their Credential Provider API such that passkeys can now be synced using external providers, meaning password manager apps can save and offer passkeys on iOS, iPadOS, and macOS. So you can choose to sync your passkeys with whatever your favorite password manager is.

See this page: https://developer.apple.com/passkeys/

And Google announced a similar API a month or two ago.

See the section titled "Passkey support for Android apps" on this page: https://developers.google.com/identity/passkeys/supported-en...

You guys conveniently ignores the fact that Apple and Google are still the gatekeepers in that scenario.

Yes you need to trust your operating system developer to some extent. If your threat model includes not trusting the company that writes the source code to your OS…don’t use computers I guess?

Suppose one does trust their OS developers. And they want to use some passkey-protected service.

Does that service also have to trust the OS developers? Correct me if I'm wrong, but I'm under the impression that services can decide whose passkey implementations to trust.

Seems like that should be up to the user, not the service.

The user picks the passkey, don't they? Android, Apple or Microsoft. Or Yubikey, or another token.

The concern is not about trust but gatekeeping the providers.

For example in the case of email, you generaly dont worry about google reading your email but we should definitely be concerned if gmail allows send & recieve from only few domains or providers it chooses.

But no more than they are the gatekeepers of your password when you use their keyboard software, right?

How so

So your keychain is symmetrically encrypted with a password and they don’t store that?

Among other things, yes[1].

[1]: https://support.apple.com/guide/security/escrow-security-for...

e2e encryption is one forced update away from being plain text.

I trust big tech companies more than I trust startups or smaller tech companies. I have faith that neither Apple nor Google would do that.

This is a personal belief based on chatting with Apple and Google employees. You don't have to agree.

Regardless of how much you trust them, the fact that they can force a decryption of these keys (and selectively, per-user, no less) means that you are not in custody of your own authentication identity. Add to that, they can be legally compelled to take such a measure (and I'm sure they will in due time).

Compared to using, say, KeepassXC with a unique, secure password per vault. Now you can sync on iCloud or google drive, but neither Google nor Apple can decrypt the vault; the keepassXC maintainers presumably could make a malicious update (which you'd still have to accept, since the updates aren't forced on you), but that would also affect the security of everyone using KeepassXC (and potentially be much more harmful to the economy and society as a whole than the government is willing to accept in order to get intel on an individual person of interest)

KeepassXC has a ways to go still before I can trust it. I just attempted to use it again, after a few years, and syncing the DB across google drive randomly caused all of my entries to be erased. No recovery, nothing. just opened the DB one day and all of my saved notes and passwords went poof.

It's a know bug, but the fact that it still exists really shows how much the devs care about making it a really rock solid alternative. I've never had this issue with Google passwords, 1password or any other provider.

Oh for sure, KeepassXC has some UI issues. And in this case, a glaring bug, thank you for making me aware of it! It looks like there are workarounds, though I'm not sure how much I like them.

I've already been doing manual backups. In addition, there is a feature to make a copy of the database before writing that I've just turned on. And the "Use alternative saving method -> Directly write to database file (dangerous)" option is supposed to prevent this issue from happening with cloud storage.

I wasn't in any way arguing KeepassXC is a layperson-friendly way to manage authentication credentials, just that it gives you the most security from the big identity providers (Apple, Google) selling you out for political or selfish reasons.

Of course, there's probably only so much I can do here. Apple could presumable ship an update to their OS that allows them to access a user's database while it's unlocked, or to keylog the master password.

A yubikey might be the only thing that can really protect you here.

When Apple or Google receives a request to give user data, and they get thousands of such requests, they compare the cost of complying and the cost of not complying. I'll tell you an open secret that such companies are doormat-level compliant and are very very proud of that.

please stop spreading unfounded and vicious rumours - or show us some proof.

Am I talking to the hive mind of HN? If not, let others think for themselves.

Remember Snoden. IIRC only two or three guys in all of Skype knew about/worked on the backdoor. Everyone else would have sworn it is end to end encrypted all the time.

> This is a personal belief based on chatting with Apple and Google employees.

Have you chatted with the Apple and Google CEOs? How about with the future Apple and Google CEOs?

Until law enforcement asks them to make an exception for you in a sealed court decision.

For apple, yes. but as i understand it, your passkeys are not synced or stored in google password manager, they are only stored on device and never synced through or stored on google servers.

When Apple or Google control the endpoints (the password manager apps on your devices), they can get the keys at the ends if they really want to.

>Law enforcement cannot get your passkeys through these two big tech companies.

Of course they can, just not from the stored cloud data. But that's just software. One little patch and your cloud sync is without E2E.

What is it encrypted by? Or asked differently, what does the user need to have to decrypt it on all their devices? And how can we know that Apple & Co. don't also have access to that? It's not like Law enforcement hacks into your connection, they just force the company to hand out your data.

I think it depends on your threat model. For my personal accounts, I'm more concerned about the risk from badly-managed auth than law enforcement. So from that standpoint, using an established big tech company makes sense. Other people may place different weights on various threats.

I lean this way...I know policeman bad and government bad, but 99% of us will pass away and only our family and friends will remember we existed.

Then we are at passwords again where I can happily exclude both. Convenience might be an advantage, but I don't see me using such an auth solution for my private accounts.

Put your passkey on a yubikey if you like.

As a law abiding citizen, my willingness to put in extra effort to avoid law enforcement is pretty low.