jmsgwd

If the database is not local, and there’s no authentication, what stops someone else from accessing it inappropriately?

But the fact that it's so boring is interesting.

How else could you represent piano roll data than as a stream of events? I thought that was ubiquitous since the invention of MIDI.

Are you saying other sequencers are unable to render the same data as piano roll and score?

Are you referring to Windows Kerberos here or NTLM?

That came across more snarky than I intended!

Let me rephrase: for the majority of users, the usability and resilience benefits of synced credentials are enormous, and the security costs are marginal at best. But this rests on a number of assumptions. YMMV.

>Huh interesting, how does that work? I thought the way yubikeys operate the keys are generated on-device and are impossible to remove, and also come in limited number.

I wasn't referring to hardware keys (like YubiKeys), but rather on-device secure enclaves, TEEs, or TPMs.

Also I said "protecting a key using the secure enclave", which is perhaps a bit of a sleight of hand :-)

By that I mean a key that is wrapped (encrypted) using a parent key stored in the secure enclave. The key itself is not stored in the SE. But since it is wrapped using a parent key that is stored in the SE, that means it can only be decrypted in the SE. I believe this is how iCloud Keychain works, for example.

Digging into this further, it looks like I might have been wrong to imply that a credential manager app can instruct the SE itself to perform the proof of possession calculations needed for passkey authentication using a private key that is "protected" in this sense. When the app asks the SE to decrypt a passkey private key, it looks like the SE might return the passkey private key in plaintext to the app, and then the app itself performs the proof of possession calculation transiently outside the SE. I'm not sure about that, but I'd love to know.

> How do the decryption keys for the encrypted passkeys get shared between devices?

They get established as part of the device enrolment process. I suspect this simply adds another layer to the key hierarchy, so that your passkey private keys are encrypted under a sync key (parent) which is encrypted under a SE key (grandparent).

In that case, you could still claim that your passkeys are "protected by the SE" since they are encrypted at rest and in transit, and they cannot be decrypted anywhere except in the SEs of your enrolled devices.

Just to point out, protecting a key using the secure enclave and syncing it using end-to-end encryption aren’t necessarily mutually exclusive.

The security property you care about is that the plaintext key is only ever processed in use within the secure enclave (transiently, during authentication).

That doesn’t preclude syncing or backing up the encrypted key via a cloud service - if the device allows the application to do that.

There are many cross-platform password managers that sync very nicely, which would solve for the machines you control - the Windows gaming machine and Android phone.

For machines you don't control, such as your employer Mac, well that's a special case. In theory you can use "FIDO Cross-Device Authentication", which is a passkey flow designed specifically for authenticating on one device using a passkey stored on a different device, and involves scanning a QR code.

I've never tried this though. Personally I tend to avoid mixing personal stuff with work stuff, so the problem rarely arises.

> I dont want an online backup. I want my credentials to only be on my computers. So now I gotta learn about which apps are ok, don't have cloud synching

If an "online" password manager uses end-to-end encryption, then the credentials really are only on your computers. The only thing "in the cloud" is encrypted blobs of data being moved around for the purpose of device sync and backup.

This insistence on using local non-syncing password managers is a masochistic exercise in making life difficult for yourself with no security benefit.

OK but you'd still be able to use the open source "password manager" to export the keys - which solves the issue lapcat raised in this thread - even if relying parties blocked it for authentication, which would be a separate issue.

Someone could develop a "passkey export tool" purely for the purpose of doing credential exchange then local export.

Or are you saying the credential exchange process itself could block providers?

Once "secure credential exchange" becomes supported by commercial credential managers, what's to stop someone implementing an open source password manager that implements the standard and allows local export in plaintext?

OK I see what you mean. Having the ability to switch between vendors but not the ability to export your data locally (e.g. as plaintext keys) is a new meaning of "vendor lock-in" I hadn't considered before.