We have an open source software that allows users to be created. The users are saved in an LDAP directory. The software connects to the LDAP as an administrator to write a new entry for a new user, or to edit the password if the user wants to change his password. To do this, the LDAP master password must be stored in the software. Now, this password is valuable, where valuable means, if it gets into the wrong hands, you have to call the police within hours. Therefore the suggestion was made to store the password reversibly encrypted with salt. However, for me this does not come out on a remarkable improvement, because the key for the encryption must also be stored on the system, as well as the salt. If an intruder has root privileges on the system, he can read the encrypted password, key, and salt, and with the open source software application, with a little programming knowledge, he will have decrypted the password shortly. I think about the best way to solve this, but no matter which technology you use, the associated key must always be stored on the system, so it is just as vulnerable as before. So the question is essentially how do you make the application have the key, but it is not stored on the system?

The application is old and has a lot of memory leaks, so it has to be restarted automatically every night, so just keeping the key in memory is not a usable option. The key must be permanently available, even after restarting the server.

The web application is in Java (EE), running on both Windows and Linux, but it the majority of users uses Linux, and for a high-security environment this could be made a requirement. However, a platform-independent way is better. The application starts with the server and is running all-time, so it can keep values in the memory.

An U2F dongle might do the job, I had not thought about that option at all yet. Thanks for the hint.

  • What is the operating system ? Do you have physical access to this machine (i mean, to be able to reset TPM) ? Is the application you mentioned a persistent service (involving that it get the master password at startup only and then store it in memory ?) or may it be launched on demand ?
    – binarym
    Mar 30 at 15:44
  • 1
    Perhaps a 2FA dongle like a Yubikey for admin access to the LDAP? It would need to remain plugged in for auto restarts but theft would require physically taking the key. Mar 30 at 16:11
  • please edit your question to include the information requested by others, and also consider the following: is this LDAP admin account dedicated to the application only, or shared by other admin users?
    – brynk
    Mar 31 at 2:11

If you're not worried about malicious insiders, here's what I'd do:

Issue each authorized user a flashdrive with a file on it. The file contains the "password" (ideally it should be too long and random to easily memorize or type, so not really a password in the usual sense). The drive is encrypted using a full-volume encryption method (BitLocker, VeraCrypt, etc.) and each authorized user has their own passphrase to decrypt their flashdrive. The software reads the LDAP "password" out of the file, once the flashdrive is installed and unlocked.

Advantages of this system:

  • The LDAP admin password can be completely beyond human ability to memorize.
  • The password copies are stored on physical objects that are easy to maintain an inventory of.
  • An attacker who steals a user's flashdrive hopefully won't know the passphrase to unlock it, so they can't decrypt the key.
  • An attacker who guesses a user's passphrase hopefully can't access their flashdrive, so they can't use the passphrase for anything.
  • In theory, each user could have a unique "password" for LDAP administration, allowing monitoring of usage and easy disabling of individual accounts at need.


  • Kind of a hassle both for the users and for the IT folks who need to create and manage all these flashdrives.
  • Changing / rotating the LDAP admin password is a mess, especially if everybody shares the same one; all the drives need to be updated.
  • More common for people to get locked out because they lose a small object or forget a passphrase than if they only needed to keep track of one of those things.
  • A malicious insider can just unlock their flashdrive and then copy the file contents out of it, trivially (or probably just decrypt the flashdrive).

You could also use hardware tokens, but most of the advantage over an encrypted flashdrive there is the ability to make the secret non-exportable. Unfortunately, that would prevent having the secret be a password, which must be transmitted in some form. That puts a real damper on how hard you can hide it, and in particular makes it totally impossible to hide from an insider.

IF at all possible, don't use a password here

Establish the connection using some form of public key cryptography. Mutual TLS, SSH with public key, whatever. Use a system where there's an unpredictable string to be signed or decrypted, and proving that you have the private key is used for authorization. Then use a hardware security module (HSM) to store the private key, and make sure it's not exportable. The key can now never be extracted, so the only way to use it is if you also have access to the HSM. Depending on your needs, this could be an HSM that is given to every authorized user or that is only available by checking out one of a limited number (possibly only 1) from a trusted source, and it could be relatively tied to computer hardware (such as the TPM in a PC) or portable (such as a Yubikey).

For extra security, you might protect access to the private key with a passphrase or other secret, turning it into effectively a two-factor authentication requirement (the attacker needs both to have the HSM, and to know the string that unlocks access to its key). SSH and GPG private keys already typically are encrypted using password-derived keys, but there are better systems than those use.

You can't do anything about an attacker with root access to a machine where the software runs. If the software can communicate with the LDAP server, the attacker can tap that communication, edit it to serve their own purposes, initiate it on demand, etc. Even if there's no post-authentication session token to steal, and the authentication sent on every request is done without exposing the secret (e.g. instead of a password, you use a symmetric key to HMAC the message or a private key to sign the message, and the key is stored somewhere the attacker can't read like inside an HSM), for as long as the attacker has access to the compromised system they'll have full control over its communication with the server, and you can do a LOT of damage in a short time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.