Bitwarden already treats login and vault unlock as two distinct operations technically — login authenticates against Bitwarden’s servers and decrypts the vault locally, while unlock only decrypts the vault locally. However, when managing passkeys, this distinction is hard to recognize: passkeys with encryption can be used for both while passkeys without encryption can only be used for login.
I’d like the ability to assign a scope to each passkey:
Scope
Can log in on a new device
Can unlock an existing session
Login only (current behaviour, default)
Unlock only
Both (current behaviour, default if supported)
Why this improves security:
If a passkey is compromised (lost hardware key, synced passkey in a breached credential store, etc.), the blast radius is limited by scope:
A Login-only passkey alone isn’t enough to decrypt the vault — the attacker still needs a separate unlock credential
An Unlock-only passkey alone can’t be used to log in on a new device and exfiltrate the encrypted vault blob
This creates defense-in-depth: an attacker needs two separate, independently compromised credentials to fully access the vault — even if both happen to be passkeys.
I don’t think that premise – and clear distinction between those two operations – is accurate, as login also (currently and “always”) decrypts the vault locally:
Effectively, it seems you are requesting that two passkeys be required to login (one to download; the other to decrypt – login does both, as @Nail1684 mentions).
Seems like the more effective approach would be to up the security game by using a hardware passkey and setting a PIN on it (they self-destruct after a predetermined number of failures). And, of course having a contingency access method so that a lost hardware key does not turn into an unusable vault.
This reminds me of my front door. Originally, it had two different keys, one for the handle, the other for the deadbolt. Seemed like a good idea, but because we carried both keys on the same ring it really did not up-the-game. Eventually we realized that in addition to being inconvenient, it also decreased security because we tended to use only the handle lock.
I replaced both with a higher quality (less pickable) deadbolt and a handle that does not lock. Much more convenient and much more secure because one can not weakly lock the door.
I support this feature request, and have expended my last vote on it.
I especially would welcome the option to have a passkey unlock (decryption) feature that cannot be used for server authentication (login).
I currently use security keys for 2FA, but not for passkey login, because if a security key that stores a login-passkey falls in the hands of a bad actor, then only the UV PIN would stand in the way of vault compromise (and yes, I already know how to harden a security key PIN).
However, I would love to use a security key for unlocking a logged-in vault. This would have a convenience similar to “Unlock with PIN” with master password on restart disabled, but be much more secure. To compromise the vault in this configuration, an attacker would need to not only acquire the security key and the PIN, but would also need to get access to an unlocked device with a logged-in Bitwarden session.
I think that you’re forgetting about login with a passkey that does not have encryption enabled (or for which PRF is not supported). This clearly illustrates that the authentication operation is distinct from the decryption operation.
Decryption could also be achieved using the master password, as is the current practice when a login-passkey does not have encryption enabled. But I see nothing wrong with using two separate passkeys (one for authentication, one for decryption), if the user prefers not to enable passkeys that can both authenticate and decrypt.
That being said, I would consider the option of authentication-only passkeys to be less useful than decryption-only passkeys. I would be happy if Bitwarden simply implemented an option to disable authentication (login) for PRF passkeys (whether individually for each passkey, or locally for all passkeys used with a given client, or globally for the entire account).
True, but I never questioned that part. I only tried to point out, that decryption of the vault also is part of a (full) login, and not only “happening” in unlocking.
With distinct operations I wasn’t directly referring to authentication and decryption, but login and unlock – as a response to this:
In the context of this feature request topic, I don’t think it is necessary or helpful to attempt to make such semantic distinctions, especially since Bitwarden is not always so precise or consistent with its own use of the terminology (e.g., when using “Login with Passkey” for a passkey that has encryption disabled, Bitwarden does not refer to it as “Authenticate with Passkey”, and it doesdescribe unlocking as an operation that is distinct from authenticating).
Related to this topic, the first option proposed by @mu88 (“Login only” passkey scope) is already implemented: the user simply has to uncheck “Use for vault encryption” when creating the passkey. However, I think that it is OK for this part of the feature request to stand, because the UI can be improved (e.g., to allow a user to disable encryption for a passkey without having to remove and re-create the passkey from scratch).
As I’ve stated above, the more useful aspect of this feature request is the introduction of an option to disable authentication for an unlock-passkey.
Thank you for compensating my lack of detailed wording to express this properly, very much appreciated! And my bad if some tiny but maybe relevant details remained unclear in my initial post.
@mu88 Do you consider this also as already implemented? (that “Login only”-passkey includes, consequently, the necessity to enter the master password for a login)
Technically, yes, definitely. However, I personally find the UI not very clear and intuitive about this particular implication. I’d love to have a passkey overview in Bitwarden where I could see all my passkeys at one glance, which would make it very easy to distinguish between login / unlock - a bit like such a table:
