Questionable PIN Security

Preface: I am a long time user of KeePass with multiple plugins and also used Myki before it was announced they were shutting down. I liked the automated features in Myki and have migrated over to Bitwarden, paying for premium. Really missing Auto-Type and hoping that will be coming soon!

Anyway, on to the reason I’m posting… I’m a bit concerned about the PIN security implementation and am keen to hear other thoughts…

I have “Unlock with PIN” enabled to avoid entering my obscenely long master password every time. I assumed there was some kind of unique ID specific to my device that was used in conjunction with my PIN making it unique to my device. Therefore, if the data file was ever taken elsewhere, the full password would be required to unlock.

However, with the vault locked, I copied the %AppData%\Bitwarden\data.json file and placed it on to another computer where I installed Bitwarden app offline and restored the file to the same location (internet disabled), only to find the same PIN unlocked the database as it did on the original PC with no need to enter the full master password.

This means if my original PC was ever infiltrated, either by Ransomware or over the network, that file can be copied off and hacked into within mere seconds.

I was always under the impression the PIN Unlock was unique to the PC it was applied to, but it doesn’t seem to be the case.

I would be keen to understand whether I’m over thinking this or is this some kind of oversight in the security of the app? Are extensions affected in the same way?

4 Likes

Hi @Jmac, the Unlock with PIN page in the help Center provides additional information on this feature:

Note

If you turn off the Lock with master password on restart option, the Bitwarden application may not fully purge sensitive data from application memory when entering a locked state. If you are concerned about your device’s local memory being compromised, you should keep the Lock with master password on restart option turned on.

Would it not be better to implement PIN security in conjunction with some kind of unique identifier of the system to ensure it can only be unlocked on the device it was applied to?

After ensuring the “Lock with master password on restart” option is enabled in the PIN unlock settings, I’m now asked for the Master Password when copying the file to a different computer.

I think this will have to be the acceptable middle ground for now.

Perhaps using some kind of unique parameter of the system, in conjunction with the PIN would provide the security needed to allow this in the future.

1 Like

Slightly varying the thread but it might apply and help you. I have debated this same issue in the past (within my own mind) and the method I use to allow me to have peace over this is:

I use BW on linux LUKS encrypted drives. When I am absent and the machines are off there is NO access to anything and in this case specifically BW! There can be no copying at all.

The issue you sight is common to all software encryption in that a “bad guy” that has pawned your machine will always have control over the drive’s content.

All the above said I REALLY like the concept of a PIN that uses device specific “qualities” as a sort of second factor authentication to allow access. In fact it is a major improvement in security if that feature is feasible I would thumbs up a vote for it. Great idea!!

+1. This sounds like a reasonable improvement.

I think the whole documentation regarding Unlock with PIN and Understanding Unlock vs. Log In should be clarified. The following paragraphs are the relevant information I found in the help center and the white paper. IMO it’s contradictory and the behavior described by @Jmac is not covered either.

Enable Unlock with PIN
If you turn off the Lock with master password on restart option, the Bitwarden application may not fully purge sensitive data from application memory when entering a locked state. If you are concerned about your device’s local memory being compromised, you should keep the Lock with master password on restart option turned on.

Understanding Unlock vs. Log In
Unlocking can only be done when you’re already logged in. In other words, only when your Vault data is already stored (encrypted) on your device. Because your Vault is already downloaded and your decryption key stored in memory:

  1. You don’t need the decryption key derived from your Master Password, so you’re free to use other access methods, like PIN codes and biometrics.

You don’t need to be connected to the internet (or, if you’re self-hosting, connected to the server).

White Paper
We do not keep the Master Password stored locally or in memory on the Bitwarden Client. Your encryption key (Symmetric Key) is kept in memory while the app is unlocked. This is needed to decrypt data in your vault. When the vault is locked, this data is purged from memory.

I could imagine that this description of the locked state is misleading, as the memory is normally purged in the normal locked state (as described in the White Paper). Therefore, the Master Password is not only needed for the login process but also for unlocking the vault as the decryption key isn’t stored in memory. If I’m not mistaken, there are probably two different locked states, and maybe this should be pointed out here, the normal locked state (as described in the White Paper) and a PIN lock or less secure locked state. In the latter the decryption key has to be kept in memory as unlocking the vault doesn’t involve the master password, which would be needed to decrypt the symmetric key from the file system and load it to memory.

As far as I understand it, there are rather three different states involved if “Unlock with PIN” is used:

  1. Login with Master Password: Authentication process (including 2FA) to receive encrypted data from server (Fallback after 5 failed PIN attempts)
  2. Unlocking (from normal locked state) with Master Password: All data has been purged from memory (Fallback from PIN lock after app restart if Lock with master password on restart option is used, the default setting)
  3. Unlocking (from less secure state) with PIN: encryption key is kept in memory even though the vault is locked
    • Lock with master password on restart on: encryption key is kept in memory when entering PIN lock
    • Lock with master password on restart off: encryption key is kept in memory and written to disk (the behavior @Jmac discovered when he transferred the local file to a different offline system)

Do you agree with this structure?
The white paper says that “Your encryption key (symmetric key) is kept in memory while the app is unlocked”. Do you know if the encryption key (symmetric key) is also kept in memory in the locked state (PIN lock) or if the PIN is used to encrypt the symmetric key when entering the locked state to then keep the encrypted symmetric key in memory or to write it to disk?

3 Likes

I have been trying to replicate this behaviour with no success. I am always required to enter my master password to access my vault, regardless of whether I have copied the data.json file into the %AppData%\Bitwarden folder or not. Has anyone been able to achieve this, and if so, can you provide step-by-step instructions to make this work? I am now wondering if this is even possible and whether all the “what-if” scenarios in this thread are valid.

@dh024 Yes, @Jmac is right: I can reproduce this for a desktop vault that has been PIN-locked after disabling the option Lock with master password on restart. In my case, I assumed the attacker was using a portable desktop installation – e.g., with D:\Bitwarden-Portable-2022.6.2.exe installed on a USB (D:). On the victim computer, navigate to %AppData%\Bitwarden and copy the data.json file to the USB at D:\bitwarden-appdata\data.json. If the computer is locked or powered off, use a recovery environment on a bootable USB to access the file. The copied vault can still be unlocked using the PIN, from any computer.

Thus, the attacker can take the USB to any other computer, and try to crack the PIN at their leisure. If doing this manually (by trying the obvious 1111, 1234, birthdates, etc.), you can get an unlimited number of unlock attempts simply by closing and restarting the app after each fourth attempt. There may be a hash stored in the data.json file that would make a more automated cracking attempt possible, but I have not explored this yet.

@rpaulson If you are worried about a memory attack, then you are going to be disappointed. Despite what is said in the Bitwarden documentation and whitepaper, whether the vault is unlocked, locked, or logged out, the actual master password is stored in unencrypted plaintext in memory until you shut down the app process completely!

Thanks @grb, the team will be investigating the Github issue. For context, below outlines expected behaviour:

On your Local Machine

Data that is stored on your computer/device is encrypted and only decrypted when you unlock your Vault. Decrypted data is stored in memory only and is never written to persistent storage.

We also reload the application’s renderer process after 10 seconds of inactivity on the lock screen to make sure any managed memory addresses which have not yet been garbage collected are purged. We do our best to ensure that any data that may be in memory for the application to function is only held in memory for as long as you need it and that memory is cleaned up whenever the application is locked. We consider the application’s encrypted data to be completely safe while the application is in a locked state.

Thanks for escalating this. To clarify for other readers, the “Github issue” mentioned by dwbit refers to an issue different from the two raised in my post above — the referenced issue is related to the failure of the Chrome extension to purge the local vault when logging out, and is documented here:

I will return in the near future with documentation of the claimed memory vulnerabilities (a preview of which I’ve shared with dwbit in Direct Message).

@bw-admin I agree that the expected behavior is as described in the documentation cited above. Unfortunately, the actual behavior is different. The failure to purge the clear-text master password and decrypted vault information from memory after locking and/or logging out (even after 4 hours of inactivity) has now been documented on Github:

This memory vulnerability is distinct from the Chrome extension issue mentioned above (Github Issue #3124), and is also distinct from the issue raised by @Jmac in the OP of this thread (which I have reproduced in my post above).

I hope that some of these vulnerabilities will be addressed in the near future.

@grb this claim is with the team to investigate :+1:

1 Like

@bw-admin Just so there is no misunderstanding: You had previously indicated that you notified the team of Github Issue #3124. I had promised (in my previous post) to document a different issue (sensitive information not purged from memory), and I have now done so — as Github Issue #3166. Therefore, I posted here again, to close the loop. I hope that both issues will be brought to the attention of the devs. In addition, the entirely separate (third) issue described by @Jmac in the OP of this thread is also worthy of discussion and mitigation.

Rest assured, all information has been passed along to the team for review.

3 Likes

As an aside to this discussion: Yes, it would be nice if mobile apps had the same PIN functionality as the Windows PC/MacOS apps/extensions. I’d use alphanumeric in my 6-digit PIN, but as I have 4 devices its not that practical as 2 are iOS - so I don’t believe I can do alpha-numeric there (is this an iOS/Android constraint or just a BW app one?). I am looking to have different PINs for each device, just haven’t implemented it yet as still getting BW bedded down - and my BW knowledge up (as I migrate from 1PW) and would prefer to have consistent numeric only or alpha-numeric for all.

Possibly an argument in favour of a universal sync’d PIN across all devices by vault - or does this potentially introduce a weakness that partially recreates something similar to @Jmac’s OP issue, since same PIN would work on multiple devices?

P.S. Was there any outcome of the investigation? Correct or Incorrect behaviour as reported by @grb? Bug, Known/Not Known or Intentional? If bug or unintentional any fix?

This thread discusses/mentions three separate issues. The first is the behavior reported by @Jmac, which is really a feature request and not a bug. The second and third are bugs that have been reported on Github. You can follow the links to the corresponding bug reports (#3124 and #3166) to check the current status. Both of these are still open issues, but some partial fixes have been released to address #3166. I have not had time to do further investigations into these issues since I posted the above information in July, but the bug reports on Github contain detailed instructions for how to reproduce these two bugs — thus, feel free to do some testing on your own and report back here.

Cheers - and yes was referring mainly to your items and sorry my bad - was aware of the GitHub entries for them and didn’t think to review any updates there! :roll_eyes: I’d vote for the unique identifier appended to PIN @Jmac suggested - but isn’t that already present (was sure I read another thread that talked about it)?

What you probably remember seeing it this request, which is different. That request involves storing a user-specific code on the user’s devices, and using that code in combination with the master password to decrypt the vault. Even if you extend that request to include also PIN-lock use cases, that approach would not help if somebody steals the PIN-locked vault from one of your devices, (because the same attacker would also be able to steal the code that is stored on the same device).