@GossiTheDog Thankyou for making this wide-open door explicit. I've always had an instinctive aversion to passkeys cos they reside on your phone (among other devices). And phones are incredibly vulnerable in so many ways
@GossiTheDog please don't advocate to make account recovery even more awful. "Forgot your gmail password? Prepare for three weeks of phone calls to customer support!"
@GossiTheDog Has anybody actually tried that? I thought that you couldnt recover from an existing phone if it's still active without original phone explicitely accepting this recovery
@GossiTheDog Really?! Jeez. I personally use BitWarden, but I would at least expect Apple to not allow it for their "Advanced Protection" with E2E for everything in iCloud? And I think Google has a similar toggle? Although I wouldn't bet on it, too many obscure options for both.
The private key stored with google (or any other such service) is encrypted with what? A private key stored on a Secure Element, never exportable or used against the users will?
Or with the users mother maiden name and the ability to read an SMS that was sent to the users mobile phone number?
@ljrk@GossiTheDog Ah yes, this is how FIDO2/WebAuthn normally works.
But what I wrote about is WebAuthn with your Android Phone/iPhone where the sk and k_sk are backupped to your Google/iCloud account as a method to share it between devices using the same account.
The discoverable credentials are called passkeys and there are device-bound passkeys and synced passkeys. What I'm talking about are synced passkeys.
All the big platforms are selling synced passkeys as phishing proof and secure. But the basic promise that the private key cannot be stolen (except physical) has been violated by exporting it somewhere where it can be stolen.
@faebudo@GossiTheDog No, this is nothing about Passkeys, this is how password managers usually generate an encryption key for the wallet. None of the keys above is a Passkey.
Making this more clear, given all Passkeys and other data in the keychain kc, the following happens to upload it to the cloud:
ekc <- Enc(pk, kc)
The bundle of (ekc, esk) is uploaded to the cloud. When enrolling a new device, the user gives their master password and thus:
a derived secret encryption key (never leaves device)
a randomly generated encryption keypair (pk,sk) (may be symmetric actually, fuzzy on the details right now), never leaves the device (in unencrypted fashion)
the keychain itself (never leaves the device in unencrypted fashion)
the keychain encryption with the generated key (yes, synched)
the keychain encryption keypair/key, itself encrypted with the derived secret (yes, synced)
Only encrypted data (= indistinguishable from random data) is uploaded.
And yes, this is phishing resistant and secure. This is how every proper synched password manager has operated for a long time.
If you claim that this scheme "uploads your secret key", then by the same reason password auth uploads the shared secret to every hop b/w you and the authenticator. Which, yes, but it's encrypted using TLS: Your ISP cannot read the password.
Additionally, this is actually nothing that's related to Passkeys. It's just how synched Passkeys are commonly implemented. You don't need to sync discoverable Passkeys, it's nowhere in the spec. KeePassXC allows you to not sync Passkeys.
Either way, they are more secure simply in the same sense that SSH Keys are more secure than SSH Passwords. It's absolutely insane that we now, finally, have proper public-private-key auth in the Web and the same people claim it's insecure while themselves using SSH Keys. It's the freaking same thing, just for Web!
To drill this down: The major point against attacks is not that the secret is safely stored in a physical key. It's that the authentication isn't based on a shared secret. And that's what happens here.
Optionally(!) syncing Passkeys doesn't make this less secure, since they are encrypted before they even leave the device. And this is the same for synched passwords managers.
If you don't sync, you don't have either. It has nothing to do with Passkeys.
@GossiTheDog@faebudo I'd still argue that this is the same for any synced Password managers and has virtually nothing to do with the Passkeys. If Apple implements their own SSH Key Manager, this doesn't make SSH Keys a bad authentication system.
Regardless, I tried looking into this and I cannot find any source that this actually works. AFAIK you can download the encrypted wallet and effectively bypass LoginAuthToken in the above scheme using SMS, but you still need to somehow decrypt the sk, which is encrypted using a key derived from a password. I don't see how this works with SMS reset and didn't manage to make it work either.
@GossiTheDog@faebudo Every user will look at this and ask: And why is this a bad thing? If users are in the fear of getting locked out because their phone broke, no one will use the tech. And tbf, that's nothing I'd do either.
The good thing is that with E2E something can be stored securely in the cloud. Enrolling a new device only works if you know the password your wallet key is derived from + have the login data for your Google/iCloud/whatever account. Or at least a recovery contact has that.
@GossiTheDog@faebudo Oh, definitely! in the end, the user is always the weakest link!
But that was the same for (synced) passwords and nothing new here. And I cannot make my parents use an unsynched password manager – I'm glad they use one at all!
The alternative to synched Passkeys would be synched Passwords (bad in all regards), unsynched Passkeys (they won't use them), unsynched Passwords (even worse: won't use and insecure) or using no Password manager at all (god pls no).
“For additional privacy and security, 15 data categories – including Health and passwords in iCloud Keychain – are end-to-end encrypted. Apple doesn't have the encryption keys for these categories, and we can't help you recover this data if you lose access to your account.”
@GossiTheDog@ljrk@faebudo that’s not my understanding. Under standard protection keychain is end-to-end with keys only on trusted devices, while photos have keys managed by Apple. This is why when you add a new device you have to pair it with an existing device - the pairing process shares the encryption keys from the secure element. As far as I remember (been a while since I read the Apple security whitepaper), if you lose access to all devices and didn’t save a recovery key then you are SOL for getting keychain back.
@GossiTheDog I really don't like the phone method of it. At work we are just giving everyone Yubikeys the only thing holding us back is auth for apps on Android. This is such an issue we have actually talked about having to push iPhones