That’s not completely accurate. You can only export the database, if you “logged in” to it before. (and KeePassXC also has locking/unlocking mechanisms) I guess, they reason, that you already provided your master password (and YubiKey or Key File) with “logging in” to the database file.
PS: That being said, another “failsave” for export like with Bitwarden is not bad. But with an open database, in either way (Bitwarden and KeePassXC) you could also manually “copy” vault items etc. - so a password for exports doesn’t prevent everything here…
Unfortunately I found out that when bitwarden is unlocked, its master password remains stored in the process memory, along with all its passwords and usernames contained in its database. The good thing is that when it is locked the memory is emptied. However a malware could exploit the time in which bitwarden is unlocked to steal all the passwords.
I don’t know how dangerous this can be, but I recommend keeping bitwarden unlocked for a very short time.
@xmestessox Thanks for your new “report”, but that is not “new news” - and that’s why we always recommend a very short “unlocked” interval. (e.g. usually a vault timeout not longer than 5-15 minutes)
I think you will find that when any password manager is unlocked, that the passwords are accessible using information contained within process memory. That is pretty much the definition of “unlocked”.
This is one of the big reasons why “stay malware free” is such a mantra. It is also why things like “low-effort” biometric unlocks are so important – if I make it easy to unlock, you will not mind generally keeping it locked.
In my opinion, a password manager is for keeping sensitive data safe. And a password manager that stores unencrypted passwords in memory is not a secure password manager because it is vulnerable to a memory dump attackor other techniques.
And especially paid password managers should design a password manager that does not store clear text passwords in memory.
Absolutely true. That is why one should not unlock their vault on a machine they do not trust to be free from malware. Your concern also seems like the perfect reason to pepper your passwords.
Given your strong prioritization of confidentiality over availability (see CIA), you might consider setting your “vault timeout” to “lock” and “immediate”. This will keep the in-memory data encrypted almost all the time.
Do you understand how computers work? You cannot do anything with data (e.g., display, edit, or autofill passwords) unless the data is available in memory for the CPU to access. The passwords are not stored in memory for frivolous reasons, they are stored in memory because the Bitwarden apps would not be able to function otherwise.
The best you can ask for is for a password manager to only decrypt vault items one at a time, as needed, instead of decrypting and storing the full contents of the vault. My understanding is that Bitwarden devs are working towards this goal, but this is going to require a major rewrite of large parts of the Bitwarden codebase (which consists of nearly a half-million lines of code, by the way), so it will take some time for that to be implemented.
The best you can ask for is for a password manager to only decrypt vault items one at a time, as needed, instead of decrypting and storing the full contents of the vault. My understanding is that Bitwarden devs are working towards this goal, but this is going to require a major rewrite of large parts of the Bitwarden codebase (which consists of nearly a half-million lines of code, by the way), so it will take some time for that to be implemented.
Perfect, exactly as you said, it would be a good thing if a password manager stores unencrypted data in memory only what is needed, and not the whole database. I hope that in the future those who work on bitwarden will be able to achieve this, I am confident that they will.
Yes a good thing but not a giant leap for mankind. By necessity, the encryption key itself will be stored in working memory in both the current and 1-at-a-time scenario. With it, one can decrypt any entry in the database. It’s just a bit more work for the bad actor.
To truly achieve stores unencrypted data in memory only what is needed, set set your “vault timeout” to lock and immediate. This purges the encryption key when not in active use. This is available today.
Assuming you have an operating system that is running bitwarden and a malicious program that is able to read bitwarden’s memory:
If bitwarden has access to that encryption key stored in a secure enclave, I don’t see how you could prevent that malicious program from doing the same.
You could encrypt the key in that secure enclave, but that meta encryption key would have to be stored in memory, which is accessible to that malicious program.
With malware with OS admin privileges on a system, there is very little (or nothing) that can be done. That’s why operating systems like Qubes OS exist.
And, by the way, if you were paranoid enough to use an OS like Qubes as your daily driver, I don’t think you would be using an online password manager.
I remind you that KeepassXC has its own hidden process memory, it doesn’t even appear in the list. So if KeepassXC can hide this I think it is possible to do it with other password managers. You just have to want it and have the skills to do it.
I’ve been thinking about something, and I want to make you a riddle!
It is true that bitwarden data is stored in the ram unencrypted. However, the data is stored in a scattered way, and maybe it’s not easy to find passwords among so much scattered data.
So I want to challenge you to discover a password.
To understand if it is easy or difficult to find a bitwarden password stored in the unencrypted ram I created a password and then I read the bitwarden ram process where the unencrypted passwords are stored.
Let’s pretend that a malware has managed to gain access to the bitwarden ram as shown in the image.
Can you find the password? It is in this data in the image. What is it? If you find it, write me the password. It’s very easy to find out what it is, along with all your account data: username, url,password title, username, url, etc.
If bitwarden could not store all passwords in ram when unlocked it would be perfect.
You seem to have already forgotten everything that was explained to you previously, here, here, and here.
I don’t know if your “riddle” is supposed to be some kind of joke, but the password is plain to see (tgG******5ov). It is no secret that the vault data are stored in plaintext when the app is unlocked, and the solution is simple: keep the vault locked at all times, except for when you need to autofill a password.
This right here is where you and I diverge in our thinking. To me, unlocking a vault on a malware infected machine is itself the game-losing play.
At that point, the malware knows how a password was accessed and can do the same thing to access the next password, be it by accessing Bitwarden memory, calling Bitwarden functions, etc.
Encrypting in memory only masks the symptom you observed/reported; it does not solve the problem of wanting to trust an device that is not trustworthy…
This right here is where you and I diverge in our thinking. To me, unlocking a vault on a malware infected machine is itself the game-losing play.
At that point, the malware knows how a password was accessed and can do the same thing to access the next password, be it by accessing Bitwarden memory, calling Bitwarden functions, etc.
Encrypting in memory only masks the symptom you observed/reported; it does not solve the problem of wanting to trust an device that is not trustworthy
Hopefully I never have malware accidentally installed on my computer.
