While there is ongoing debate about password peppering, I personally find it a very low-effort strategy for sensitive accounts that addresses specific threat models. It is particularly effective due to rate-limiting by services that prevents brute-forcing.
Consequently, I am reluctant to store passkeys for sensitive accounts in password managers, as this feels like reducing security compared to peppered passwords.
Proposed Solution
Implement an optional secondary encryption layer for passkeys using a user-defined “pepper” password.
This would achieve the same security benefits as password peppering, since brute-forcing would still require interaction with rate-limited services.
Implementation Details
Add a “Secondary Encryption” checkbox next to passkeys (similar to the existing “Re-prompt” checkbox)
Use encryption that doesn’t reveal decryption success/failure, producing binary blob regardless of password correctness and letting the target service validate the generated passkey
Benefits
Restores defense-in-depth for passkey users
Leverages service rate-limiting for enhanced security
Minimal UI complexity using existing patterns
Feature remains completely transparent for users who don’t enable it
Backward compatible with current passkey functionality
Could also address User Verification requirements if made mandatory, with added offline protection
Current Workaround
While password peppering can be done manually, passkey re-encryption requires password manager support, making this feature essential for advanced security strategies.
Related Issues
Combined Password requests integrated peppering, deemed low-value due to manual workarounds - but passkeys cannot be manually peppered
Passkey User Verification PIN requests dedicated PIN for User Verification, which this proposal could be extended to address (unified pepper/PIN) with added offline protection
Maximum Retries requests implementing maximum retries for user verification, which would be directly addressed by target service rate-limiting with the extension of this proposal
The key proposal of my FR is to add another layer of encryption to the passkeys, in addition to the whole vault encryption, in order to mitigate attacks where the attacker would succeed in gaining access to both the vault and its master passphrase / offline unencrypted vault (not just accessing the unlocked vault, that re-prompt addresses). It is really equivalent to peppering the passwords stored in Bitwarden.
I will vote (when I can) for the feature request proposing to use the PIN for re-prompt, because it is what is currently refraining me from using re-prompt. But although my FR could replace re-prompt, re-prompt cannot replace my FR.
It seems that your post is duplicative of various existing feature requests, so it will likely get moved (merged into an existing request) or closed. If you indicate your preferred disposition of this thread, that will be take into account.
Additional encryption for items protected by Master Password Reprompt is indeed similar in spirit, though it does not make it explicit that peppering is a workaround for passwords, while there is no workaround for passkeys. Also applying this idea to passwords instead of passkeys is a bit more challenging, because in order to be able to use a simple additional “pepper password” by taking profit of target service rate-limiting, decryption of a password with the wrong “pepper password” should look like a plausible password, which is a bit complex to ensure, compared to a plain binary passkeys, which is why I preferred not to mention it initially.
So if my FR cannot be kept open, I would prefer moving it to the other FR in order to express these points (but otherwise I can also add a dedicated comment in the other FR).