PRF extension support for Bitwarden extension #13838
Replies: 2 comments
-
|
@Mysak0CZ It's awesome your idea! I'm a new contributor to Bitwarden and still finishing reading the documentation and guidelines. However, I would like to know if this implementation would be done in the server project. Even though it is an extension for browers, would it somehow use the server project or not? |
Beta Was this translation helpful? Give feedback.
-
|
As I looked into possibilities of implementing this, I stumbled upon the fact that the library https://github.com/1Password/passkey-rs (which is used in Bitwarden's Android client) already added support for PRF. This severely limits freedom in implementing this extension, as implementation needs to exactly match the passkey-rs library. CC @coroiu as from what I can see, you are the one maintaining the Bitwarden's passkey-rs fork. Any recommendations on how this could be approached? Thank you in advance for any response. |
Beta Was this translation helpful? Give feedback.
-
Code Contribution Proposal
PRF extension is currently described in the WebAuthn W3C editor draft and many browsers already support it natively.
The Bitwarden browser extension handles passkeys by replacing native functions, but at the moment it lacks support for the PRF extension.
As Bitwarden's website supports logging in through Passkeys using this extension, this actually means that Bitwarden cannot be used to sign into its own website.
I would like to attempt implementing the PRF extension based on the above-mentioned specification into the Bitwarden browser extension.
The underlying
hmac-secretFIDO extension behavior is specified in CTAP specification.Most of the specified behavior can be done using simple operations and SubtleCrypto's HMAC sign API using
SHA-256.The only problem I foresee with the implementation is, that CTAP specification defines, that the secret value for the HMAC should be
CredRandom:This is currently not part of existing passkey's data.
I believe the cleanest approach to this is generating this value only when the
prfextension was requested at credential create time and storing it next to the currently stored secret value.As far as I am aware, this extension shouldn't affect rest of the response in any way.
Beta Was this translation helpful? Give feedback.
All reactions