← Back to context

Comment by aborsy

1 day ago

That’s true for any password manager. If the database/store is unlocked (so the master password is cached or available in RAM), all passwords can be extracted. You have to lock the password manager when you don’t need it.

In fact, with Bitwarden, the cached password is exposed to the browser that has a large attack surface (including interacting with random remote servers). There was just a vulnerability in most browser based password managers including Bitwarden that would allow a remote attacker trick a user send out their passwords.

I use Bitwarden but mostly for non-critical passwords.

Doesn't good 2factor minimize a large attack surface like this?

I like the idea of storing password data in individual encrypted files and using git to store changes, but I wonder if it creates more friction to retrive the information. I havent tried this solution yet. I will when I get more time. It seems like this solution would benefit from a more standardized specification for storing and retrieving information. I known its not every persons cup of tea, but maybe some kind of separated add-on for streamlining this process could be beneficial.

>That’s true for any password manager

Modern operating systems isolate individual apps such that a malicous app can not access the RAM of another app. There is a difference between not making an effort to protect passwords and requiring an OS exploit to do so.

  • Memory isolation doesn't really help, though. If you have a malicious process running under the same user account as your password manager, it's still game over since that process could e.g.

    - capture keyboard input - capture your screen - silently install browser extensions to capture your credentials - modify your shell config, .desktop files, $PATH, … to have you e.g. call a backdoored version of your password manager, or put a modified version of sudo on your $PATH that logs your password (=> root access => full memory access) - …

    • You can use Qubes OS for true VM-level isolation, or use hardware security keys where possible, or run sensitive applications in dedicated VMs.

      I think that in general it is game over the moment you have malicious processes running. I use firejail for most applications, which I believe is the bare minimum, or bubblewrap.

      3 replies →

    • Ugghh, once again I forgot that HN removes line breaks unless you use double line breaks or indent by 2 spaces, and now it's too late to edit my comment.

      @dang People keep running into this. (See e.g. this comment[0] from a few days ago.) It also makes it rather awkward to write lists IMO. What's the reason for removing line breaks and could this be changed?

      [0]: https://news.ycombinator.com/item?id=44946386

    • For modern operating systems capturing keyboard input is locked down to avoid keyloggers. Capturing your screen requires explicit user permission to do so, popping up a dialog. Apps are isolated so another app can't interfere and install a browser extention or modify shell configs, etc.

      4 replies →

  • The OS protections apply to all applications. In addition, the job of agents like gpg-agent or ssh-agent is to protect secret keys while they are cached (like preventing OS writing keys to swaps). You can configure them to erase keys after a certain time, require user’s confirmation for each key operation, store gpg keys in internal TPM or external hsm, and would talk to the agent through specific sockets.

    Unlike browser-based password managers, the agents don’t continuously interact with the browser code and remote elements (probably don’t have network access at all).

    One area that matters that I forgot to mention in my comment below is that, as a result of all above, Pass doesn’t check the domains and doesn’t protect against phishing. There might be extensions, but at that point, you might as well use keepassxc.