I don’t know if anyone have seen this article but food for thought.
Feel free to ask to change the name of the feature.
Techspot wrote a similar article that can be found here. I’d like to know if BitWarden is vulnerable to this possible issue.
I have seen the data stream that BitWarden passes from the server to the client, it’s a really long JSON data string and from what it looks like each individual entry is encrypted; not as a single blob. The way I look at it is that this is done so that all data is stored in memory in encrypted form and only until a piece of data is required is it decrypted. This is good, very good. However, this still leaves the data clean-up routines where when something is decrypted is it cleaned up off the memory stack when it’s no longer needed? That is the question.
I believe your linked article is a summary of this White Paper, and that white paper mainly speaks to the password manager in a locked state.
Kyle has responded on Reddit with:
“Bitwarden clears encryption keys and cached data from memory when the application enters a locked state.”
Ooow thanks for the clarification.
Did miss that.
But we still miss a good lock state with pin or yubikey implementation to be fast enough to not renter our password then.
Wiping memory when in a Running: Locked State isn’t the only criteria with which they were concerned…
Password Manager Security Guarantees:
All password managers studied work in the same basic way. Users enter or generate passwords in the software and add any pertinent metadata (e.g., answers to security questions, and the site the password goes to). This information is encrypted and then decrypted only when it is needed for display, for passing to a browser add-on that fills the password into a website, or for copying to the clipboard for use.
Throughout this paper we will refer to password managers in three states of existence: not running, unlocked (and running), and locked (and running; this state assumes the password manager was previously unlocked). We assume that the user does not have additional layers of encryption such as full disk encryption or per process virtualization. We define the three states below:
Not Running
We define “not running” as a state where the password manager has previously been installed, configured, and interacted with by the user to store secrets, but has not been launched since the last reboot or has been terminated by the user since it was last used.
In this “not running” state the password manager should guarantee:
- There should be no data stored on disk that would offer an attacker leverage toward compromising the database stored on disk (e.g. the master password or encryption key stored in a configuration file).
- Even if an attacker retrieves the password database from disk, it should be encrypted in such a way that an attacker cannot decrypt it without knowing the master password.
- The encryption should be designed in such a way that, so long as the user did not use a trivial password, the attacker cannot brute force guess the master password in a reasonable amount of time using commonly available computing resources.
Running: Unlocked State
We define running in an “unlocked state” as cases where the password manager is running, and where the user has typed in the master password in order to decrypt and access the stored passwords inside the manager. The user may have displayed, copied to clipboard, or otherwise accessed some of the passwords in the password manager.
In this “running, unlocked state” the password manager should guarantee:
- It should not be possible to extract the master password from memory, either directly or in any form that allows the original master password to be recovered.
- For those stored passwords that have not been displayed/copied/accessed by the user since the password manager was unlocked, it should not be possible to extract those unencrypted passwords from memory.
Knowing usability constraints that affect password managers, we concede that:
- It may be possible to extract those passwords from memory that were displayed/copied/accessed in the current unlocked session.
- It may be possible to extract cryptographic information derived from the master password sufficient to decrypt other stored passwords, but not the master password itself.
Running: Locked State
We define “in locked state” as cases where (1) the password manager was just launched but the user has not entered the master password yet, or (2) the user previously entered the master password and used the password manager, but subsequently clicked the ‘Lock’ or ‘Log Out’ button.
In this “running, locked state” the password manager should guarantee:
- All the security guarantees of a not-running password manager should apply to a password manager that is in the locked state.
Since a locked password manager still exists as a process in virtual memory, this requires additional guarantees:
- It should not be possible to extract the master password from memory, either directly or in any form that allows the original master password to be recovered.
- It should not be possible to extract from memory any cryptographic information derived from the master password that might allow passwords to be decrypted without knowing the master password.
- It should not be possible to extract any unencrypted passwords from memory that are stored in the password manager.
In addition to these explicit security guarantees, we expect password managers to incorporate additional hardening measures where possible, and to have these hardening measures enabled by default. For example, password managers should attempt to block software keystroke loggers from accessing the master password as it is typed, attempt to limit the exposure of unencrypted passwords left on the clipboard, and take reasonable steps to detect and block modification or patching of the password manager and its supporting libraries that might expose passwords.
Additionally, they highlight one thing in the design of 1password in relation to how much the newer implementation leaks compared to the stricter controls in the older version.
After assessing the legacy 1Password4, we moved on to 1Password7, the current release. Surprisingly, we found that it is less secure in the running state compared to 1Password4. 1Password7 decrypted all individual passwords in our test database as soon as it is unlocked and caches them in memory, unlike 1Password4 which kept only one entry at a time in memory. Compounding this, we found that 1Password7 scrubs neither the individual passwords, the master password, nor the secret key (an extra field introduced in 1Password6 that combines with the master password to derive the encryption key) from memory when transitioning from unlocked to locked. This renders the “lock” button ineffective; from the security standpoint, after unlocking and using 1Password7, the user must exit the software entirely in order to clear sensitive information from memory as locking should.
It appears 1Password may have rewritten their software to produce 1Password7 without implementing secure memory management and secrets scrubbing workflows present in 1Password4 and abandoning the distinction between a ‘running unlocked’ and ‘running locked’ state in terms of secrets exposure.