An important fix for users on Chromium based browsers is now available in version 1.24 of the bitwarden browser extension. You should update as soon as possible to resolve the problem. Version 1.24 has been published and is available in all stores.
If you believe that a device that had the bitwarden Chrome extension was infected with malware or has been stolen and was unprotected at the time you may have been affected by this issue. Otherwise there is no evidence to support a potential compromise of your data. We are not recommending that users change their master password or the passwords of their stored logins at this time.
How do I fix it?
Install version 1.24.2 or greater from the Chrome Web Store. You can get it at https://chrome.google.com/webstore/detail/bitwarden-free-password-m/nngceckbapebfimnlniiiahkandclblb . Most users will get this update automatically and requires no action.
Confirm that you are using version 1.24.2 or greater. Open the bitwarden extension and navigate to Settings → About.
What was the problem, and who may have been affected?
The issue occurs when a user is using the “Never” lock option, which results in your vault’s encryption key (a salted and hashed version of your master password) being persisted to the host machine’s disk (using the chrome.storage API). Since this was the default lock option prior to version 1.24 this occurred at least once for all users upon the first time logging into the extension.
When switching your lock option to something other than “Never” this key is purged from chrome storage and is only held in memory for future use of the application. However, due to the undocumented way the chrome.storage API works, there may be a lingering chrome.storage log file that still contains the encryption key on your local machine’s disk. This log file is periodically overwritten by the browser, at which time the key would be permanently deleted from the system, however, depending on your usage of the extension this may not have occurred yet. For example, if you just installed the extension recently the log file may not have been overwritten yet.
The following locations contain bitwarden’s chrome.storage files:
%AppData%\Local\Google\Chrome\User Data\Default\Local Extension Settings\nngceckbapebfimnlniiiahkandclblb
~/Library/Application Support/Google/Chrome/Default/Local App Settings/nngceckbapebfimnlniiiahkandclblb
~/.config/google-chrome/Default/Local Extension Settings/nngceckbapebfimnlniiiahkandclblb
The file is usually named something like 000003.log, or 000004.log, etc (the number increments each time it is overwritten). Updating to the latest version of bitwarden will re-seed any potentially affected chrome.storage data and permanently purge the old files from the system.
How did bitwarden fix it?
Starting with version 1.24, the default lock option has now been set to “On Restart” which will ensure that the encryption key is never written to disk for fresh installations. If a user still opts in to use the “Never” option, obviously this will still occur. Users using the “Never” option should take the proper steps to ensure that their machine is kept secure to avoid compromising their bitwarden vault. Going forward we will work to present an appropriate warning to users who choose to opt in to the “Never” lock option.
Additionally, we also re-seed all chrome.storage data in the extension, meaning any old log files from chrome.storage that could contain sensitive data are permanently deleted and cleaned up.
- Jan 17 9:33pm EST — issue reported by user subdavis on bitwarden’s public issue tracker (GitHub).
- Jan 17 10:12 EST — issue confirmed by bitwarden developer.
- Jan 17 11:25pm EST — issue patched and commited.
- Jan 18 10:00pm EST — version 1.24.0 published to all stores containing the fix.
- Jan 18 11:30pm EST — this blog post published.
- Jan 19 11:45am EST — version 1.24.2 published to all affected stores which does not require the additional re-install step previously recommended in version 1.24.0.