Our application needs to store a password in a database. It‘s not possible to store a hash because the password is needed to access other data that are protected by this password.

Currently, the password is stored encrypted with a key that is part of the code. We are aware that there is no way to store the password in a 100% secure way, but what would improve security and why? For example, would a salt add security?


  • The password is originally entered by a user into the application
  • Access to the password is required in non-interactive mode (so cannot be unlocked by a user)
  • Only solutions on the application level can be applied

There are a couple ways this problem is approached. One is to configure the system to connect to a PKCS#11 server, and to use the HSM to decrypt the master password when the application service is started. (This becomes another chicken-and-egg problem when you realize you have to store the PKCS#11 credentials in a file.)

Another approach is to require a human to enter an "unsealing" password every time the service is started. While this can be more secure, it can't provide automatic recovery in the case of a failure.

Yet another approach is to store your master key in an on-board Hardware Security Module (HSM), such as a TPM chip. You would have to consult your OS documentation for information about using this approach.

  • Thank you for the suggestions. However, HSM and user action cannot be used. I‘ve updated my question with relevant restrictions. – not2savvy Mar 2 '20 at 22:05

A salt does not help you, because a salt is applied to a cryptographic hash function, which isn't suitable for your scenario, as you have correctly analyzed. Your goal is to make access to the credentials (or the key to decrypt the credentials) as difficult as reasonable possible, given your limitations.

The following approaches are commonly used:

  • Depending on your operating system, you have different options to store credentials locally (e.g. the DPAPI from Microsoft).

  • A modern approach would be using a vault (e.g. from Vault Project) that manages the secure distribution of credentials in your infrastructure. In such a scenario, the credentials are stored on a central server that manages the access rights.

  • In addition, there are hardware-based and token-based key-stores available, ranging from a simple smart card to a full blown HSM.

All of those options are viable and none of them are 100% secure. If someone is able to gain control of your application, he can do what the application can do - including accessing your credentials.

  • Could you please explain why a salt cannot be used with encryption? – not2savvy Mar 2 '20 at 23:25
  • @not2savvy - Salts are used for hashing, to reduce their vulnerability against rainbow table attacks. The length of the plaintext drives the size of the required rainbow tables and therefore influence their viability. For encryption (symmetric and asymmetric alike) the size of the plaintext doesn't matter, as long as you are using a state-of-the-art algorithm with appropriate modes. Therefore, a salt does not add additional security for encryption. – Demento Mar 3 '20 at 18:02

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.