Since there hadn’t been any pull requests yet, I thought I’d give it a try. You can find my proof of concept implementation here:
While it is definitely not production ready, it seems to be fully functional and compliant (at least it passes all tests defined in the getcredential-prf.https.html test suite)
Few notes about the implementation:
Currently the prf seeds are derived from the secret key of the passkey. I choose this option, to have the extension working without modifying the vault or server-side storage of passkeys. I’d argue that this approach is secure enough, as the secret key of the passkey is essentially a 32 byte random number. I use this as a high entropy input for HKDF to derive two 256 bit keys to be used as prf seeds. Due to the pre-image resistance of the utilized hash functions, neither the seeds nor any prf outputs can be used to retrieve any information about the passkey’s secret key. Nevertheless, I also looked at how 1Password implemented this feature and they store the hmac-secret keys alongside the passkey’s secret key. I assume they are randomly generated, upon registration. If support for these fields are added in the remaining bitwarden ecosystem, this might be a better approach.
Due to not storing additional data with the passkeys, I was unable to persist whether a specific passkey should support the prf extension or not. Hence, every passkey will support the extension if asked by the client, independent of whether this was requested during registration. This is probably not spec conforming, but did not cause any of the above test cases to fail, so I did not worry about it too much. After all its just a proof of concept
I did not fully implement the hmac-secret extension, but implemented the prf computation as described by the specification for authenticators that support the hmac-secret extension. This probably does not break anything, since this extension is not advertised, but a full PR could probably look into this and finish the implementation.
I also did not put to much effort into the code structure and placed things, where they felt convenient. For me the implementation is mostly used to continue working on a different project, where I want to use the prf extension to derive cryptographic keys (similar to the use-cases mentioned above), and I needed a simple way to test my project there (and I do like to use bitwarden for that).
I still have to take a closer look at the contribution guidelines, but I wanted to first post my progress here, before submitting a pull request. I’m also happy if anyone wants to take this as a starting point and continue this work, as this is more a sidequest for me, and I’m already quite happy with the result I have locally
Just adding to the requests. I would like to use Confer, but discovered that Bitwarden doesn’t support PRF. Do I really need to switch to another password manager?
On iPadOS 26.4.1 in combination with Bitwarden 2026.4.0 Bitwarden is invoked an a passskey seems to be generated (at least there is an entry in that field afterwards), but the site refuses to accept it and does not store it.
Using the email option for the first time, you need to generate the passkey;
an email will be sent to you containing your signin link.
If the generated passkey cannot be stored in Bitwarden, follow Moxie’s new guide:
(2026-04-21, email from Moxie Marlinspike, moxie@confer.to)
Confer now has a recovery code option as a fallback for Bitwarden users on Linux.
When passkey creation doesn’t work with Bitwarden (it doesn’t fully support the PRF extension that encryption requires), you’ll see a “Use a recovery code instead” button.
It gives you a 64-character code that you can save in Bitwarden like a normal password, and it works regardless.
My test prompts returned excellent results:
what are the prerequisites to use an air mouse on some google tv
This is so unfortunate that we have to rely on hacks to work around the limitation of PRF supported passkeys in BitWarden. Especially since other password managers already support this feature.
Hi, paying customer here. This is causing me a lot of headaches, and I’m really surprised and disappointed it hasn’t been implemented already. There’s not even a clear reason for why it’s not a priority. Everyone just keeps pointing at how much better 1Password’s Passkey implementation is.
