Accessing the risk of PIN login

Let’s say you use a PIN login, but disables the option “Lock with master password on browser restart”. What are the risk exactly?

If you disable lock with master password on browser start, I am assuming that the pin is stored in the vault. If someone gains access to the file system, they can then copy the vault and attack it by bruteforcing the PIN. This would not be an issue if you did not disable “lock with master password on browser start up”

On windows, the file system is not always encrypted. This mean someone could use a Linux USB key to boot off and copy the file off your file system. Even if the file system is encrypted, anyone malware that gain access to the file system would be able to acquire a copy of the vault. This would be less of an issue if Bitwarden uses TPM, but a scan of the documentation does not indicate that Bitwarden does use TPM.

Other than enabling lock with master password on restart, is there other forms of mitigation? On system with biometrics, it would be more secure to use fingerprint and face id because I assume that the key would get store in the secure enclave protected by the biometrics. What about Windows system that does not store TPM, is there a security risk there?

What about the risk on a chromeOS device? PIN would be stored on disk, but since the storage is encrypted, you would need to have the google account credentials to copy it. However, chromeOS malware who gain account access would be able to access the file?

What do you think? I like to not have the user enter the master password because this particular user is not great at typing in password, so I was attempting to evaluate the risk of retaining the pin option would be.

The pin is a trade-off between convenience and security. Usually your device is less of a target than the bitwarden servers are. Thus, it can be a reasonable trade-off to have it “less encrypted” (with a lower entropy key).

That being said, if your file system is not encrypted, and you do not trust the physical security of your device against a capable threat actor, DO NOT USE A PIN . It will keep your nosey but tech-illiterate roommate out of your vault, but it can be cracked by an attacker with readily available tools (hashcat, john).

It can be improved by raising iterations / using argon2, but even with argon2 it is possible to crack in (reasonable) time.

If you disable lock with master password on browser start, I am assuming that the pin is stored in the vault.

An encryption key gets derived from the pin and your email, the same way your master password is used to derive the encryption key. Your actual vault key gets encrypted using this derived encryption key and stored to disk.

it would be more secure to use fingerprint and face id because I assume that the key would get store in the secure enclave protected by the biometrics.

I don’t know whether this works on iOS or android, but on windows and mac, as far as I read the code, the key gets stored in the OS’ keychain with the Bitwarden app being able to access them at any time. Biometrics only returns a true/false result. I.e it does not directly unlock the keys and thus does not give any cryptographic security. This can thus be circumvented to get the key without involving biometrics. It is again a trade-off between security and convenience. [I have only studied this briefly to do a linux implementation]

What do you think? I like to not have the user enter the master password because this particular user is not great at typing in password, so I was attempting to evaluate the risk of retaining the pin option would be.

How great do you consider the risk of an attacker actually stealing your physical device, extracting your Bitwarden vault and running cracking software against it. Unless you are a high value target, this is rather unlikely, so the trade-off might be worth it to you.

Interestingly, this is exactly analogous to the risk-benefit analysis that users of 1Password would/should do when deciding on the complexity of their vault password. In Bitwarden, the cloud vault is protected by a strong master password, but the local vault cache may optionally be secured using a weaker password/PIN instead (assuming that device security is good, and the probability of a targeted attack low). In 1Password, the cloud vault is protected by a strong secret key, but the local vault cache is instead secured by a weaker vault password. It seems that many Bitwarden users feel comfortable using a relatively weak password/PIN for local vault protection, and that many 1Password users feel comfortable using a relatively weak vault password for local vault protection.

Can we estimate a lower bound for an appropriate entropy for the local password (Bitwarden PIN or 1Password vault password)? Maybe, if we assume that a determined attacked has the resources to breach either your local device or the cloud servers — in that case, the risk of vault theft will be approximately equal to the probability of attack, which should be approximately proportional to the perceived value of the stolen data. For example, if Bitwarden has around 1 million vaults stored in their data base (it was around a 100,000 in 2018), and if we assume that the average value of the cloud hosted vaults is around 10× greater than the value of your locally stored vault (taking into account that the mean value tends to be skewed by a few outliers in the population), then the probability of a targeted attack against your device is approximately one-millionth the probability of an attack targeting the Bitwarden cloud servers. Thus, a rational basis for determining the required PIN entropy for a Bitwarden user’s PIN would be to make it 20 bits lower than the master password entropy (because, 220 ≈ 1 million).

I typically recommend for Bitwarden users who are not high-value targets to use a master password with an entropy no lower than 50 bits, which implies that a PIN entropy of around 30 bits should be reasonable. This is achievable using a 9-digit numeric code (if chosen at random).

Thank you both.
I agree that it should be looked at in terms of vault security and device security. I don’t know how 1passwords works, I think it is very important to secure the cloud vault with a really strong master password with 2FA because it’s expose to attack on the web.

For the devices

  • Android phone is secure by a fingerprint and it also prompts for a pin every couple of days. Assuming that the phone is lost in a locked state, the attacker will most likely exploit the attack by attempting to break using the pin. I haven’t tested what happens if someone tries to bruteforce the pin. My impression is that you would be forced to enter the password if you fail x number of times, but I am not sure. Early edition of Android OS could be hacked via usb, but I believe the most recent version require the entry of the pin Just to be on the safe side, the android pin and bitwarden pin are not the same.

  • For the Chrome device, it’s a actually a desktop box, so access is depend on the theft of the device which would require them to break into the home. Because it’s a chrome OS device, the storage is encrypted. If someone attempt to brute force the pin, it reverts to password after a few tries.

I now think that the current scheme of strong password and a pin on the desktop and fingerprint on the phone is probably good enough. I would probably increase the pin as suggested. One possible increase would be to make the user enter the master password on startup, however this might result in a reduction in security. Currently the user has the password locked up. If they have to enter this regularly, they will end up writing it down and post noting it on the monitor.

I would quibble with that piece. It’s not just the value of the data but the difficulty in accessing the data. Bit Warden servers have state of the art hardware and software protection managed by professionals. Home users may have old routers that haven’t been updated in years and various security vulnerabilities created by poor practices or knowledge gaps of the computer owner. The home user’s computer is likely way easier to target even if the payback isn’t as high.

@bw-tinkerer My analysis was based on the following premise: