[jwally]

I'm missing something.

Webauthn puts a private key into a firewalled section of hardware onto your device - which is extremely prickly to work with in my experience - for your security.

For passkeys to be transferable the private key cannot be locked to your device.

Is bitwarden somehow able to "spoof" this hardware and have your browser generate private keys in it instead?

[drdaeman]

> Webauthn puts a private key into a firewalled section of hardware

This is not true. In general, Webauthn doesn’t care where and how the keys are stored. There is attestation feature, but AFAIK e.g. Apple intentionally doesn’t implement it for unmanaged devices.

[jwally]

I've experienced this on my phone IIRC...if I register a webauthn key on chrome on iphone, it shows up on safari; but the reverse is not true.

Im assuming this is because apple uses a software based TPM that isn't tied to the device. This lets those private keys sync between devices.

Is the future state for bitwarden to be able to perform the same trick somehow? Have you create keys in it and not your devices tpm?

[lxgr]

The situation with Chrome and Apple devices is currently quite confusing.

Apple has only recently introduced the necessary APIs to allow for third-party passkey providers (i.e. other apps acting as a passkey storage) and users (i.e. other apps using passkeys stored in iCloud and in other third-party provider apps).

But it's not easy as passkeys being supported on the latest versions; at least Google used to support a non-synchronizing platform authenticator implementation of WebAuthN using the system keychain and Touch ID (or the login password as a fallback) as well. So there is also a chance you were using that, at least on macOS.

> Is the future state for bitwarden to be able to perform the same trick somehow?

For web browsers, I believe the current approach of 1Password and presumably also Bitwarden is to inject a custom implementation of WebAuthN into every page's context. This doesn't require any WebAuthN/passkey support on the browser's side.

On macOS, they could also act as a system-level passkey provider though; this should then allow all passkey consumers (such as Safari and other browsers) to use these passkeys natively, i.e. without a JavaScript shim. And on iOS, given how web extensions are notoriously tricky there and all browsers are kind of Safari under the hood anyway, that might even be the only option.

[CharlesW]

> The situation with Chrome and Apple devices is currently quite confusing.

As someone who's used 1Password, Apple's password/passkey manager, and Chrome's password/passkey manager while checking out the passkey user experience of these respective solutions, I didn't find it more confusing than the ability to choose your preferred password manager. That is, I didn't find it confusing.

[lxgr]

Is that on iOS or macOS?

Maybe the onboarding experience is better now, but when I last looked into this, 1Password and Chrome were fighting over who gets to store newly generated passkeys in my browser. At the same time, Chrome's ability to use Apple/iCloud passkeys is brand new; before macOS Sonoma, this wasn't possible at all.

[lxgr]

Not sure about managed vs. unmanaged devices, but Apple used to support attestation before they started synchronizing passkeys via iCloud.