@GossiTheDog well, by the nature of the process, the public is unlikely ever to hear whether (3) happens.
there has only been one Snowden in living memory, plans that rely on there being another every year are bad plans.
since we can't know the extent to which the risk becomes reality, new technologies need to be designed in ways that minimize these risks from the outset.
@GossiTheDog
If I recall correctly: Apple at least is using iCloud keychain, so you can recover to a new device IIF you have an old device or the iCloud password itself executed within apple's hardware security module, which does limit this threat a bit.
@GossiTheDog I'm still curious how it's going to work with people (like me) whom legitimately use the same device for multiple roles and accounts across domains. Even more fun for software testing. It may be the end of personas, reasonably anonymous accounts, etc.. They will possibly figure out that we are actually dogs.
@GossiTheDog my guess: it works like the keychain in general is synced. like you used to sync passwords back and forth between devices before passkeys (where the synced part is basically a private key, as syncable as a very long password)
I think he is saying that if the passkeys leave the device and are stored centrally, then the government could gain access to them and thus all your stuff
I am no expert on #Webauthn but maybe some "pure-device-based-no-backup" attestation type could be added. But then, in turn, the relying party would need to require that and only that. Unlikely to happen.
Does this mean that relying parties might need to maintain "trusted" lists of attestation CAs in the future?
Here it would be unlikely that Google, Apple and Microsoft certificates will not be included on those lists by default.
Under FIDO, to which Google declares compliance for passkeys^1, the private key should never leave the client device so they shouldn’t be stored on the server… but that applies to the service provider (e.g. Shopify website). Identity provider, in this case Google or Apple, of course do store private keys on their servers for backup purposes, only they declare them to be encrypted by the sync passphrase.
I guess there are two workflows here: one under normal usage scenarios, one under TAO^2 or other “law enforcement love letter” scenarios.
Granted that identity like Google provider controls all data flows for any software keys, from storage (Android), sync passphrase entry (Android) to operating system and application updates (especially after hosted developer keys were introduced to Android^3), it would be naive to have any illusions that under TAO scenario they won’t retrieve that one way or another.
This shouldn’t be the case with hardware authenticators, of course, which are also allowed by Passkeys. Or at least building a side channel for private key retrieval will be much more difficult even in TAO scenario.
The basic Fido scenario is lovely and secure - private key never leaves the device, all is good. It seemed that Passkeys was the implementation that allows authentication to not be tied to a single device, but IIRC it works not by communications with another physical device (like yubikeys) but be allowing the private key to me moved around?
@saper@GossiTheDog@kravietz@PlaneSailingGames What it sounds like is that how a user configures the security around passkeys is important. Using the Apple example mentioned previously, iCloud Keychain security1 is what protects passkeys, if I'm reading this stuff correctly. So a user who cares more about security than convenience is going to take extra steps to secure iCloud Keychain like using two-factor with Yubikeys. And by NOT doing that, the security of Keychain isn't that great. [1] https://support.apple.com/guide/security/icloud-keychain-security-overview-sec1c89c6f3b/1/web/1
(i)Cloud accounts have been targeted for hijack for quite a long time.
what is the point of cloud-based passkeys?
so I am going to protect myself against hijacking, say, my Github account, but my Apple account stays less protected?
But if I go ahead and buy a real hardware fido key, I can use it for all services, including Github and (probably) Apple, so why bother with the cloud-based solution?
Developers and users both hate passwords: they give a poor user experience, they add conversion friction, and they create security liability for both users and developers.
ok, now I got to understand that the Keychain is an encrypted data structure stored somewhere (it could be Apple's key-value store). Reading this story I gather that a whole thing is encrypted with a symmetric wrapping key. This wrapping key can be either obtained by the syncing identity or derived from the recovery code.
So devices exchange the key exchange key among themselves during pairing? Could recovery code be seen as a #SPOF?
@ben@bontchev@GossiTheDog IIRC Google does have the option of having a sync passphrase which at least purports to do e2e… I'm not sure there's another place to set it than in Chrome, though.
@GossiTheDog@bontchev Recovery via help desk can be disabled. If you then lose all your iPhones, Macs, iPads etc. at the same time, you will lose everything. It is always syncing end-to-end between your devices.
At least that's what Apple says. Of course you never know what non-free software actually does.
@erlenmayr@GossiTheDog@bontchev “Can be disabled” is an excuse, not a design choice. 99% of the people will never do it, and whoever designed this system knows that perfectly well. Ergo, US effectively has access to 99% of the passkeys.
@WPalant@erlenmayr@GossiTheDog That's not true. At least in iOS, the passkeys are kept in the keychain and that is end-to-end encrypted. They are protected the same way as the passwords stored there. Even Apple can't see them.
@GossiTheDog@bontchev Isn't this where a security conscious user could add hardware security keys as MFA so that signing in on a new device would require physical access to one of the security keys? Or is there a way to bypass even the hardware security keys in one of the available recovery scenarios? This is a legit question, no sarcasm. I'm trying to learn about pros and cons of various methods for different user threat profiles.
On android you have to enter the lockscreen of your previous phone to get your passkeys on your new phone though. The passkeys are e2e encrypted with a secret derived from that lockscreen.
This makes them more resilient by default to snooping by three letter agencies than passwords, which you can choose to e2e encrypt, but it's not the default (again on chrome).
Add comment