Here’s the answer of the probable major factor that triggered this change:
https://www.reddit.com/r/Bitwarden/comments/147nr9y/bitwarden_windows_client_vulnerability/
The meat of the matter is in the source HackerOne report (including the discussion following the report):
OK, so here’s another related security problem it fixed:
I have a feature request, but I wanted to first inquire about this topic on this thread, to make sure I’m not requesting something out of scope.
@Quexten
I wanted to login to bitwarden using the desktop app on Linux without the master password. (I can’t be bothered to remember an actually secure password and type it.)
Currently, the Bitwarden desktop app does not have any method to do that or allows me in any way to pass the password to the program in a script friendly way.
I think the way to go about this, is indeed to use the TPM and the methods on Windows and MacOS also use the TPM underneath (call it secure enclave or what not.)
I would be willing to contribute this, but not if it has no chance of getting accepted.
You mentioned that there is no way to make that work on snap and flatpack. I don’t know about snap but flatpack does allow access to the TPM via –device=all though that may be too permissive for bitwardens security standarts.
In my opinion, it would be fine to simply not ship this feature on snap and flatpak and enable them when they keep up with current standards in sandboxing features.
I also saw you talk about, how you don’t want to ship eventually insecure and dangerous features to users. In that case, I don’t think there is anything to fear with regards to accountability because users need to manually add themselves to the tss group first and probably also enable it in app.
What is the consensus on this?
@Mikilio Welcome to the forum!
Sorry, not a contribution to your actual question, but I just wanted to add here, that there are plans to bring “Login with passkey” also to the desktop apps, which would be an alternative login method without master password.
Here is the corresponding feature request: Sign into Bitwarden with a passkey / "Login with passkeys" (for all BW apps) – and here a corresponding PR: [BEEEP|POC] Add infrastructure for native PRF passkey login on desktop by quexten · Pull Request #17420 · bitwarden/clients · GitHub
(but if you look into it, only Windows and MacOS are mentioned so far – and I don’t know about the current status or prospects for Linux, though…)
PS: If you meant “unlock”, there’s also passkey unlock planned for the first clients, see here: Unlock with FIDO2/“passkeys” (and in general: the desktop app can also right now also be unlocked with PIN or biometrics)
@Nail1684 The initial PR actually has Linux support but only for security keys. I had a proof-of-concept for bluetooth / hybrid, but that requires a lot more infrastructure / GUI support because the linux platform support is just worse, regrettably. I may take some time to do this in the future however, as Linux is my main use-case for this.
@Mikilio As to the TPM proposal; First, do you mean login or unlock. I do believe you mean the latter, but i’m not entirely sure? As for the specific proposal, if the user has access to the TSS group, that means that any application not sandboxed in flatpak/snap can access the TPM and thus unlock the bitwarden vault. Effectively, that means that locking your vault no longer serves any security function because it can now be trivially bypassed.
The secure way to do this, given Linux’ security model, would be something like:
- Install a daemon running under the tss user. This would listen for requests via dbus and inspect the requesting process, and validate the process contents against a digital signature. (I’m not sure if this is currently possible because of the process hardening added recently)
- Only hand out the Bitwarden secret stored in the TPM to validly signed Bitwarden executables
I meant the first unlock where biometric login is not available. (I just assumed that was login)
In my thread model, I assume all applications I run under my UID to be trustworthy and rather sandbox unsecure applications, so I haven’t considered that being a problem.
If process fine-grained access control is required, how about using apparmor or SELinux. I think they were developed exactly for this use-case and are quite common in most distros.
The way that you were suggesting with validly signed Bitwarden executables. Do you mean IMA? I think I read in their docs that the recommended way to create policies is also by reusing SELinux rules.
If dbus access rules are enough control, we could use tpm2-abrmd (which is also moving all it’s functionality into the kernel)
Would that be sufficient?
Bitwarden clients support login using master password, using SSO, using another logged-in device, using passkeys, or using emergency access. Biometrics is not a supported login method; it is only supported for unlocking a client that is already logged in.
The documentation that explains the difference between “Log In” vs. “Unlock” is available here:
I was referring to the first unlock, that unseals/decrypts the local vault. @Quexten made the correct assumption.