By my understanding, the when I ‘log out’, BW purges all data from memory (and disk?). To login again, I need access to the server to sync the vault. Depending on my configuration, the server will request 2FA.
When I ‘lock’ the vault, the client encrypts the local database, but keeps the decryption key in plaintext in memory. When I present the correct password (or PIN, or fingerprint), it decrypts the database.
Am I correct in that the decryption key itself is not derived from the PIN or fingerprint or password, but the client merely uses them for authentification of the user? At least the documentation suggests so.
This feels unecessary. A memory dump of BW will expose the encrypted database along with the key. The encryption is an obfuscation at best.
Why not encrypt the key as well, so that the PIN or whatever is properly necessary to get access?
I imagine on modern devices one can leverage a TPM or at least some OS service to safely store the key, and only hand it out if we present the correct credentials.
(If this is indeed what BW does already, consider this instead a request to update the documentation )
Hey @polwel , Welcome to the Bitwarden community forums !
According to what i can understand from the documentation and confirm from my usage , the PIN is only stored in the Memory as long as the BW app/browser is running.
And it is never written to the storage unless you chose to opt for storing it.
Some people ask for the ability to unlock the vault with a PIN even if its a new session(i.e on restart of app/browser), so for them they could uncheck the pre-checked field" Lock with master password on restart on setting a PIN.
You can find the above in pt 4 of the help article here -
Also don’t think taking memory dump is an easy task to do without the knowledge of the user.
There are mitigations for such an attack too and mostly rely on OS level implementation for it.
As for the fingerprint security ,it is also dependent upon OS level implementation like TPM etc. But i don’t think its fair to expect from them to explain how each OS implements its security for protecting the user fingerprint/biometric data. We can probably look on the respective OS documentation for learning how they secure it.
Cheers
Yeah, sure, a memory dump is a rather sophisticated attack. I was just wondering what could be the benefit of encrypting the database but storing it alongside the key. Clearly it does not protect from an attacker who can read arbitrary memory. So either I am not seeing the threat model, or BW does indeed encrypt the key separately.
In any case, I am struggling to understand how the browser restart is related to this. I can configure BW to only lock (rather than log out) on browser shutdown. If BW can securely derive the decryption key from the PIN, how does it matter if the browser was closed?
But i don’t think its fair to expect from them to explain how each OS implements its security for protecting the user fingerprint/biometric data.
Agreed. In essence, all I wanted to know is whether or not the PIN or fingerprint is actually to decrypt the vault, or if Bitwarden essentially just blocks the UI until the user has provided the proper credentials. I don’t care how the OS authenticates fingerprints in detail.
The reason why I brought up the TPM is that it can enforce rate limiting. If the key was otherwise derived from the PIN, an attacker could conceivably just brute-force it. I just assume the OS does the best it can on that front (use a TPM if available).
On locking the vault manually or on browser shutdown (not logging out) , the decryption key is purged from memory.
I am not sure what u mean my “storing” the key.
Storing here only means in the RAM.
So after purging the RAM , there would be no traces of the decryption key.
You’ll need to again enter the master password on browser/App restart to decrypt the vault and then after that the you’ll get to enter pin to unlock it until the application remains in the memory.
So then your question will again lead to someone dumping the memory. If you feel someone is able to dump your personal devices memory then it would mean that your device somehow got compromised, so now you’ll anyway have many more threats to lookout for other than dumping memory as mentioned by the article here Bitwarden Security Whitepaper | Bitwarden Help & Support
To my knowledge , fingerprint doesn’t decrypt the vault , the Bitwarden decryption keys are stored in the TPM or any other trusted module the OS implements. The fingerprint is a method through which the OS authenticates the user , and on successful authentication it presents the decryption key to the Bitwarden app. Where does the OS store and protect the key would depend upon how well its managing its fingerprint service.
Unfortunately i won’t be able to answer you beyond that. Maybe you can contact the BW support if you still have concerns about it.
Cheers
It’s what I imagined BW to work like, but I was confused by the docs saying that ‘[before unlocking the] decryption key [is] stored in memory’. This sounded like it was held in memory unencrypted, which sounded like a terrible idea.
Thanks for pointing me to the white paper again. I had read it before, but I must have overlooked the critical section:
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.
…except that this claim is not accurate, unfortunately. Unencrypted secrets, keys — and even the plaintext master password — remain in memory after locking the app, and even after logging out. The memory is only purged when the app process is terminated (and this is true whether the vault is unlocked, locked, or logged out).
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.
@bw-admin This sounds great, but in my experience, the attempts by the Bitwarden client app to purge memory are not successful. Perhaps there may have been an inadvertent regression of the code after the quoted safety measures were implemented?
Thanks for following up. Go ahead and create an issue on Github and I’ll include that link with the feedback for investigation For now, the quotes above indicate expected behaviour.
@bw-admin The expected behavior unfortunately does not match the actual behavior. This as now been documented on Github as Issue #3166. If you can bring this issue to the attention of the devs, that would be great.
I also encourage any interested Bitwarden users to try it out on their own installations. The easy-to-use HxD memory inspector is available to download as freeware, and detailed step-by-step instructions are available in the Github bug report that was just posted.
)
For now, the quotes above indicate expected behaviour.