Current password manager implementations, including Bitwarden, decrypt entire vaults into system memory, creating significant attack surfaces. Independent Security Evaluators’ 2019 research found that all tested password managers failed to provide advertised memory security, with vault contents remaining accessible through memory forensics even in “locked” states.
Modern malware like Raccoon Stealer and RedLine Stealer now specifically target password managers through memory injection techniques, making complete vault exposure a practical security risk.
Academic research shows selective decryption reduces compromise blast radius while maintaining usability
Implementation Considerations
Vault Format Changes: Separate metadata from payload data in vault structure Search Optimization: Implement encrypted search or expand metadata fields as needed Cross-Platform: Ensure consistent behavior across desktop, mobile, and browser extensions
This enhancement would significantly reduce the impact of memory-based attacks while maintaining Bitwarden’s core functionality and user experience.
Not to take away from your proposal, but some of the background information that you have provided is misleading:
To be clear, the 2019 ISE study did not include Bitwarden in any of their tests (and my understanding is that it would have passed the tests if included at the time).
Furthermore, Bitwarden significantly improved its memory security in 2022. In the locked state, there should be no sensitive information in the process memory used by Bitwarden clients.
Thus, your feature request is only relevant to unlocked vaults.
Good point, I’ll update the post. There are still open Github issues where unencrypted info including master key is available after locking a vault.
Edit: I can’t edit the OP
But even if the above weren’t true and Bitwarden was perfectly removing unencrypted data or key artifacts from memory the instant the vault was locked, we are unlocking our vaults multiple times per day. And if we aren’t using biometric or secure element avenues to unlock, we’re also typing in a master password or pin multiple times per day (putting us further at risk of keylogging).
In a perfect world, and the subject of another feature request I made today, all key material would remain on a hardware security module and all encryption and decryption would happen on the device.
But I hope this feature request is clear enough, happy to discuss the merits of “least privilege decryption” or whatever you’d call this.
Thank you. Please note that Issue #6231 pertains to clients with unlocked vaults, not locked vaults as claimed. Issue #1516 is specific to the Firefox browser extension, and is a Mozilla issue, as explained here.
I was just making sure that the record is clarified on existing memory vulnerabilities in Bitwarden: the client process memory is always purged of all sensitive data on locking of the vault (or logging out), except that in the Firefox browser extension, the memory cleanup can be delayed, unless the browser itself is closed.
As far as your feature request, it appears to me that you are essentially proposing a “semi-locked” state as a fourth vault state (in addition to logged out, locked, and unlocked). Some users might be unhappy about the complete loss of search functionality for Notes and custom fields, though…
Bitwarden is in the process of going this route, as well. However, the individual encryption keys for each vault entry must still be available in memory for decryption to work, so this will not protect against an attack that exfiltrates a memory dump.
My understanding is that the fact that Bitwarden’s code base is primarily TypeScript and C# presents technical hurdles to leveraging some of the memory hardening techniques deployed by KeePassXC (which is written in C++). Past Github discussions (including the ones linked above) have revealed that browser extension processes in particular have little to no control over the timing of garbage collection (thus, “immediate memory clearing after use” may not be possible to implement).
Yes, it’s hard to have low-level memory control when using any interpreted or bytecode style translator.
I think your assessment is right, that it would reflect a new state. I personally am more than happy to forego the ability to search the truly sensitive content for the feature of “just in time decryption” or whatever this might be called. I don’t typically search more than the metadata. I also wonder if there are esoteric cryptographic ways to search the encrypted data, but that’s probably outside the scope.
I just want to start the conversation about the merits of this idea. Keeping the vault completely unencrypted in memory has been bothering me for awhile, so this is my first, perhaps naive, attempt at starting a discussion about it.
My understanding is that the fact that Bitwarden’s code base is primarily TypeScript and C# presents technical hurdles to leveraging some of the memory hardening techniques deployed by KeePassXC (which is written in C++).
The crypto and domain logic is being moved to a Rust based SDK currently, and this has some memory protections (zeroizie on drop), with more (memory dump prevention) at least having drafted changes. The former is be available on all platforms once the SDK is used consistently, the latter only on platforms where the SDK is run natively (i.e not web).
However, the UI on non-mobile clients of course runs in typescript/angular, which is hard to reason about. However, when you lock, a process reload wipes out the renderer process and should clear all memory held by it.
On desktop specifically there are other mechanisms available, that allow at least protecting the main process, but not the renderer process (these are electron terms). For instance, on Linux, there is experimental support via en environment variable for PR_SET_DUMPABLE, that prevents debuggers from attaching, or userland / root from dumping the process memory.