One more question: How come passkeys that are stored in a Bitwarden browser extension do not seem to be PRF-capable, even when used on a PRF-capable browser? For example, when registering a passkey for one Bitwarden account, the passkey can be stored as a login item in the Bitwarden vault of a second account; however, when doing this, the first account shows the registered passkey with the status “Encryption not supported”.
Perhaps storing a Bitwarden passkey in a Bitwarden vault is not generally a good idea, but I don’t see why vault storage of passkeys should exclude the possibility of storing passkeys that require PRF. There will be use-cases that need such functionality.
@Micah_Edelblut, is there some way of telling which browsers are PRF-capable? I’ve tried Google Chrome and MS Edge under Windows 11, storing passkeys in Bitwarden. In both cases I don’t get the “Use for vault encryption” checkbox and of course the resulting passkey can’t be used to decrypt the vault. So firstly, can you confirm that this is because Chrome and Edge are both not yet PRF-capable, and secondly, is it possible for Bitwarden to indicate which browsers have been tested and found to work? Many thanks.
@bitmap FYI, this thread alone has confirmed that Chrome, Edge, and Brave are PRF-capable, and it has been reported that all Chromium based browsers are PRF-capable (which would include Opera, Vivaldi, and others, in addition to the ones just mentioned).
I agree that it would be helpful for debugging purposes to have an official or semi-official list of browsers that are supported and/or tested and confirmed to work. However, as seen by reading the various comments posted in this thread, the browser used is not the only factor that determines whether passkey login will work or not.
Yes, I agree, but it seems to be the case that it only works with hardware security keys like YubiKey. My attempts were to use software passkeys saved in Bitwarden and/or Windows Hello.
When I was trying this out, I noticed my browser extension had not yet updated to v2024.1.0. Bitwarden was offering to save a passkey - maybe it’s something I did but for some reason, v2024.1.0 doesn’t offer any more. Instead, I chose to sign in with Windows Hello. This was accepted but I still didn’t get the “Use for vault encryption” option and so I was forced to enter my Master Password anyway. This kind of defeats the purpose!
I’m sorry to say that I’m more than a little confused!
Same here , just added a “Windows Hello” passkey for vault login …
Extension 2024.1.0 indeed does not offer to save the passkey in BW (well that’s not what I want do anyway in this case) and I chose Windows Hello to save the passkey.
As mentioned it is saved in BW as a passkey for vault login with “Encryption not supported”.
So I’d assume that although the browser (Brave in my case) does support Webauthn-PRF the Windows Hello “provider” does not support encryption (yet) … therefore the need to decrypt the vault with Master password during login process with the Windows Hello passkey (what defeats the purpose of course).
This would be a question to ask Microsoft if and when this might change ?
As for the 2024.1 extension not offering to save the passkey in BW … would have to try out if this is a generic issue when saving ANY passkey in BW (which would be a bug) or just when trying to save a passkey for BW vault login - the latter would make sense somehow since I would not want to store the BW login passkey in BW itself ?
@tschap123 & @bitmap — Version 2024.1.0 includes a PR (#6861) that explicitly blocks storing a passkey for your own Bitwarden vault inside your vault.
Interestingly, if you store a Bitwarden login passkey for somebody else’s Bitwarden account in your own vault, such a passkey cannot be used for encryption!
I noticed something strange when using Chromium on Fedora Linux to configure Log in with passkey.
When I turn it on, a window pops up asking me to enter my master password, but below that I’m only given the option to send a validation code via email and a window to enter that validation code.
Anyone else seeing this?
Seems a bit less secure doing the verification via email and not my master password.
I’m not suggesting that every platform capable of storing syncable passkeys should also support passkeys that have encryption, but I would expect Bitwarden in particular to offer this functionality. If security of the implementation is not sufficient for whatever reason, then the security needs to be beefed up, that’s all.
Basically, a Bitwarden vault should be able to function as a giant “virtual YubiKey”, with unlimited passkey storage.
How are you logged in to the Web Vault? If you logged in with a passkey or logged in with a device, then Bitwarden is not able to use the master password for verification, and in such cases it will fall back to an email code.
@soluschristus The gory details are available here (clicking the link below will take you directly to the section about passkeys):
To clarify, your vault contents were never encrypted using your master password — Bitwarden uses a randomly generated 256-bit symmetric encryption key for encryption and decryption of your vault.
To make sure that only authorized users can access this account encryption key, the key is itself encrypted. This produces a “protected” key, which is useless by itself, but which can be decrypted to generate the account encryption key.
With master password login, the master password is used to decrypt the protected key. With passkey login, the PRF public key (what you’re calling a “secret key”) is used to decrypt the protected key.
In a brute-force attack, an attacker would need to correctly guess either your master password or your PRF public key. Since the PRF is a 32-byte random number, its entropy is 256 bits. To get an equivalent master password entropy, it would need to be a randomly generated passphrase containing twenty words.
However, one weakness of passkeys is that if someone gets their hand on the hardware that is storing your Bitwarden passkey (e.g., if your YubiKey is lost or stolen), then it may be possible to brute-force guess the FIDO2 access PIN for the hardware, which will be considerably easier than brute-force guessing a 256-bit random key. I have recently discussed this potential pitfall, in the following forum post:
I’m confident my issue is with Windows 10 alone.
I have an old Surface Pro laptop that had Windows 10 installed and the latest Chrome browser and it wouldn’t support passkey (PRF) encryption.
I upgraded it to Windows 11 and now it does.
I also tried MacOS, ChromeOS, even Raspberry Pi OS (11 & 12) and all these support PRF encryption. I have only found Windows 10 that doesn’t.
So I finally got around to trying Pinion’s suggestion using Virtualbox and I can verify that it worked with Yubikeys with firmware 5.1.2 and 5.4.3, just as described. Of course, everything worked great in VirtualBox, but in Windows 10 with the Brave browser, it still won’t decrypt my vault without entering my master password, which I guess I should have expected.
I have found that passkey encryption will not work on Windows 10 using any browser.
I tried 4 PCs. I upgraded one to Windows 11 and encryption started working after the upgrade so I’m confident the problem is Windows 10.
Even a VM that is hosted on Windows 10 won’t work, also an RDP session into Windows 11 from a Windows 10 client wont work.
