Hi,
I found the following keys: “keyHash”, “encKey”, and “encPrivateKey” in a file called data.json located in %AppData%\Bitwarden. My browser extension timeout option is “On Browser Restart”, and the Bitwarden App (Version 1.20.1) Log-out (NOT lock) option is “On Restart”. But all the encrypted data together with the “key” is still in the data.json even after computer reboot.
What does each of those keys mean? Are they the decryption key (that is, the 100,001 or as configured iteration of the Master Password)? If so, isn’t it unsafe to keep the key on the hard disk?
Also, how many bits is the encryption key? Is it 128-bits, or is it more, since SHA-256 keys seems longer than 128-bits?
keyHash:
A hash derived from your Master Password and derived Master Key. This cannot be used to obtain your Master Password or Master Key.
encKey:
An encrypted version of the Generated Symmetric Key (which contains the encryption key and MAC key). This is protected by the encryption key derived from your Master Key.
encPrivateKey:
An encrypted version of your RSA Private Key. This is protected by the encryption key derived from your Master Key.
Since both encKey and encPrivateKey are encrypted by a key derived from your Master Password (the derived key is not saved in data.json) there is little risk in storing these locally. The upside of having the data.json is you have a locally cached version of your vault available in case Bitwarden is down/offline (or the company disappears).
I’ll refrain from commenting on keyHash until I’ve studied it’s use more and reviewed the upcoming whitepaper.
Since these keys are not the actual encryption key, why are they needed? I mean, shouldn’t the Encryption Key be strong enough to protect the whole vault, without need of other keys? Also, as I’m not using the organization version of Bitwarden, why does it use RSA?
The encrypted Vault data should be stored on the hard disk (in data.json) when in “Lock” mode, but NOT in “Logout” mode. There should be a way to permanently delete all Bitwarden Vault data, which I previously thought is the “Logout” option. Is there a way to delete all data from data.json without uninstalling the Desktop App? @tgreer
Thank you very much! Looking forward to your reply!
Nat
These are the actual encryption keys that protect items in your vault. Every account generates an RSA key pair on creation for use with Organizations/Collections even if you are not using that feature.
This is exactly how things are working on my computer.
But it doesn’t seem to work well on my computer though. I first configured the Desktop App Vault Timeout to “On Restart” and the Vault Timeout action to “Logout”. Then, I closed the App without logging out manually and rebooted my computer. After that, however, all the data is still in the data.json file. But I can’t log in without my wifi turned on.
Is this a bug? Acting like it’s logged out, but still keeps all the data…
Thank you very much! Looking forward to your reply!
Nat
@RobertT When I manually click the logout button, it would delete nearly all the data in data.json. But shouldn’t auto-logout be the same as manual logout? I hope Bitwarden doesn’t expect everyone to manually logout every time…Seems like a bug to me…
A very good point. Isn’t there an option to pick whether it Locks or Logsout in Preferences too ? Does that help (somehwhat) ? I do agree that if you Quit, ideally the app should logout - or let there be a preference that does that for your as it shuts down.
@BitMDP123
Thanks for your suggestion!
I tried the “Quit” function, but it didn’t work.
I use the “Logout” and “On Restart” option in Settings.
Logging out should delete all the data, or else hackers could just take the encrypted data and try to decrypt it. Seems like there isn’t any difference between logout and lock mode for hackers…
@Nat, @RobertT, what became of this discussion - I realise its now 2 years old and may well be superseded or now obsolete due to BW updates - but was the outcome of the vault security/access/deletion resolved/clarified?
(I’m new to BW and just in the process of migrating away from 1PW so doing a steep-ish learning curve to upskill myself on BW - more than I bothered with for 1PW and now regret).
Seems like this bug is still there in the Desktop app. If you set the vault time-out options to Logout and On Restart, your login session is deauthorized (requiring you to log back in before you can access the UI and sync with the cloud vault), but the data.json file is never scrubbed when quitting or when restarting the Desktop app.
It works as expected when logging out manually, or when logging out automatically after if the vault time-out has been set to a time-based limit (I confirmed it for the 1 min option), but not when the time-out trigger is set to On Restart.
Thanks @grb for the quick update. I’d have wondered if your first paragraph behaviour “If you set the vault time-out options to Logout and On Restart, your login session is deauthorized, but the data.json file is never scrubbed when quitting or when restarting the Desktop app” is deliberate - to leave a back-up copy of vault on the device (for offline access). But obviously that’s not true based on your second paragraph “It works as expected when logging out manually, or when logging out automatically if the vault time-out has been set to a time-based limit, but not when the time-out trigger is set to On Restart.” So probably need a BW Team SME to clarify behaviour (and confirm if its a bug)?
No special clarification is needed, because the expected behavior is published in Bitwarden documentation: “Logging out of your vault completely removes all vault data from your device.”
If you want to leave a backup copy of your vault stored on your device for offline access, that is what the Lock function is for.
Cheers - still making my way through all the documentation so haven’t full digested that part (offline access and how vaults are stored on my list to read up on shortly). My point was mainly around what you reported re: On Restart timeout setting seems to definitely be a bug - need a BW team expert to clarify if that should scrub the json file, right?
It’s the fact that the Time-out Action setting is set to Logout that makes it a bug. If the time-out action is set to “Logout” and the time-out trigger (“On Restart”) does not result in a full logout, then it is a bug — no ifs, ands or buts. Not sure why a Bitwarden dev would be needed to clarify or confirm this, since the behavior is reproducible.
I meant in the sense its not intentional? Obviously if it’s set to ‘on restart’ it can’t trigger until the restart - which could be anytime (meaning the vault file is left in limbo until then). It would be better being set to on shutdown (or reboot if O/S is the trigger), but obviously if its at shutdown it may not complete the action reliably due to the shutdown?
My point is that the logout process does not complete (the data.json file is not scrubbed) even when the app is restarted, or even when the new login process is initiated (i.e., after the username has been entered but before the master password has been entered). I suppose it is theoretically possible that the vault may be scrubbed for a minuscule time period between when the password is entered and the vault is synced after the successful login. But such a feature would be absurd, so I highly doubt that this is the intended function of the Logout On Restart option.
It would make more sense to rename this time-out option and implement it so that the time-out action (Logout, in this case) occurs On Exit (i.e., on quitting the app). But even if the intention was to offer an option to have the time-out action occur literally when restarting the app, then this functionality has not been correctly implemented.
The Desktop app has time-out options for “on system lock”, “on system sleep”, and “on system idle”, and the Browser Extension also has “on browser restart”. I have not tested these extensively, but I would assume they work as expected unless there is evidence to the contrary.
Yes - absolutely. I think we are saying the same thing in different ways
Absolutely - I am using these myself - but haven’t tried to prove if they don’t work - as you say I have assumed “they work as expected unless there is evidence to the contrary”.
