Does bitwarden save master password in TPM

ON some of the other password manager, you can save the master password key into the TPM so that when you reboot the computer, you do not need to log into password manager with the master password. Does Bitwarden have a feature like this?

For more information, please refer this page
https://bitwarden.com/help/article/data-storage/#on-your-local-machine

Thanks Vachan, but that is not what I am looking for. I am wondering about the behavior for the desktop client. Let’s say I reboot the computer and reopen bitwarden desktop client, does it allow me to unlock using Wndows Hello using biometrics or does it require you to enter the master password the first time you start the app. On some password manager, you have to enter the master paasword everytime the desktop client is restarted unless there is a TPM to store the master password.

Paul

You don’t have to enter your master password, just validate your Biometrics :slight_smile:

In Bitwarden documentation, it talked about the difference between login and unlocking. I was under the impression that you can only unlock using windows Hello, so rebooting it would mean relogging in using master password?

I may tried this out later on a windows pc, but currently Bitwarden lives on a chromebox and so doesn’t even have this feature.

You can also unlock with a PIN code that you setup. Just be sure to disable the option to “Lock with master password on restart”

See the help docs here:

https://bitwarden.com/help/article/unlock-with-pin/#enable-unlock-with-pin

Ok,
I managed to install bitwarden on a windows box and the behavior is not what I expected. Bitwarden has two states logout when the bitwarden is disconnected from the network and have no access to the vault, and lock where the vault exists in memory is locked. The documentation say that when the vault is logged out, you must enter the master password to re-entered.

Scenario 1 - quit from the bitwarden window client and then relaunch it. I was able to get in using windows hello. I thought this would be mean relogging in, but I got in with just the windows hello Pin.

Scenario 2 - restart windows machine. I was able to access Bitwarden with windows hello PIN. Doesn’t this mean I have to re-login using master password, but this is not the case. I can get in using the windows pin.

This is not a complain but I am trying to get clarification on the behavior. If quitting and restarting machine doesn’t require master password, where is the master password stored?

What is also weird is that when I bring up the desktop client, it flashes a warning that I need to enter the master password and then disappear. The client then work without issue and do not prompt for master password, just the windows hello one.

Your master password is not stored locally - it is only used to generate a key for encryption.

https://bitwarden.com/help/article/security-faqs/#q-is-my-bitwarden-master-password-stored-locally

There is a wealth of useful information in the online documentation that you might find helpful.

Thanks David, but I don’t think the faq answer my question.

When you enable windows hello on bitwarden, it’s proobably not storing the master password but a key. It seems to be storing the key because I don’t need to use master password to get into the vault after a reboot. I can get unlocking using windows Hello. How is that key stored?

The technical bits of how Windows Hello secures keys can be found here:

1 Like

Thanks Trey,
So basically it just uses Hello’s method of storing keys, which tries to use TPM when available. When it’s not available, a less less secure method is used?

Paul

So I switch off TPM and rebooted my computer, I am still able to decrypt the vault without TPM. This mean the key is not being stored in TPM. Perhaps, it will do that if TPM was available, but apparently it is not needed, so how does bitwarden store that key :-).

I am curious because another password I am using enpass, will force you to re-enter master password if TPM is not available on startup citing that that without TPM there is no safe place to stash the key.

Vendors claim a lot of outrageous things - I wouldn’t get too alarmed.

If you want more details about the BW security process, you should be able to find your answers here:

Also if a dedicated TPM isn’t available most modern processors have secure areas that can store secure data.

Dear @paulsiu ,

Have you ever gotten more info on this? Apparently, 1Password differentiates using TPM/not using TPM. While not using TPM, 1P requires re-entering password on restart. If using TPM, 1P doesn’t require entering the password, but will warn about other malicious apps.

BW recently added the option to require re-entering the password on start for biometrics, while recommending that Windows users leave this option on as it is better for security. So, presumably, BW has never stored and is not storing the key in TPM, and either 1) clear-text key or 2) key encrypted with unknown seed (since password is unavailable and PIN isn’t enabled) is stored on disk. As such, using Windows biometrics prior to v2023.4.0 weakens the local vault considerably or completely. And for v2023.4.0, requiring a master password on restart (and not PIN) is definitely a better option.

OK, given the general silence from BW on this topics, I guess we will never find out for sure until BW explicitly documents it, or until someone looks at the code and tells us all about it. I am leaving a note here in case it is any use.

  1. Before this v.2023.4.0, by the app’s design and BW documentation, you’d think that Biometrics unlock, even on Windows, would be stronger than PIN unlock when the user sets it not to require password on restart (i.e. the encryption key is encrypted and then written to storage). With PIN unlock, you would have to turn off requiring password on restart explicitly with the document warning that this weakens the encryption. Whereas with biometrics unlock, there is no option to require password on restart, and the document is mum about any weaknesses. Because BW implements hardware-based keystore on other platforms, you might also imagine that BW would take advantage of TPM on Windows also, albeit the caveat that Windows Hello doesn’t require TPM before Windows 11.

  2. With v.2023.4.0, suddenly out of the blue, BW puts in an option to require password on restart for biometrics unlock, and the document suggests that on Windows, it’s better for security to require password or PIN (!!!) on restart. This is out of the blue because what you see are the change in the app, and a one-liner in the release note on github that doesn’t explain anything. There is no pull-request. There is no bug pending. There is no feature request. No complaint from the press about Bitwarden’s another weak point. Just an improvement out of the blue.

I can imagine 2 hidden reasons for this. One is the discovery of a vulnerability in Windows Hello/TPM. The other is that maybe it is a left-over item from the code audit from last year. Out of the two:

  1. Someone actually discovered TPM vulnerability (TPM 2.0 Library Vulnerabilities May Affect Billions of IoT Devices - Infosecurity Magazine) in the right time frame, at the end of Feb/beginning of Mar. Maybe this is a BW gift to address this issue until some TPMs can be fixed.

  2. There isn’t an item related to Windows hello or TPM in the code audit.

It would be nice if BW would explain this item, instead of us having to guess the intents ourselves.

 

You may be able to figure out what was changed by examining PS 2079:

 


or perhaps @mgibson will have time to offer some insight. (Matt: In case you do see this, the relevant questions are two posts up).

Also, @Quexten wrote a comment in his PS-2370 on GitHub, which suggests (to me) that he may know the answer to your questions. Maybe he will be able to comment here, as well.

I only had a brief look at the biometrics update, and never really looked closely at the Windows code besides what was required to reimplement it for Linux. Still, how I understand it:

Before the biometrics update the biometrics were just an access control.The symmetric master key was stored in the Windows keystore api.

Now, a symmetric encryption key is derived from a signature created by the Windows hello API (which might internally use the TPM, but that would be windows internal, if it did). The key is still stored in the Windows keystore API, but encrypted with the symmetric key derived from Windows hello. Bitwarden does not directly access the TPM to store cryptographic keys.

The issue with windows (and linux) in general is that the security model is fundamentally different compared to more locked down systems such as Android. The OS can’t make guarantees about providing per-app cryptographic keys, and does not provide APIs for this (besides something like Windows UWP and flatpak on Linux).

I can’t speak for the reasons the option to require password on restart was added, but my guess would be exactly the reason above. (Again can’t speak for Windows and haven’t tested it on Windows but this does work on the Linux code which is very similar, but feel free to correct me if I made a wrong assumption):

Before the rework, a valid threat would be malicious code running under the same user. It could ask the OS keystore for the cryptographic keys, and since there is no per-app cryptographic key distinction the OS keystore happily hands the malicious code the keys required to decrypt the vault.

After the rework, malicious code running under the same user would only get an encrypted copy of the key required to decrypt the vault. The malicious code would need to invoke the Windows hello API and have a user happily confirm the Windows hello prompt. Still, if the malicious code manages to do these steps, it could decrypt the vault.

Asking for the master password on reboot and not persisting the biometrics key to the keystore would eliminate this issue entirely. This is why I think it could be the reason for adding the option.

3 Likes

Thanks for your response! I appreciate all the effort you’ve put into making our lives easier and more secure through your code contributions. Your insights are invaluable, and I’m grateful for the answers you provide that others might not be willing or able to give.

Assuming what you say is right regarding the key storage in Windows, prior to v2023.4.0, it would be very easy for a malicious app to get the vault encryption key if you have biometrics turned on, and possibly, the anti-malware/anti-virus programs may not detect it. From v2023.4.0 forward, the malicious app would have to also get the user to authenticate by biometrics to get the persistent key. Also, because the key may not be stored in TPM (according to @paulsiu 's testing, it seems to definitely not), wherever the OS is keeping the keys is also another attack surface.

To me also, it seems like Windows and Linux’s biometric/key storage subsystems wouldn’t be good places to keep persistent secrets; you misstep once, and you may lose all the secrets. You can’t rely on Windows machine to be FIDO2 key or to manage passkeys either. Time to rotate BW key and delete all those FIDO/FIDO2 credentials. Windows, thanks for all the fish.

Once again, thank you for your help and insights!

Yeah, that’s just a limitation of Windows’ security model. Keep in mind many other apps also use the keyring (chromium, vscode use the keyring for example on Linux). If your threat model actually includes malicious code running under the same user, there are other things to also worry about (keylogging on Windows, Xorg on Linux, sniffing the Clipboard, etc.).

It is definetly better than just storing the secrets in plaintext, where it could end up in user backups, be read out on systems without full disk encryption, etc. Still it is not perfect.