"Login with passkeys" - what does beta mean?

… I mean, I know what the word “beta” means. :crazy_face:

But what’s exactly “beta” as of now? (aside from that it only works with the web vault at the moment?) What feature is missing / will be coming in the future? :thinking: The new help page (Log in with Passkeys | Bitwarden Help Center) doesn’t specify what’s beta either, or I missed something.

Does anyone have a clue?

Bitwarden opted to label this a “beta” so users would understand that it is not yet finished. This is because we haven’t yet brought the experience to other clients (you can’t login with passkeys anywhere but the web) and because the ecosystem for supporting encryption (read more about PRF here) is still very new, and we need to let the industry catch up if we want to bring this out of beta.

Thanks for the response!
But a bit confusing or “inconsistent” - and so maybe harder to make it understandable. With the same reasoning the whole passkey feature drop end of last year could have been marked as “beta”. :rofl: And “beta” makes me think of “not fully/reliably working”. But as I understand it correctly, the “login with passkeys” now works completely/reliably, but that only under specific circumstances (mainly: browser with PRF and only for web vault), right?

Fair! I think we at Bitwarden learned a lot about our users’ expectations when we launched passkey storage last year :sweat_smile:

One other thing I’ll add is that, unlike storing passkeys where we have a roadmap for bringing that functionality to other clients (we’re working on it now!), we don’t know when PRF support will be introduced to other platforms, so it is hard to plan for expanding the login with passkey feature.

A little confused about how different multiple passkeys can be used for encryption. Originally the vault was supposedly encrypted using the master password with kdf/argon iterations. Now it can be encrypted with passkeys? Do you have an article that explains this further? Trying to connect where we were MP encryption to where we are…Passkey encryption.

@islandtime

The overall security architecture and encryption schemes are described in the Security Whitepaper; the specific details about passkeys is here.

The vault contents were always (and still are) encrypted and decrypted using a symmetric encryption key, which is a 256-bit random number (your account encryption key). The master password is used to encrypt the account encryption key, which creates a “protected” version of the key that can only be decrypted (to recover the account encryption key) if the master password is known. Thus, when you log in with a master password, the servers transmit a copy of the protected key to your Bitwarden client app, and the client app then uses the master password that you supplied to decrypt the protected key (thus retrieving the account encryption key which is used to decipher your vault contents).

When logging in with a passkey, the process is quite a bit more complicated, but the bottom line is that the account encryption key is again encrypted (“protected”), using a different technique. Specifically, somewhere in the process of registering a passkey (with the encryption option enabled), a “PRF public and private key pair” is generated, and the PRF public key is used to encrypt your account encryption key.

So now you have two different protected keys: one that is protected using the master password, and one that is protected using a passkey. These protected keys are useless unless they are decrypted, and to decrypt the protected keys you will need the master password or the passkey, respectively.

3 Likes

Are there any (current) plans expand passkey login to the browser extensions for Chromium browsers? Seems like the technical prerequisites should already be in place to allow that to happen.

2 Likes

That is an excellent description of the encryption process. Thank you for clarifying and providing the reference source information. You guys are just plain awesome in your support & products. Thank you!

1 Like

I was wondering the same thing. I was able to turn on log in with passkey and vault encryption in Brave but that appears to be working only for vault.bitwarden.com. I did not see any option to log in with passkey in the browser extension so I likely just misunderstood the scope of the current implementation.

Are there any (current) plans expand passkey login to the browser extensions for Chromium browsers? Seems like the technical prerequisites should already be in place to allow that to happen.

At the moment, we’re blocked by the fact that browser extensions use a different url than the one used to register the passkey (eg. vault.bitwarden.com) and so we are blocked on bringing this to the browser extension until additional support for this scenario is accepted into the webauthn spec and developed by the browser ecosystem.
WebExtensions should use asset links model for WebAuthn RP ID · Issue #238 · w3c/webextensions · GitHub

Interesting dilemma! An alternative solution would be to register a separate passkey for the extension. Or perhaps some kind of pass-through mechanism (e.g., is it possible to render an iframe within the extension pop-up?).

Bummer! Although it’s also interesting to see specs developing as needed based on use case scenarios.

Hmmm…
Seems like the guys at heylogin found a way to somehow make prf work with their plugin. A little strange that no passkey is created on my yubikey for that. It only works in Chrome and Safari claims it cannot open the heylogin vault since “Webauthn PRF extension not supported”.
Not sure if their approach would be applicable for bitwarden.

That’s a bummer since I’d rather use the Key for browser extensions (what I use 75% of the time) over the web vault (used 2% of the time) or mobile (used 23% of the time). I realize though the extension URLs are different than other URLs.

Is there not a way to have the extension authenticate using a browser window like several desktop applications do (postman, global protect, slack, etc.)? Would that work for Authentication, but not encryption? I realize, this approach would likely take a lot of work, but still worth considering as I’m not sure how soon WebAuthn is going to jump on this.

1 Like