Sure, I’ll try to give a brief description @grb
There are three biometrics implementations, Linux, Mac, Windows.
First, let’s talk threat modeling. The attacker model that we underly is an attacker that gets physical access to a device with a vault that is locked. The kernel space (operating system) is not compromised, but the attacker can run anything in user-space. The security goal here is that the attacker cannot access the decrypted vault.
We have to look at the three platforms separately.
Mac is the simplest, it is just storing your vault’s key (“user-key”) in the keychain, and using touch-id as an authentication gate. Authentication happens in the app, not by the keychain. Moving authentication to be handled by the keychain itself is a desire, but not really prioritized over other more pressing matters. Mac by default disables debuggers, and the electron features (devtools) are disabled in production builds, which is why security is achieved. (Side-note, in the past there were versions where devtools were active, which could be used as a means to bypass touchid. This is no longer possible, but shows why keychain-based authentication is better).
Linux stores the key in-memory only, specifically in memfd_secret protected memory or in the kernel keychain. The process in which the keys are held is additionally hardened to not be debuggable. User-space programs cannot get access to the process memory to get the key. Because of this, the security goal is upheld.
On Windows, we handle BFU (before first unlock) and AFU (after first unlock) mode separately. In BFU mode, there is no copy of the key in memory. Instead, we use(abuse) an API that allows Windows-Hello gated deterministic signatures. A static challenge gets signed, and the deterministic signature gets hashed, and this hash gets used as cryptographic key material, to decrypt an item stored on the key-chain. The windows key-chain is wide open to all apps on the user, but the key needed for decryption is only accessible after authenticating with windows hello. In AFU mode, the key is stored in DPAPI protected memory, and the process is hardened against debugging. A separate Windows-Hello API is used to gate access to this key. As per the assumptions of the threat model above, the attacker gains access to the physical device, and cannot gain access to the key. They would have to bypass Windows-Hello in order to unlock the vault.
For Windows specifically, unchecking “require master-password on app start” enables the BFU flow I describe above. Assuming Windows-Hello is secure and cannot be bypassed, this shouldn’t change anything about the security guarantees. It should only be different if you assume a stronger attacker, one that can bypass Windows Hello, or one that has user-space code running while the real user is interacting with the device. However, if you do assume this stronger attacker model, then a bunch of other assumptions also break. (For instance, such an attacker could just take a memory dump of your browser, with your Bitwarden browser extension during use). For this reason, we don’t underly this stronger threat model for any security descisions / designs.
Windows now has Windows-Hello based Passkeys with PRF support, which would be a more approrpiate way to implement unlock. However, again there is a prioritization issue.
) about current implementation details, and especially about the relative risks of unlocking with Windows Hello (with or without “Require master password or PIN on app start” enabled)…