Bitwarden PINs can be brute-forced

6 minute read

Published: 2023-02-28

The Bitwarden desktop client and browser extensions allow the user to unlock Bitwarden with a PIN. This PIN can be set-up per device after logging in to an account using the master password. All information pertaining to the PIN is stored locally on the device. It cannot be used to sign in to an account (read: authenticate with the Bitwarden backend server), but it can be used to obtain access to the vault data, that has been synced and stored locally in encrypted form.

Let's now assume that the user enables the PIN unlock and configures Bitwarden so that it doesn't require the master password on restart.

Then a secret derived only from the user's email and PIN will be used to encrypt the master vault key. It stores roughly

c=EncryptK(email,PIN)(master key)c = \mathrm{Encrypt}_{\mathcal{K}(\mathrm{email},\ \mathrm{PIN})}(\text{master key})c=EncryptK(email, PIN)​(master key)

on disk, where K\mathcal{K}K is a key derivation function. This means if an attacker can at any point gain access to the encrypted vault data stored on the device the attacker can brute-force the PIN: the attacker can check whether decryption of ccc succeeds using the guessed PIN. This brute-force will very likely be successful, since PINs are usually very low-entropy. Now, granted, the key derivation function is PBKDF2 with 100000 iterations (+ HKDF), but that won't help with a 4 digit pin.

Bitwarden seems to be aware that PINs are low-entropy and that many PIN guesses are a problem: the client allows only 5 PIN unlock attempts. However this 5 guesses limit is enforced completely within the client's logic: it relies on the attacker using the official Bitwarden client. Instead, an attacker can directly attack the ciphertext ccc above, trying different PINs until the ciphertext successfully decrypts.

Exploitation

A proof of concept exploit for Linux only can be found here. It uses the fact that the encryption is authenticated and checks whether the MAC verifies using the key derived from the guessed PIN. It only tests the PINs 0000 through 9999, so you will have to use one of those if you want it to succeed. Make sure to uncheck the "Lock with master password on restart" option (otherwise the required information would need to be read from the Bitwarden application's memory (quite a different attack scenario)).

It finds any 4 digit PIN in less than 4 seconds:

$ time ./target/release/bitwarden-pin
Testing 4 digit pins from 0000 to 9999
Pin found: 9999
./bitwarden-pin  81.73s user 0.03s system 2384% cpu 3.429 total

Bitwarden's response

I've reported the issue to Bitwarden previously, however it was marked out of scope as it belongs to one of these categories:

Attacks requiring physical access to a user's device

Scenarios that are extremely complex, difficult or unlikely when utilizing already compromised administrative accounts, self-hosted server, networks or physical devices which would render much easier and alternate means of compromising the data contained within Bitwarden

This is however not entirely true: only the device-local encrypted vault data needs to be accessed. If accessing device-local data is outside of the threat model, why are we encrypting these data at all? We might as well store them in plain text.

Mitigation and Remediation

1. Inform better about the risk

The risk of this attack is relatively low (depending on your threat model): the attacker needs to gain access to the encrypted vault data stored on the device, and the user must configure Bitwarden in a specific way for the attack to be possible. Dumpster diving could give access to these data when the disk has not been erased and no additional measures like full-disk encryption were taken. However, if someone gains access to the device data (e.g. through coercion) they can start a brute-force attack, and don't require you to ever enter the PIN/trust the device.

Advantages:

• Nothing to implement

Disadvantage:

• PIN is brute-forceable when device data is obtained

2. Rely on a third-party to enforce an unlock attempt limit

Secret-share the master key with a backend that enforces an unlock attempt limit.

Advantages:

• Easy to implement

Disadvantages:

• Client needs to be online
• Access to the backend database and device allows immediate decryption (without a brute-force attack), the backend may also be coerced into releasing the ciphertext

3. Rely on some hardware security magic

Do the above (no. 2) in a Trusted Execution Environment, Intel SGX or something alike.

Advantages:

• Would likely work offline

Disadvantages:

• Not all platforms support hardware security magic

Final Words

Using a long passphrase as a PIN in bitwarden is safe today. However, Bitwarden takes little effort in communicating the risks of choosing a short low-entropy PIN. Currently there is very little information to be found about the PIN in Bitwarden documentation, and it is not mentioned in the Security Whitepaper. A motivated attacker (e.g. a dumpster diver) can recover entire Bitwarden vaults today, unless additional measures like full-disk encryption were taken.

Sources