I'm a software dev working on an open-sourced password manager(dev lib, gui and cli) for educational and eventually usefulness purposes. There doesn't seem to be all that much information regarding vault-based password managers and the security they build on/attack vectors and common practices to protect against them. So I was wondering what the application(especially the GUI app) can take for safety precautions for keeping the data secure?

For unlocking and adding/removing entries in the vault

  • 1/2FA to unlock the vault
  • It uses AesGsm + Argon2ID for password hashing/validation and data encryption.
  • Sensitive data is stored in libsodium sodium_malloc memory space and sodium_mprotect_noaccess no matter encrypted or not
  • It'll offer password/word generation as well as warning against passwords existing in password lists
  • Data is zeroized before deallocation/dropped
  • Vault is locked based on in-activity

To summarize my questions,

  • While I've understood that memory handling could only ever be relatively safer by using Intel SGX & Amd SEV enclaves, are there possibly any glaring flaws that I should know about in any category of the protection a password manager is supposed to offer?
  • Are there generally any safety precautions that can be taken when presenting the sensitive information to the user, except for proper cleanup? It will support "revealing"/readable the password, clipboard and QR code generation?

1 Answer 1


Note: First of all, let me clarify that if a machine on which a password manager is running is compromised, no amount of memory protection or other safeguards will completely save the user (and a compromised computer is also not the threat a password manager is designed to defend against). That said, a password manager can take measures to limit the damage in some situations.

The following techniques are only useful in case of infection by unprivileged malware (you cannot defend against malware with root/admin privileges), and will protect only those secrets that do not leave the password manager. Passwords that are used will be compromised while being entered into the browser. However, any passwords that haven't been used won't, nor any TOTP secrets (if the password manager includes TOTP support).

Here are some things you can take care of:

The password manager's memory shouldn't be unnecessarily accessible by other processes

By default, processes can access the memory of other processes that are running with the same (or less) privileges under the same user. This means that even unprivileged malware can extract the master key or other secrets from memory. sodium_mprotect_noaccess() will not save you here, since malware can also change the memory protection flags on another process's memory.

Some password managers try to overcome this by encrypting secrets in memory. This amounts to security by obscurity and has very limited benefit. Instead, you should protect memory like KeePassXC does, making it inaccessible to all other unprivileged processes. (You'll probably have to look at the source code to figure out how they implement this. If memory serves me right, on Windows they do it using DACLs.)

Protect the master password

Apart from memory protection, you want to protect the master password from being key logged, otherwise the entire password database will be compromised to the point that all other protections will be useless.

One way you can reduce the chances of the master password being key logged (on Windows only, I do not know if the equivalent can be done on Linux/MacOS) is the use of what some password managers like to call 'secure desktop' (not the same thing as the Secure Desktop that Windows uses for login and UAC prompts). Basically, the main password manager process creates a new desktop using CreateDesktop, prompts the user to enter the master password on the new desktop, closes the desktop and returns to the main desktop (check KeePass's source for implementation details). Any process running on the main desktop cannot directly key log the master password on the new desktop.

Although this will mitigate common keyloggers, any malware that is aware of this technique can enumerate all desktops and create a process on any new desktops, allowing it to key log the master password[1]. The solution is to check the new desktop for any unauthorized processes, and either kill them or prompt the user about them

  • On Linux, key logging cannot be prevented using X.org. In theory, the Wayland composer should isolate better. At least, it is not trivial to intercept key strokes unlike with X.org.
    – A. Hersean
    Jul 20, 2021 at 12:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .