Master password kept in memory after login

[denalena]

Steps To Reproduce

1. Start Bitwarden Desktop
2. Log in to your Bitwarden Vault
3. Create memory dump files via Windows task manager
4. Investigate content of the files, e.g. by running strings

Expected Result

The master password is not present in plain text in the memory dump of any Bitwarden process.

Actual Result

The master password is present in plain text in the memory dump of any Bitwarden process.

Screenshots or Videos

Additional Context

I stumbled over this issue in the archived desktop repository and realized it's still not fixed: https://github.com/bitwarden/desktop/issues/476

Operating System

Windows

Operating System Version

10.0.19045 Build 19045

Installation method

Microsoft Store

Build Version

2023.8.2

Issue Tracking Info

• [X] I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.

[bwbug]

@ledeniz In fact, a lot has happened since 2020, and you may be interested in reading about Issue #3166 and its recent resolution.

In any case, as @kspearrin pointed out already in the (since archived) Desktop Issue 476, the memory security guarantees offered by Bitwarden are limited to the states in which the vault is locked or logged out.

[denalena]

Thanks @bwbug for your answer and the hint to the related issue. Does this mean it's impossible to resolve (because of the underlying browser engine)? If that is the case, please feel free to close this issue

[atjbramley]

Hi @ledeniz,

Thank you for your report - it has been escalated for further investigation. If you have more information that can help us, please add it below.

Thanks!

[FlakyPi]

I can confirm that the same happens when using the Firefox extension. I think this is an unacceptable security issue.

[bwbug]

Users who are concerned about this should realize that to function properly, Bitwarden client apps must hold the cleartext master password in memory, because this text string is used to generate the symmetric encryption key that is then needed to decrypt vault secrets and to encrypt new information that is going to be added to the vault.

It seems to me impossible to make a password manager that is secure against an attacker who has unfettered access to device memory while the password manager is in use.

[BizClimb]

Perhaps a middle ground would be to encode the plain text password into some other form of string so it's not sitting in memory as is, it's not a bulletproof solution by any means but if there was a simple hashing or encoding on what's kept in memory, then the client itself can decode the encoded password stored in memory when it's needed? This would simply allow hiding the actual plain text vault password?

[bwbug]

It would be trivial for an attacker to themselves decode the encoded password (or an encoded encryption key). This type of approach would just be security theater, making some users feel better because they cannot see the plaintext version of the master password.

[BizClimb]

Yes, it would be an "extra step" for an attacker to go through, and a skilled attacker could certainly get it if enough work is put in, but that's what security is all about, making it as hard as possible for attackers, so I would not consider this just "security theater".

Of course risk is relative to the perceived threat model, but there are attacks that could potentially search common strings to try and extract the full vault password. Example if my password is BobIsMyName123, and an attacker search's the memory for Bob since they might know it's my name, they could find that the full vault password is BobIsMyName123 quite quickly, where as if it's hashed and not in plain text, that would not work.

Either way, you can see CERT's advice regarding handling passwords in memory, specifically plain text storage of passwords in memory here

Regardless, I wouldn't think of this being a super critical issue that needs immediate attention or anything, since a device's memory should be secured from external threats in general, but in my opinion it certainly warrants some consideration if it should be implemented at some point to increase overall security.

[dsommers]

Regardless of potential solutions, it's just obfuscation of the secret information. And it needs to be seen in context of various threat models.

I do agree that storing the password in plain text in memory is highly questionable, but to make it unpredictable, the code gets complicated. And is it worth the cost, when comparing it against threat models? How likely is it this situation could occur? What kind of attack vectors would be needed to used - in addition to just do a memory dump? Who can do trigger a memory dump? Who else can read memory regions where this information is stored?

Potential solutions could be to create a random encryption key at program start, ensuring that key is not ending up in the same memory location each time and encrypt/decrypt secrets like the master password using that key. And if that encrypted key is stored on different locations each time, it gets further more challenging.

But at some point, that encrypted information need to be decrypted and stored in plain text in memory for a shorter time ... So while it may be possible to reduce the chances to extract the plain text password, is it worth the effort with the additional code complexity?

And also consider that additional code complexity can also introduce new attack vectors in the program, triggering this "obfuscation logic" to be more predictable - leading to the password leak.

So to say it bluntly: Who and/or what are you trying to protect this access to the master password against?

I don't believe this kind of challenge can be fully be solved in software alone to be closer to bullet perfect. Once operating systems provides a possibility to have separate encrypted memory regions per application and the CPU is the instance orchestrating the encryption keys on behalf of the applications (ie. the OS or the application itself does not have access to the encryption key itself) - that's where we can get closer to a real solution.

Anything else, will essentially just be obfuscation of the memory content - in one or another way.

[tribut]

I've tried to reproduce this using the Firefox addon (on Linux) and the good news is that the master password is not kept in memory in the clear, neither in unlocked nor in locked state.

However, I did notice that multiple versions of the master password with typos I had made while trying to unlock the vault were still in memory. Is there some sort of special treatment of the master password that is applied only when the vault was successfully unlocked? If yes, this should also apply to rejected master passwords.