1Password Future

Sure, but if that key derivation function is protected by a "you get 10 attempts then we wipe the keys" safeguard, the effective entropy is much higher. The question shouldn't really surround the effective entropy of the PIN, but rather the systems in-place to protect bypassing safeguards in the key derivation function which render the actual entropy of the PIN irrelevant. There probably isn't no way around that safeguard, but as more of this gets moved into trusted compute silicon the level of sophistication required to breach it goes up; and is one hardware revision or operating system update away from being made moot again.

This thread really smells like https://xkcd.com/538/. Three things you have to remember, that are far more important than any of the concerns you have:

1) The effective entropy of the current system (passwords) is "shrugs shoulders fuck it not our problem". Services can enforce password entropy requirements. They cannot effectually require users to use a unique password. They also cannot forbid users from writing the password they use in a .txt file on their desktop or post-it note or throwing it in Apple Notes (EVERYONE does this outside of our bubble. Apple Notes and Excel are the #1 and #2 password managers on the planet). A six digit pin + hardware TPM key derivation is, at best, the same thing that was guarding how most people store their passwords anyway, and in many cases far better than the current state (if a user's device has no E2EE, or if…

A lot of comments in this thread are discussing vendor lock-in with Apple or Google.

1Password is working on passkey support already (https://www.future.1password.com/passkeys/) and I imagine others will follow suit. Vendor lock-in isn’t part of the spec, it just happens that in these early days, the OS-level authenticators are the main ones implemented (as are other hardware authenticators).

In the mid to long term (e.g. by the time websites start supporting this), I don’t think vendor lock-in will be a problem. It’s no worse currently than chrome or iCloud Keychain being your password manager, which has been part of the landscape for a very long time. Like password managers, there will be other options. The benefit is that unlike passwords, there is a standard API for “autofill credentials” rather than using an extension to update the DOM.

For those wondering: the local threat here is a malicious extension can modify the function of navigator.credentials.

While not malicious, this has been shown to be possible by 1Password. See https://www.future.1password.com/passkeys/ and I have confirmed it is possible to modify this function.

JavaScript can be monkey patched, in some ways this is great for polyfills. For other cases this can be a threat.

If browsers had an explicit mechanism to register extension provided Authenticators and locked down a way to modify the original navigator credentials interface, then we may be able to protect the "first" bytes that come back from the authenticator to the application.

For _using_ WebAuthn, Linux without a TPM has the option of using a hardware key like a Yubikey or Nitrokey, or a virtual authenticator like what 1Password proposes here: https://www.future.1password.com/passkeys/

For _syncing_ WebAuthn passkeys, then virtual authenticators that sync over the wire like 1Password above is the only option. Using virtual authenticators means that your key material is in-memory alongside the OS and all running apps. That's why it's so critical that OSs expose pluggable sync fabrics; so that vendors like 1Password, or even YubiCo, can implement sync fabrics that roam through whatever hardware the current platform happens to have available.

> However, I do see some hesitance in the idea of passkeys.

Interesting, my impression is that everyone is ready for passwords to die.

> I do see some problems with them, namely that it seems like passkeys are locked to the iPhone/Android device and are hard to sync.

This will apparently be solved with password managers, which will handle sync across devices/platforms. (One source: https://www.future.1password.com/passkeys/)

> What would you need to switch to passkeys?

Password manager support with cross-device/platform sync.

Right, the question is: given that 1Password is adding support for passkeys (https://www.future.1password.com/passkeys/), are they going to support exporting them once they are a passkey provider?

I don't see any indication that they are. If they don't plan to support exporting and importing into other ecosystems, then I would argue that their implementation is not portable. I would say that zacharyvoase's concern is still valid in that scenario:

> There's no way to migrate your passkeys between ecosystems