Why app server credential encryption is reversible, and what that means
Password storage usually means hashing: a one-way function that lets a system verify a password without ever being able to recover it. Application servers that need to connect to a database on an application's behalf cannot use that approach for their own stored credentials, because they need the actual plaintext password at connection time, not just a way to check it.
Why reversible encryption is the only option here
A datasource configuration file has to store a password that the server itself will later present to the database. Hashing would make that impossible, since a hash cannot be turned back into the original value. The practical alternative is symmetric encryption with a key the server holds, which is reversible by design: anyone who has the same key the server used to encrypt the password can decrypt it back to plaintext.
Where that assumption breaks down
The security of this scheme depends entirely on the encryption key being kept secret and, ideally, unique per deployment. Historically, some application server defaults used a fixed, well-documented key rather than one generated per installation, which meant anyone who recognised the encrypted value's format could decrypt it using publicly known information, without ever needing to find or guess the key.
The second route: memory, not configuration
Even where the stored, encrypted value is well protected, the server must hold the decrypted plaintext in memory at the moment it authenticates to the database. A full memory capture of the running process, taken and analysed offline, can recover that plaintext directly, bypassing the encryption scheme entirely because it never needs to break the encryption at all.
The defender's takeaway
Any credential that a server must be able to use automatically, rather than merely verify, cannot be protected by hashing and needs a deployment-specific, properly managed key if encrypted locally at all. The more durable fix is moving the credential out of local configuration entirely, into an external secrets store the application retrieves it from at startup, so no static key or config file ever holds a value that decrypts to a real password.
Key takeaways
- Credentials a server must reuse automatically cannot be hashed; they need reversible encryption instead.
- Reversible encryption is only as strong as the secrecy and uniqueness of the key behind it.
- A fixed or well-documented default key turns 'encrypted' storage into effectively plaintext.
- Decrypted credentials exist in process memory at connection time, which is a second route to recovering them.
- External secrets stores remove the need to keep a decryptable credential in local configuration at all.
This note has been rewritten and checked for this edition; it is not a copy of the original post.