See:
If you have a good master password it would be difficult to brute force and get the master key.
If you have a good master password and easy PIN, then you can get the master key by brute forcing the PIN.
The PIN can be a great convenience if your local machine is secure, but it definitely reduces the security of your vault if anyone ever gets the locally cached version of your vault.
The location listed in that link is
%LocalAppData%\Google\Chrome\User Data\Default\Local Extension Settings\nngceckbapebfimnlniiiahkandclblb
However, there is no default directory. I am using the chrome extension without the desktop app.
In any case I was curious about the master key storage. One of my relative uses bitwarden but is apparently too tech unsavvy to use a pin. What I did was to setup bitwarden (on chrome os) to never prompt them for a pin. This probably mean the masterpassword key is store somewhere on disk. I was curious how vulnerable this is. In any case, this is still better than what they did before, which was to use the same 5 characters password for all of their accounts.
In any case, if I use a PIN, I could technically be able to generate a hash for each combinatiion. So for a 8 digit pin, that would be 10^8 or 100,000,000.
@RobertT - Thank you for joining this thread and providing some valuable insight.
One thing that is unclear to me is how costly it is to brute-force the PIN: does each guess require AES-256 hashing and 200,001 PBKDF2 iterations (same as would be required for brute-forcing the master password)? Or is the hashing of the PIN not as slow as the hashing of the master password, which would make PIN-based locking even less secure.
Hopefully my question makes sense – apologies if I am butchering some of the cryptography terms, which I am still learning about.
1 Like
According to HiveSystems, it would take 26 seconds to crack a PBKDF2-hased 8-digit numerical PIN using an RTX 3090 GPU.
Grb,
My thought was that you can write a program to call the same routine they are using to generate the hash and do this for all combination. This would result in a list of hash for each number.
A 4 digit pin would be 10^4 or 10x10x10x10 or 10,000 combinations. Still there would be some trick to the hash. May be they salt it with a another value to throw things off.
OK, I think I figured out why I couldn’t find it. The documentation list that the data is at
%LocalAppData%\Google\Chrome\User Data\Default\Local Extension Settings\nngceckbapebfimnlniiiahkandclblb
However, I have multiple profiles for Chrome, so it’s not at Default profile but at the . For example could be “Profile 2”.
%LocalAppData%\Google\Chrome\User Data\<profiile>\Local Extension Settings\nngceckbapebfimnlniiiahkandclblb
Will look at the data next.
A 4 digit numeric PIN can be cracked (worst case, not optimized) on my 7 year old PC (no GPU) in less than 3 minutes.
Don’t ask me how I know.
RobertT,
I found the nngceckbapebfimnlniiiahkandclblb directory, but can’t seemed to find the data.json file. Is it name “data.json”?
data.json is only for the Desktop App, not the Browser Extension.
It has been estimated that GPU-based cracking would provide a speed increase on the order of 200x, and perhaps you would get another order of magnitude improvement by optimizing, reducing the time to crack to a fraction of a second (~0.1 s). However, and 8-digit password would increase the number of required guess by a factor of 104, which would yield an extrapolated projection of 15 min or so for an 8-digit PIN when using better hardware and software for cracking. This is similar to the 17-min estimate obtained by HiveSystems for using a GTX 3090 GPU to crack an 8-digit PIN that had been hashed using bcrypt.
But if you (@RobertT) do know how much time it takes to crack a PIN (and I won’t ask you how you know), then perhaps you also know (or can find out) how the PIN has been encrypted. Does it follow the exact same encryption method that Bitwarden uses to get the Master Password Hash from the master password?
It seems that for the Chrome extension, the data may be stored in files that have names consisting of 6 numerical digits, with file extensions extensions .log and/or .ldb. Alternatively, the 000xxx.log file may just be a log file, but it does contain values for “keyHash”, etc. – and worse, the “keyHash” value is still available when the extension is logged out.
AES-256-CBC, exactly the same as the Protected Symmetric Key.
I’m a bit out of my depth here, so please forgive if my question makes no sense, but…
If the PIN encryption does not use the PBKDF2-SHA256 (and HKDF) algorithms, is it correct to conclude that even with a PIN chosen to be just as strong as the master password, it will be significantly easier to crack the former than the latter?
It does. If your PIN and Master Password are the same then the pinProtectedKey is just as secure.
@RobertT Thanks for the confirmation; that is reassuring. What about the encryption of the local vault when locked – is it just as cryptographically secure as the vault at rest in the Bitwarden cloud? Or are there additional vulnerabilities of a locked vault stored locally on the device?
I’m not sure why it’s reassuring. A weak PIN can still easily be cracked.
It’s reassuring that the only added weakness inherent to using a PIN is if the PIN has less entropy than the Master Password. This provides a rational basis for deciding whether or not to use a PIN, and for deciding how strong the pin must be – one must balance the weakness of a reduced entropy against the added security of measures available to safeguard device access (e.g., limiting physical access and using good internet hygiene and antimalware defenses). So, for example, if I believe that my ability to secure my local device makes the risk of intrusion a million times smaller compared the the cloud-exposed vault, then that suggests my PIN can have an entropy 20 bits lower than the Master Password entropy.
This reasoning assumes that the encryption of the locally stored locked vault is identical to the encryption used for the cloud vault (which hasn’t been confirmed yet).
Based on the information from this thread, I have learn quite a bit. So what I have learn is (most of this info is available on the Bitwarden website).
- Bit Warden never saves unecrypted vault on the local storage or the cloud. The vault is always encrypted at rest.
- All encryption and decryption is done locally on the device using the master password key. Unencrypted data is not sent from and to from the cloud.
- The master password key is derived from your master password.
- When you log into the Bitwarden client, it retrieves the vault from the cloud and uses the master password key to decrypt a copy locally. The copy is stored encrypted locally. In the case of browser extension client, it’s stored in browser local storage.
- The master password key is supposed to be stored in memory. The prevents it from getting copied. However, this also mean you have to reenter it whenever the bitwarden client is killed. For example, I have to re-enter my master password each time I quit my browser and reopen it. There are certain setting that reduces security. For example, if you say you never logout, it stores the masterpasword key locally.
- Once a vault is logged in, it can be locked, which prevents access to the vault locally. During the lock state, a user can use a pin or biometric to unlock. The PIN does not decrypt the vault, but allows you to retrieve the master password key to decrypt.
What is unclear to me is
- Are there instances other than setting bitwarden to never logout where the master password is written to local storage? I would think that if you reboot your machine and you don’t have to re-enter the master password, it must be storing it to disk somewhere, then again it may be that it’s not stored in local storage.
- I believe in some password manager, the master password can be stored in the TPM on windows. I imagine Bitwarden might have similar provision in the desktop client. However, I only use the extension.
To answer Grb’s question based on my limited understanding of what we discussed, encryption is always done at the device using the master password key, so vault data in the cloud and locally would have equal level of encryption and protection. The issue is if the master password is stored in persistent storage.
I am guessing that using the PIN will reduce security, because the PIN is likely to stored in persistent storage (unless it’s stored in something like a TPM), so if you are concern, do not use PIN.
In the event of malware. If infected, you will have no idea what it’s goals are. It may be something harmless written by someone who wants to prove their hacking skills but is otherwise harmless. It may be a ransomware hacker who wants to encrypt your drives for ransom. It may be someone who intend to use your computer as a BOT to attack public infrastructure. You have to assume that your computers on your network may be compromise and erase and reinstall. To protect against data losses, it’s best to have off-line backups that are arranged in a tower of Hanoi configuration. That way you have backup from different time periods so you can go back far enough to a time when there is no infection. You want to store them off-line so that malware can reach them.
While you are at it, backup the vault and store it offline in an encrypted volume in case your vault gets trashed.
Do you have a reference? I’m not so sure about this claim, when it comes to local storage – all of the Bitwarden documentation makes such claims (encryption at rest) only about the vault stored in their cloud. And even if the vault is encrypted locally when locked, there is no documentation I have found that reports what cryptographic methods are used to do the local encryption (as opposed to the cloud encryption methods, which are well-documented), so it may still be crackable.
Furthermore, when the vault is unlocked, it must (by definition), exist somewhere in a decrypted, readable form. Again, there is no definitive source I have found that rules out the possibility that the unlocked/decrypted local vault may be stored on disk. Even if we can confirm that it is only stored in memory when decrypted, [so] isn’t there a risk that it gets written out to a pagefile during memory-intensive operations?
I really wish that Bitwarden would issue another whitepaper or similar documentation that clearly spells out – in one place – the implemented protections and relative vulnerabilities of the vault and its various decryption credentials for each client app (web vault, desktop, portable, mobile), and for each “state” (logged out vs. locked with PIN vs. locked with Master Password, timeout Never vs not Never, enabling vs. disabling “Lock with master password on browser restart”, and any other state variables I may have missed).
For those interested (and for my own future reference), the following webpage describes some attack methods that can be (have been?) used against LastPass – I assume that Bitwarden has similar vulnerabilities: