Password encryption limitations
Open Liberty supports Advanced Encryption Standard (AES) encryption for passwords that are stored in the
server.xml file. When you use this option for protecting passwords in the Open Liberty configuration, understand the limits to the protection that AES encryption provides. Currently, Open Liberty supports AES-128 encryption.
Encrypting a password in the Open Liberty configuration doesn’t guarantee that the password is secure or protected. Encrypting a password only means that someone who can see the encrypted password can’t easily recover the password unless they know the encryption key. The application server process requires access to the encrypted password and the decryption key, so these items must be stored on the file system that is accessible to the server runtime environment. The encryption key is also required by anyone who encrypts a password that’s placed in the server configuration. If an attacker has access to the same set of files as the Open Liberty server, applying AES encryption to the password provides no additional security over XOR encoding. However, there are reasons why you might consider encrypting passwords in the Open Liberty configuration.
The Open Liberty configuration is composable and sharable. Open Liberty is designed to be configured without an administration subsystem, so any XOR-encoded password is visible to any administrator. Because of these design features, consider whether passwords are sensitive and need to be encrypted. If passwords aren’t sensitive, encoding them might provide little value. If passwords are sensitive, protect the configuration files or the encoding key, depending on the scenario. Either the configuration files that contain the passwords are sensitive and access to these files must be controlled, or the passwords are encrypted and the encoding key is protected as sensitive.
For more information about how to obfuscate passwords for Open Liberty, see the securityUtility encode command.
In Open Liberty, the default key that’s used for encrypting and decrypting can be overridden by setting the
wlp.password.encryption.key property. Make sure that you don’t set this property in the
server.xml file that stores the password. Otherwise, the file that contains the key might be included when you run the
server dump or
server package commands. Instead, set it in a separate configuration file that’s included in the
server.xml file, as shown in the following example:
<include location="/protected/key.xml" />
This separate configuration file must contain only a single property declaration, and it must be stored outside the normal configuration directory for the server.