I noticed that Windows Credential Manager has a bunch of Bitwarden credentials in it. I assume some of them are for Windows Hello that I have enabled (Windows Hello PIN to more exact) and used that to open Bitwarden vault. But what? Why? And what are the rest of those? What is that username thing? Internet or network address? And why so many of those in total?!? I might understand one for the Windows Hello PIN…but there are so many!
Now the password can easily be sniffed out of those with proper tools, but is that security issue? What could someone who gets access to those credentials get with them? I hope not my Bitwarden vault from your servers or its content from my computer?
I THOUGHT that everything is encrypted on my computer by my passphrase (& alternatively with Windows Hello security token protected by TPM and PIN) and all that data would be decrypted in computer memory and used to do whateverneededtodo…and I expected them to be in the Bitwarden folders data! Especially I expected that when I closed the Bitwarden program, unless I gave PIN/passphrase, there would be absolutely NO credentials or passwords or access rights anywhere that could be exploited in ANY WAY, if someone could sit in front of my computer for a while. I DID NOT expect to find something like this sitting there.
So please explain this to me and please, please tell me this is not a security issue / bug?
.
.
.
BTW. I came up with this SECURITYU VULNERABILITY that claims that using Windows Hello to open the Bitwarden is NOT SAFE because those credentials can be harvested and used to decrypt all the data…that one should have settings set to “Require password or PIN on app start” instead of “Ask for Windows Hello on app start” (which is what I have been doing). In other words, one should only use Windows Hello pin to open locked - not closed - Bitwarden vault. IS THIS STILL THE CASE OR HAS THIS BEEN FIXED?!?
Try disabling “unlock with biometrics” in all apps and browser extensions on that computer, and then logging out fully (not just locking) all apps and browser extensions on that computer. Then check the Windows Credential Manager again (perhaps after restarting the computer first).
Why would I do that? That does not answer to any of the questions I asked.
I tryed deleting them and then I could not open Bitwarden with Windows Hello PIN and had to use my passphrase…and to sign into the Bitwarden account too.
Your local Bitwarden app is also connected to Bitwarden’s cloud, hosted in Azure. Access Tokens and Refresh tokens are part of the authentication mechanism for that.
Windows Hello PIN is considered a biometric, which is why credential manager has biometric entries for Bitwarden when it is configured for biometrics.
That said, you can delete anything you want in credential manager. Worst thing you have to do is to reenter your credentials (i.e. password) or re-setup biometrics.
Interesting test. That tells you that they are part of making biometrics work. Now, set up biometrics again and I bet the Credential manager entries will reappear..
It would demonstrate why the credentials are there, which was one of your questions. For example, logged-in apps or browser extensions need an access token and refresh token to be able to sync with the cloud servers. If biometric unlock is enabled on restart of an app or browser extension, then a key must also be stored for the purposes of decrypting your vault on unlock.
If you read the report at the link you posted, you will see that the status was changed to “Resolved” on May 8, 2023, and that a fix has been in place for the past two years.
The TPM credentials are themselves encrypted, so although an attacker could potentially obtain a copy of the credentials stored in the Windows Credential Manager, it would just be a meaningless random string, unless the attacker is able to get you to complete a Windows Hello authorization.
And that fix was exactly…what? That that data cant be accessed by other processes anymore or was it actually fixed so that that data is encrypted by TPM?
If Bitwarden vault is indeed then encrypted properly with Windows Hello + TPM (PIN), then why is there still in the settings “Recommend for security” in the option “Require password or PIN on app start”? There shouldnt be, right, if the issue is resolved? Using “Windows Hello on app start” should as secure as the “Require password or PIN on app start” then, right? So why its still there if that is the case? Why is it sayed to be “Recommend for security”?
Makes no sense, if the issue is resolved.
However, makes perfect sense if the issue is really NOT resolved and gaining access to those credentials would gain access to the vault (as sayed in the link I posted)…and the “fixed” only meant that access to those unencrypted tokens was just limited from other processes/users, but they where not really encrypted.
Does not really matter. The only thing stored in the Bitwarden cloud is an encrypted copy of your vault. Although I would rather the encrypted copy remain out of a bad actor’s hands, it also is not a really big deal because a long, unique and random master password is the true defense.
Also, if a bad actor were gain sufficient access to your PC that they could attack the credential manager (which MS works pretty darn hard to protect), they probably would just install a keylogger, leading to the second important defense… do not unlock your vault on devices for which you don’t practice good opsec.
…but why arent these credentials to access the cloud also encrypted using Windows Hello (TPM) or users passphrase??? Why not? Why leave them in the open?
User has to authenticate anyway before they can use the Bitwarden vault, so you could get the authentication (passphrase or Windows Hello) there anyway. And if user is not able to authenticate (using passphrase or Windows Hello), then they should have no need or right to access the cloud data either.
This indeed seems to be the case. Atleast I hope it is.
Oh, Im not trusting biometrics, there has been plenty of hacks that break Windows Hello fingerprint readers or face scans (data stored unencrypted in the devices and can be hacked easily). But I am trusting TPM + PIN on Windows Hello.
Who says they are out in the open? The visible item is a record that the credential exists, but you might note that there is no eyeball to click next to the password.
Read the access token and refresh token links earlier sent. They explain how windows/Entra persists authentication so the vault can repeatedly sync while it is open instead of just when you first authenticate. Also helpful would be to consult Dr. Google to learn how Microsoft designed the Credential Manager and Credential Guard to protect secrets better than than just keeping them in memory or on disk.
You might also read Bitwarden’s security whitepaper to understand the controls they have in place.
As I clearly sayed earlier:
“password can easily be sniffed out of those with proper tools…”
Like tools like this:
As I clearly sayed earlier:
“why arent these credentials to access the cloud also encrypted”
“User has to authenticate anyway before they can use the Bitwarden vault, so you could get the authentication (passphrase or Windows Hello) there anyway. And if user is not able to authenticate (using passphrase or Windows Hello), then they should have no need or right to access the cloud data either.”
When vault is unlocked then it could sync as it wants since credentials are in memory anyway, but when it is locked, there should be no need to store cloud credentials in the computer (without encryption derived from user authentication)…as they could be stored encrypted there and decrypted only when user authenticates (via Bitwarden passphrase or Windows Hello).
Again, the points are and remains:
Windows Credential manager content can be pillaged using proper programs.
Pillaging it gets attacker access to the cloud storage for the Bitwarden vault (even when Bitwarden program itself is closed in the users computer).
There is no reason for this to be this way: Those credentials could also be encrypted so they would be useless to attacker and decrypted when user authenticates.
The way I see it is, that this is a security vulnerability and bad design.
I would like to share some observations; I am not debating whether the current situation is bad, good, or a compromised design.
Generally, AccessToken and RefreshToken are used to grant the client access to server resources. Theoretically, these could be stored encrypted while the application is in a locked state. In that case, the locked client wouldn’t be able to interact with the account on the server at all. Currently, in a locked state, you can log out (clearing the tokens on the server as well) and sync the vault; if encrypted, the client presumably wouldn’t be able to interact with the server that way. Not being able to “properly” log out (i.e., clearing the states on the server as well) despite the client being locked may be considered undesirable for some.
The above strategy is not a problem on restrictive operating systems like Android and presumably iOS. The secure storage should be limited to the Bitwarden client only. It is a problem on permissive operating systems like Windows and presumably Linux and macOS as well.
If you don’t require a password on restart, the encryption key (or a derivative) must be stored in either data.json or the credential manager as well. If you use Windows Hello (and not a PIN), presumably it is in the credential manager. The last time I checked, BW’s RUST function call doesn’t guarantee that the key will be in the TPM, because guaranteeing it requires calling an attestation function, which BW doesn’t do.
Presumably, the encryption key in 3. is encrypted using some form of Windows Hello encryption function that is only possible after authentication with Windows Hello. The ultimate weakness that is unfixable is that any user-space process (including malware) that can get you to authenticate via Windows Hello will be able to access the decrypted key. This is apparently a problem with 1Password as well (which guarantees storing the key in the TPM).
I personally assume (true or not, see links in the edit note below) that if the tokens can be lifted from my systems, the attackers can download my vault without logging in (and without generating the new device email). Only the password would prevent the downloaded vault from being revealed. Deauthorizing all sessions would invalidate all the tokens.
So, always require a password on restart (which you can mostly substitute with Login with Device) and avoid getting malware on your device. If you get malware on your device, they can definitely keylog you and potentially read from the memory of an unlocked BW client too. Security and easy access are mostly contradictory and there needs to be a balance at all levels. What we consider “balanced” are most likely subjective.
edit: See Quexten’s comment about being able to decrypt the “userkey” using "osKeyHalf " after authenticating with Windows hello, when require masterpassword on restart is not checked. See another of Quexten’s comment about what the security model is, or what BW aims to protect, regarding AccessToken, RefreshToken, and decrypted vault.
I’m not going to put too much effort into my response, because you evidently distrust even official published statements from Bitwarden — so you are likely to also discount anything said by me, a random person on the internet.
That being said, the fix does not rely on “encryption by the TPM”. The vault secrets are encrypted by your symmetric user key, and the symmetric user key is itself encrypted (by the Bitwarden client) before being stored in the TPM (where it is again encrypted — a third time). Thus, even if an attacker can circumvent the third level of encryption to extract credential data from the TPM, in the case of the Bitwarden data, the string extracted from the TPM is useless, unless its encryption can be decoded. The symmetric encryption key used to decode the string extracted from the TPM is derived from a signature created by the Windows Hello API upon successful authentication. Thus, without your cooperation to complete a Windows Hello authentication, an attacker will not be able to anything with the information extracted from the TPM.
Nirsoft does not work anymore as of Windows 11 (24H2), unless the targeted user has deliberately disabled the LSA protection. In addition, even for users running outdated Windows versions, it required the attacker to know the Windows Logon password of a user or of an administrator account on the computer.
No password manager can protect a user who is that lax about their security.
Why should a locked session be able to sync? If that is what you want, you could archive this by simply sending the new data to the server and to clients using PKI or even simpler sessions keys…when session is opened, that data could be added to database/vault. In this way, attacker getting their hands on those PKI or session keys would NOT be able to download the data, only send new data or remove some data from the vault…nothing that happened before session was locked could be compromised in any way.
To log out without “opening the vault/program”, one could simply give a token to do that and nothing else than that (“a magic packet that program sends”). A simple “terminate userX sessionZ” would do the trick.
3.If you use Windows Hello (and not a PIN), presumably it is in the credential manager. The last time I checked, BW’s RUST function call doesn’t guarantee that the key will be in the TPM, because guaranteeing it requires calling an attestation function, which BW doesn’t do.
With what? Where is that key that encrypts it, stored and in what form? This seems like a stupid step, since there is no way to store that safely and if TPM is already used it is not even needed.
If you are talking about using users passphrase to do this, that does not make any sense (when TPM is involved), because it would mean that user would still have to provide that passphrase to open this level of encryption (which they dont have to, if Windows Hello is used). It ofcourse makes all the sense if Windows Hello is NOT used and you open up your Bitwarden vault with just your password.
before being stored in the TPM (where it is again encrypted — a third time). Thus, even if an attacker can circumvent the third level of encryption to extract credential data from the TPM, in the case of the Bitwarden data, the string extracted from the TPM is useless, unless its encryption can be decoded. The symmetric encryption key used to decode the string extracted from the TPM is derived from a signature created by the Windows Hello API upon successful authentication. Thus, without your cooperation to complete a Windows Hello authentication, an attacker will not be able to anything with the information extracted from the TPM.
Thank you, this is the response I was looking for.