Well, is the key in the TPM or not? Simple question. Neuron says there is no guarantee that it is.
Nirsoft does not work anymore as of Windows 11 (24H2),
No, but LaZagne.exe tool works just fine and can grap those passwords from Credential Manager as I showed in the picture.
Did you read the rest of my comment? I explained this already:
It is not stored, it is generated on demand, by user interaction.
I never mentioned the âusers passphraseâ or master password.
Youâre welcome?
As far as I can tell, @Neuron5569 is discussing what happens if the option âUnlock with master password on restartâ is disabled by the user, in which case the biometrics-protected key must be written to some form of persistent storage (normally, it would only be kept in volatile process memory, but this will no longer work if the user insists that the biometrics-protected key should be available after the Bitwarden process has been terminated and restarted). Itâs been a while since I looked at the code details, but I have no reason to doubt what @Neuron5569 asserted: Bitwarden will try to store the biometrics-protected key in the TPM, but makes no guarantees that this will be possible.
My own response was an explanation of how the biometrics-protected keys are secured in the case when they are in fact stored in the TPM (in response to your concern about TPM vulnerabilities). I wasnât implying that they are always guaranteed to be stored in the TPM.
Regardless, given your perspective on the security of the TPM (or lack thereof), it should make no practical difference to you whether the biometrics-protected keys are stored in the TPM or in the vault cache (data.json, etc.). As far as youâre concerned, the keys are equally accessible to an attacker from either storage location. And the requirement to decode the protected keys using a Windows Hello signature is the same in either case.
Have you tested it on a system with LSA protection enabled? Even if it does somehow circumvent PPL, it still needs administrative privileges to work.
Why would it even try to store it in TPM, since its already cryptographically protected by TPM / Windows Hello in any case? It makes no difference where it is stored, since its (encrypted) protected. Ofcourse paranoid user might like the idea of them being overwritten in case they change or user logsoff, but thats an other question entirely.
I was not concerned about the keys being accessible to attacker, I was concerned that they where NOT protected by cryptograpgically binding them with Windows Hello. If there are all the time protected by it, no matter what, then there is no problem (except that paranoid user might want them to be overwritten when not used anymore). If they arent, then there is problem (a serious one).
One completely different thing is that if indeed Bitwarden stores credentials to access the vault unprotected in Windows Credential manager, allowing attacker who gains access to them, to download users entire Bitwarden database (altought encrypted) from the server. This IS a serious security issue and again I see no need this to be this way, it could easily be fixed with the methods I describred earlier.
Huh? How can it have TPM protection without being stored in the TPM?
In the TPM, it will have an additional layer of encryption. Storing the protected keys there increases security, because an attacker would need to obtain elevated privileges to extract the keys; if the protected keys are stored on disk, they can be exfiltrated from the user context, without elevating privileges.
In addition, having secrets split into multiple locations (disk and TPM) would provide protection against other threat models, such as if your device is discarded and its hard drive is removed. If the protected keys are stored on disk, then they could be accessed just from the hard drive.
Yes the cryptographic protection is there all the time. Prior to 2023, there was a vulnerability in Windows-based client apps locked with biometrics.
I have no evidence that this is the case.
But as @Neuron5569 has already pointed out, if an attacker is able to access your device with administrative privileges, then no amount of encryption of the session tokens will protect your vault â not to mention the fact that they can just copy the entire vault database (encrypted) directly from your device, no need to access the cloud servers.
A final note: If you are not using actual biometrics in Windows Hello, but a PIN, then the weakest link in your security is probably the entropy of your PIN.
Store it in hdd encrypted by TPM:s public key for example. TPM:s private key is required to decrypt it. Voila.
Good point(s).
Well, the tokes are there and since there is only information saying that the tokes related to Windows Hello are encryptedâŚso the other tokens dont seem to be by this logic. If they where, it would have been sayed.
Ofcourse they do, if they are encrypted (with encryption with Windows Hello), extracting them from the computer does not help attacker at all of gaining the database from the servers. He needs unencrypted session tokens to do that.
You are mixing two different things:
- Being able to (locally) access the computer
- Being able to access the servers (remotely)
Yes, ofcourse he could then just copy the encrypted database directly from hdd, if he could. But then he really had to do it directly from the hdd then. But to get the database from the server, that could be done remotely at later time and some other location. ALSO, local database could be further encrypted by user by something the attacker cant get access to, while the database on the server is only encrypted by users passphrase to be exact.
Two different things, different attack vectors.
Wrong. If Im using actual biometrics then its the weakest link, since there has been numerous vulnerabilities in the Windows Hello biometrics (as I mentioned: For example they store encryption keys unprotected in the biometric device, like fingerprint reader and it can be extracted there, completely opening the whole security and everything that it is based on). ALSO, anyone can steal anyones biometrics pretty easily, especially fingerprints.
But if Im using PIN, there is no way for you to steal it from my anything that I touch (like fingerprint) or by just taking a picture of my face with special camera (like facial recognition)âŚyou really have to guess it or use some keylogger on my computer to get it. Also, the PIN is NOT stored unsecured in some crappy POS device where it can be easily extracted, its stored securely in security chip called TPM. Yes, there have been some vulnerabilitys in some TPM:s, but nothing that bad like there have been in those fingerprint readers and cameras used in Windows Hello biometrics.
Ofcourse, if my pin is bad, then all bets are off. But if its good, then there is pretty much no way around it, not atleast as easy ways as there are around Windows Hello biometricsâŚTPM has anti-hammering protection for PIN guessing.
Windows Hello should be improved, in my opinion, by allowing to use 2 different things in it, for example both PIN and fingerprint to open whateveritisprotecting. Or having the ability to use like 2 out of 4, 3 out of 4, 4 out of 4, etc. combinations, whatever you like. Personally I would love to have option to use Yubikey (with or without PIN) + EITHER face or fingerprint to open. This could easily be accomplished by using things like Shamirs secret sharing etc.
Where are you reading this?
The distinction seems trivial. The attacker either copies the session token or the vault cache while they have access to the device. It doesnât matter what time and location the attacker chooses to continue to exploit. If anything, stealing only the session key is easier to protect against, because the session key can be invalidated by routinely logging out, or by deauthorizing sessions if unauthorized device access was discovered.
I doubt that any Bitwarden user engages in local encryption of the vault cache, which requires the cache to be decrypted anytime that the vault needs to be unlocked.
Also, the cloud database is not encrypted by the userâs master password/passphrase, it is encrypted by a randomly generated 256-bit user key. The user key is protected by encryption using a 256-bit key derived from the userâs master password, email address, and a randomly generated salt (using a KDF algorithm). The protected encryption key is further encrypted by a separate encryption key that is stored separately, in a strictly controlled Key Management System. An additional layer of encryption is provided by Azureâs Transparent Data Encryption (TDE), which uses keys that only authorized Bitwarden server components are able to access. Thus, the cloud database is protected by two layers of encryption, while the user key is protected by four layers of encryption.
An attacker who can access your device with administrative privileges could easily install a keylogger, so this whole debate is a bit academicâŚ
Thatâs what I was referring to when I said âthe weakest link in your security is probably the entropy of your PINâ.
Please link the relevant Microsoft documentation.
This thread literally.
DIstinction between local and remote attacks are, well, different, not trivial.
Well, for example I have EFS encrypted the folder containing the Bitwarden vault. Ofcourse, anyone gaining access to my account via correct means can therefore decrypt it as they can decrypt Windows Credential Manager session data - and if they cant gain access to my account via correct means then they cant decrypt either anyway. (Whats the point? Well, my point in this is not about protecting Windows Credential Manager session data, done this a long time before I came to be aware of this vulnerability.)
I just sayed it in simpler way: Getting the database and Bitwarden passphrase gets you unencrypted content of users Bitwarden data, period. Email can be easily guessed or known, salt is with the database anyway.
Source?
Does not really matter if database can be downloaded via Windows Credential Manager data that user has in their computer and hacker can get access to. I assume its decrypted before downloaded to computer (by the server), otherwise local Bitwarden could not decrypt it and use it.
The point of local and remote access to Bitwarden database is the key here, not this. There are endless number of other attack vectors that might compromise Windows Credential Manager content, but not gaining admin access to the physical computer.
You seem to be missing the whole point of this conversation, let me refresh it to you:
I assumed that when user has logged out of Bitwarden app or it was even locked, sitting in from of my computer would not get attacker access to Bitwarden vault, because all access to the vault was shut down (because it was stored in Bitwarden folder and encrypted by a key that is no longer accessible because Bitwarden app is closed or locked). THIS IS NOT THE CASE, because vault can be access via this data in Windows Credential Manager.
My point is that both of your scenarios involve a local attack â either against the local vault cache or against the local TPM.
An attacker with access to the TPM already has access to your EFS folders. I was responding to the claim you made that âALSO, local database could be further encrypted by user by something the attacker cant get access toâ â EFS encryption is not an example of this.
The attacker can just as easily obtain this information without ever acquiring any session tokens.
When it comes to vaults that are locked (logged in), your assumption is wrong, and it has nothing to do with the TPM. While a Bitwarden app or extension is locked, its encrypted vault cache is stored on the local device, and as youâve said: âGetting the database and Bitwarden passphrase gets you unencrypted content of users Bitwarden data, periodâ.
When it comes to vaults that are logged out, it is true that âsitting in from of my computer would not get attacker access to Bitwarden vault.â In this state, there will be nothing of value to steal in the Windows Credential Manager.
The ones you have mentioned in this thread require administrative privileges. Regardless, even it were possible to disable PPL from the user context, an attacker with this level of access can just as easily acquire the vault contents without using any session keys.
This thread got a bit heated, and I feel the need to chime in.
THIS IS NOT THE CASE, because vault can be access via this data in Windows Credential Manager.
No. The decrypted vault data cannot be accessed with whatâs in Windows Credential Manager alone.
Whatâs stored in credential manager (or in mac keychain on mac, or gnome-keyring / kwallet on linux) is:
- Access token + Refresh token
- Biometrics key encrypted userkey
The access token plus refresh token are indeed enough to authenticate to the servers and download encrypted vault contents. This is not something that is considered a vulnerability currently however, and there are valid reasons for requiring the access token while in a locked state. This may be changed in the future.
As for getting access to decrypted vault contents:
On windows, assuming you have âRequire masterpassword on app restartâ enabled, biometrics works by:
- Use windows hello to derive a system wide osKeyHalf, by signing a static challenge
- Windows hello does not provide a means to encrypt data. Itâs authorization only, or signing currently.
- Decrypt the clientKeyHalf using the userkey the first time you unlock, and hold it in memory
The above keyhalves combine to form the encryption key that encrypts the userkey, that is stored in Windows credential manager. So, to decrypt it you would need to at least bypass Windows Hello, and get a memory dump of Bitwarden.
If require masterpassword on restart is not checked, then only the osKeyHalf is used to protect the userkey stored in Windows credential manager. Thus, any application calling the Windows hello API, and authenticating can get the osKeyHalf.
There is also a lot of misinformed claims made about what TPMs and Windows Hello can be used to provide on windows made in this thread. The API surface provided is significantly less useful than Keychain on MacOS which does allow binding biometrics to a protected credential.
The TPM is exposed through a few means (such as credential manager, and the Windows Hello Signing API), but using the TPM directly is just not tied to Windows Hello in any way that would usefully protect you against an attacker with access to your unlocked device. What it does do is help protect scenarios in which your bootloader or operating system is tampered with.
Thus, the cloud database is protected by two layers of encryption, while the user key is protected by four layers of encryption.
@grb, they were clearly referring to the vault contents as downloaded by using access tokens. Those vault contents have just one encryption layer - the userkey. You are referring to the encryption as stored in the physical database servers. Whichever encryption layers exist on the server side are stripped before the vault is returned by the API. I just want to clarify this because it may cause confusion in this discussion.
4 Likes
@Quexten, thank you for weighing in and sharing your expertise.
As for any claims that I personally have made about TPM and Windows Hello in this thread, they were based on this comment by @mgibson as well as this comment that you made in 2023.
Further clarification of implementation details from the Bitwarden team is always welcome â explanations from authoritative sources tend to be few and far between when it comes to the nuts and boltsâŚ
2 Likes
Getting data from servers using stolen Windows Credential Manager credentials is a remote attack to the servers. This attack window should be closed by encrypting these credentials too with something that is cryptographically tied to the Bitwarden vault / account, so that in order to decrypt them Bitwarden password or Windows Hello authentication should be needed. This has been and still is my point. As it is now, it is a vulnerability.
Actually no. Other users do have access to TPM but they do not have access to my EFS folders (unencrypted).
Again you fail to understand the difference between local and remote attack to gain the information.
As I sayed, if there ever is an attack against Windows Credential Manager then this security model completely fails the users, since you put your trust to that instead of the actual app (encrypted) data to control access to cloud database.
Iâd like to see some evidence for your claim that, on a computer running an up-to-date operating system, the TPM secrets can be access by someone who possesses neither your Windows password, nor any elevated privileges, nor access to your unlocked Windows account, and who does not have your cooperation to complete a Windows Hello authentication on their behalf.
You have not provided any evidence of this, but if you feel that way, you always have the option to vote with your feetâŚ
I sayed, access to TPM, not access to TPM secrets by other user. Anyone who is admin can, for example clear TPM etc. but they cant get access to other peoples TPM secretsc.
Literally the whole topic is about this fact:
Bitwarden stores data in Windows Credential Manager, that allows attacker to download users Bitwarden database, even the session on Bitwarden is locked, because this data is not encrypted with Bitwarden as other Bitwarden user data is.
-Here is a security vulnerabilityâŚ
-You have the option to vote with your feet!
Youâve repeated these claims many times, but repetition does not constitute evidence. You have provided no evidence that the session tokens can be stolen without already having access to your Windows account (and therefore, already having access to the local copy of the database).
Changing of the goalposts & red herring.
I have claimed and proven in this conversation, that those tokens can be stolen and used to download (remote attack) the database from Bitwarden servers, because those tokens are not stored in encrypted form, that would be accessible to and only to Bitwarden app, when it is properly opened (cryptographically secure manner).
The âbut you have to have access to Windows accountâ issue is just something you came up with, and has nothing to do with the actual factual issue Im talking aboutâŚand no, Im not saying you are wrong, so dont try that red herring either, Im saying that it just does not have anything to do with the actual factual issue Im talking about. Its like saying âBut this can only happen if its full moonâ or âUnless X and Zâ. Nope. It makes no difference related to the original claim and no matter how much you try to red herring the original claim and change the goalposts, this only happens inside your mind: The fact of the matter remains regardless of these strange ideas of yours.
Again, the fact of the matter is and continues to be:
Any tokens that are needed to download users Bitwarden database should be encrypted in such manner that they cant be used (to download the user Bitwarden database) unless decrypted (having Bitwarden database open).
OK, thank you for confirming.
When it comes to an attacker who already has access to your local Windows account being able to access information in the Windows Credential Manager, Iâm not saying you are wrong, either.
My point is that Bitwardenâs threat model relies on the user to prevent unauthorized access to their devices:
You, as the end-user and/or device owner, are responsible for ensuring that your devices are secured and protected from non-authorized access.
To my knowledge, there is no available password manager product that will guarantee the security of your data if you use the password manager on a compromised device.
Bitwarden regularly engages independent security consultant to conduct security audits and pen testing, and these third-party reports do not include any concerns about the Windows Credential Manager.
If you allow unauthorized access to your devices, then the exact method used to compromise your vault doesnât matter â the threat actor has myriad options for acquiring your data.
To my knowledge, there is no available password manager product that will guarantee the security of your data if you use the password manager on a compromised device.
To be clear, it is a security goal that a locked vault stays locked. If your laptop is stolen, with the laptop unlocked, but Bitwarden locked, it is a security goal that the attacker cannot access the decrypted vault contents.
Preventing access to long-term secret encrypted data (i.e the sync response) when a device is stolen, is not a stated security goal, and is also not in scope in e.g. HackerOne. In fact, encrypting the access token would not alone be sufficient to achieve this goal, since the local cached copy of the vault (data.json for the desktop clients) is also encrypted with the same long-term secret keys, and is the same as what you would get from the sync API response.
What is not guaranteed is security of your vault if there is malware running on your user account, or even kernel, while your vault is unlocked. (That includes a keylogger running in the background). For this, all measures are best-effort.
4 Likes
Stupid question perhaps, but why?
Why isnt local cached copy encrypted with additional key that is stored in Bitwarden servers and only downloaded against cryptographically secure challenge against the user? Then the attacker gaining access to the database locally would not only need that key from the servers but also the users passphrase/Hello token to decrypt it. Then it would not be protected with âjustâ users passphrase/Hello token, but also something that is only in the server and that needs to be downloaded to gain access to the local database. When user locks the session on Bitwarden, closes the Bitwarden or logs out of Bitwarden, that key would be desroyed in memory and would have to be redownloaded from the server.
Ofcourse one could argue, that if you have users passphrase/Hello token, then you could as easily just identify as that user to the server (in the same computer, without the 2FA hassle etc.) and get that decryption keyâŚand if you dont have them, then you cant decrypt the local cached database anyway. BUTâŚBUTâŚ
- It would be much better to have two-layer encryption to local database at rest anyway.
- If users laptop etc. is stolen, he could sign into Bitwarden and signout those sessions, effectively destroying that extra key, making it impossible for the attacker to gain access to that (local cached copy of the) database EVEN if the attacker would know (or get to know later) the users passphrase.
- If the connection to Bitwarden servers would be secured by tokens stored in Windows Credential Manager (+ encrypted with user passphrase/Hello token for other reasons pointed out in earlier post)âŚsince they are also encrypted by Windows user keys, attacker would need to get NOT ONLY users Bitwarden passphrase/Hello token BUT ALSO users Windows passphrase (or an other Hello token) to gain access to them.
HmmmâŚ