Conversation

Notices

1. Embed this notice
   lj·rk (ljrk@todon.eu)'s status on Thursday, 09-May-2024 05:32:00 JST lj·rk

   • Kevin Beaumont

   @GossiTheDog Huh, which vendor does that (I have a suspicion but mine doesn't)?

   • Embed this notice
     lj·rk (ljrk@todon.eu)'s status on Thursday, 09-May-2024 05:36:09 JST lj·rk

     • Kevin Beaumont

     @GossiTheDog
     Ah, uh, I meant to write SMS recovery

   • Embed this notice
     lj·rk (ljrk@todon.eu)'s status on Thursday, 09-May-2024 05:41:02 JST lj·rk

     • Kevin Beaumont

     @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.

     MS is hopeless though.

   • Embed this notice
     Wes (ferralcat@mastodon.social)'s status on Thursday, 09-May-2024 16:02:38 JST Wes

     • Kevin Beaumont

     @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!"

   • Embed this notice
     lj·rk (ljrk@todon.eu)'s status on Thursday, 09-May-2024 17:09:38 JST lj·rk

     in reply to

     • Kevin Beaumont
     • faebudo

     @faebudo @GossiTheDog

     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.

   • Embed this notice
     lj·rk (ljrk@todon.eu)'s status on Thursday, 09-May-2024 17:09:39 JST lj·rk

     in reply to

     • Kevin Beaumont
     • faebudo

     @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:

     (ekc, esk) <- Download(LoginAuthToken)
     k_sk <- KDF(pass)
     esk <- Dec(k_sk, esk)
     kc <- Dec(sk, ekc)

     You have:

     1. a password (never leaves the device)
     2. a derived secret encryption key (never leaves device)
     3. a randomly generated encryption keypair (pk,sk) (may be symmetric actually, fuzzy on the details right now), never leaves the device (in unencrypted fashion)
     4. the keychain itself (never leaves the device in unencrypted fashion)
     5. the keychain encryption with the generated key (yes, synched)
     6. 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.

     1/2

   • Embed this notice
     faebudo (faebudo@ioc.exchange)'s status on Thursday, 09-May-2024 17:09:40 JST faebudo

     in reply to

     • Kevin Beaumont

     @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.

   • Embed this notice
     faebudo (faebudo@ioc.exchange)'s status on Thursday, 09-May-2024 17:09:42 JST faebudo

     in reply to

     • Kevin Beaumont

     @ljrk @GossiTheDog This answer triggers me, did you forget a /s?

     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?

   • Embed this notice
     lj·rk (ljrk@todon.eu)'s status on Thursday, 09-May-2024 17:09:42 JST lj·rk

     in reply to

     • Kevin Beaumont
     • faebudo

     @faebudo @GossiTheDog Typically you do something more or less resembling the following.

     k_sk <- KDF(pass)
     pk,sk <- GenKeyPair()
     esk <- Enc(k_sk, sk)

     The esk is uploaded, not the k_sk or sk.

   • Embed this notice
     lj·rk (ljrk@todon.eu)'s status on Thursday, 09-May-2024 17:09:44 JST lj·rk

     in reply to

     • Kevin Beaumont
     • faebudo

     @faebudo @GossiTheDog The encrypted private key, AFAIK. So basically random data (good encryption = indistinguishable from random data).

   • Embed this notice
     faebudo (faebudo@ioc.exchange)'s status on Thursday, 09-May-2024 17:09:45 JST faebudo

     • Kevin Beaumont

     @GossiTheDog

     Fiction: FIDO2/WebAuthn is secure because the private key is stored in a Secure Element and can never be exported or used against the users will.

     Fact: Let's upload the private key to Google!

   • Embed this notice
     lj·rk (ljrk@todon.eu)'s status on Thursday, 09-May-2024 17:38:26 JST lj·rk

     • Kevin Beaumont
     • faebudo

     @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.

   • Embed this notice
     lj·rk (ljrk@todon.eu)'s status on Thursday, 09-May-2024 17:47:34 JST lj·rk

     • Kevin Beaumont
     • faebudo

     @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.