Encrypt passwords in memory of an unlocked browser extension

Once I have unlocked the browser extension all saved accounts and passwords are unencrypted in one of the browser’s processes. This includes them in memory dumps and makes them vulnerable to attacks. They may also get included in hangup reports etc.

Is it possible to not put them unencrypted into RAM?
In the Bitwarden application they aren’t unencrypted in it’s processes.

Even if somehow vault data such as passwords could remain encrypted while loaded into process memory, the encryption key would still have to be stored in the memory, so an attacker who is able to access your device memory could still decrypt your encrypted passwords using this key.

This is not to mention the simple fact that an attacker who has such unfettered access to your device as to be able to dump the memory contents, would easily be able to install malware/spyware on your device that would exfiltrate your master password (and/or encryption key), as well as the vault contents.

There are some approaches which would certainly improve the situation, some libraries implementing this are libsodium and memguard. One technique makes access harder by sandwiching the pages holding secrets between guard pages that will cause a segfault when accessed. Building upon this a technique called Boojum described in Bruce Schneier in Cryptography Engineering could be used, which constantly (every few milliseconds) rotates the in-memory encryption.

Lastly, there are also other approaches like using a tpm and or the kernel’s per-process keyring (at least on linux, idk about other platform’s APIs but i’m sure they are similar).

These certainly make dumping memory much harder.

Though… none of this applies to web extensions. To be honest I doubt this could even be useful in the desktop application because of how electron works. Rendering an entry would already bring it’s contents into unencrypted memory, and keep it there even after closed until it is garbage collected. Basically, this is only useful with very careful memory control.

Also as @grb mentioned, there are much easier attack vectors for a physical attacker like screen capture, keyboard interception and even clipboard interception as platforms (especially non UWP and Linux on X.Org based desktop environments) do not put a tight control on access to these.

1 Like