I have some question about bitwarden security settings. Let’s start with the browser extensions. If you click on unlock with pin, you have an option for “Lock with master password on browser restart”. If I don’t check this option, I can unlock using the pin without entering the master password, but then we have this vulnerability:
The issue is that you can then brute force the pin. To get around this one would make sure that “unlock using the pin without enter the master pasword” is checked so that when user restart, they will have to enter the master password first.
The article did say that the attack require local access, but can someone actually copy the vault to a thumb drive and brute force the pin?
What if you use the desktop client? If you setup the desktkop, the authentication comes from Windows Hello. Does this mean the PIN attack issue no longer matters if I use the Window Hello Pin?
While we are on the subject, I like to know how TPM plays into the security. I posted about this a while back, but never got an answer. How does Bitwarden use the TPM? Thanks.
I can’t speak to the security of biometrics or TPM, but with regards to the old gHacks article that you’ve linked, this is a re-telling of blog post by Ambiso, which was thoroughly discussed both here on the Community forum and on Reddit when it was first published — and largely dismissed as FUD.
The quote from my contribution to the discussions back in March:
To answer your specific question about whether someone can “copy the vault to a thumb drive and brute force the pin”, please refer to this comment of mine, from a 2022 thread:
This comment from 2022 only demonstrates how brute-forcing might be done manually, and postulates that automation may be possible. However, Ambiso’s proof-of-concept from January 2023 demonstrates how an off-line brute-force attack can be automated using a script.
Note that whether something is FUD or not should be a decision made by the reader. I am not here to make judgement on opinion. I am seeking to understand how everythings works so I can make my own decisions. I like to thank you for the link, they were most helpful.
Based on ambiso’s original article, when you chose not use master password on browser startup, the local vault gets encrypted with a key based on the email and pin, which means if someone were to gain access to the drive, they could just copy the vault and bruteforce the pin. I have some follow up question then, some were not answered by Ambiso’s post.
The first is the use of third party unlocking mechanism like Windows Hello. Most of the comment about PIN vulnerability seems to be center around the browser extension. A bit of confusion is that Windows Hello also allow you to set a PIN. I don’t have a windows machine with admin rights to try this on. Based on instructions, if you have a windows box, setup the desktop client, and windows hello, and then go into the browser security option, there should be an option for PIN, and an option for Windows Hello. If you choose the pin, it will continue to use the email+pin to encrypt, if you choose windows hello, the encryption will be done by the master password provided by Windows Hello? If I am unlocking using window hello pin, can I assume that the vulnerabilty specified in the article does not apply?
If that is the case, I wonder how secure windows Hello would be if the computer does not have a TPM. Back when I had access to a windows machine with admin rights. I notice that even though the computer did not have a TPM, I was still able to start the computer up without entering the password. I was wondering how secure the software storage for Windows Hello is?
One more question I have is that there is another option where there is option to “Never” log out. When you set this up, it will open the vault as soon as you open your browser. My question is how does this mechanism works. If using a pin encrypt the vault using email address and pin, does never login means the vault sits on the drive unencrypted?
Sure. I was just summarizing the community’s reaction when Ambiso’s claims first made the rounds of the online (in)security publications, back in March. To help you in your assessment of Brinkmann’s article for gHacks, I would point out that nowhere does he disclose that unlocking by PIN only becomes a vulnerability if the user deliberately disables the “Lock with master password on restart” safeguard (which is enabled by default), nor do his “Recommendations” at the end of the article include the obvious solution of re-enabling the option to “Lock with master password on restart” (or to not touch the default setting when enabling a PIN).
This is inaccurate. It is the symmetric encryption key that gets encrypted using a stretched key derived (using the account’s KDF settings) from the PIN; the vault itself remains encrypted using the original symmetric key.
As I responded originally, I have limited knowledge of the biometrics implementation, as I do not use this option myself.
There was some relevant discussion about biometrics security in a recent update to one of your other threads:
To your final question:
No, the local vault cache is always encrypted. However, when you select the option to Never lock, the symmetric encryption key itself is saved (unencrypted) in persistent storage on your device. As explained in @Quexten’s comment linked above, the symmetric encryption key is stored in the Windows keystore API, and available to anyone or any process logged in to your device as you.
Yes, the solution should have been mentioned since that is what most people is after, not how it actually works.
You are right that I am inaccurate with the description. I should have probably said that the pin+email unlocks the key use for decryption. Keep in mind that my knowledge of encryption is probably lower than yours. However, what I got out of it is that given the vault file, you can decrypt the vault using PIN + mail if you allow the key to be saved to disk.
I ask that question about Windows Hello years ago. I did not realized that someone followed up recently. I am not entirely sure what Quexten meant about per app encryption but I assume that perhaps on other platform each app have encryption key that are app specific to prevent access by other apps.
I have poked around and notice that there are utilities that can hack Windows Hello PIN if it is not protected by TPM: Windows Hello: No TPM No Security | ElcomSoft blog. I suspect it still needs physical access to the drive, but unlike other OS’s many windows volume are encrypted by default. This mean you should not use Windows Hello if you don’t have a TPM. I don’t think there is even an option to enter master password on startup if Windows Hello is used. Other password managers like Enpass actually do not allow you to bypass master password if you don’t have a TPM.
Based on this,
If I have a Windows machine, I would not use Window Hello unless there is TPM and stick with enter master password on restart. On machine with TPM, may be.
On android and IOS , biometric login seems to work well enough.
On chromeOS, you are stuck with the chrome extension, which uss PIN login. This should also be set to reenter masterpassword on startup.
However, I have elderly users who do not quite know how to type in a long master password. Even if they are show the password, they cannot type it in. I do not understand why. The most likely cause is that they are bad typers. I have been able to get around this by typing the password for them on their android devices and then enabling biometric login. Unlike Windows, I think most recent android devices have an equivalent to TPM.
On their Chrome OS devices, they don’t allow fingerprint access to applications. I am left with 2 options. I can select never logout or PIN unlock but without reentering master password on restart. I am probably going to stick with the PIN unlock. This is because Chrome OS devices are encrypted by default, so you can’t just take out the hard drive and read it.
The device login is a good idea and wasn’t available previously Will try it out and see if the user can adapt. The option is a bit tricky to setup. Thanks.
The vault timeout is set to browser restart, though other time is possible.
The vault timeout action must be set to logout or you won’t have the option to login when it timesout.
On the mobile client, approve login request must be set to on.
It worked pretty well. The biggest issue is that the mobile client must be running. I am not sure I can educate the user to keep the mobile client running.
Security-wise if the vault is open and unlock, does it mean other processes can read the vault? Just wondering about the timeout settings and its effect. On system with biometric, I actually set the system lock immediately and they must use the biometric to even fill.