The limits to protection through password encryption

The Liberty profile supports Advanced Encryption Standard (AES) encryption for passwords stored in server.xml.

Encrypting a password in the Liberty profile configuration does not guarantee that the password is secure or protected; it only means that someone who can see the encrypted password, but does not know the encryption key, cannot recover the password. The application server process requires access to both the encrypted password and the decryption key, so both these data items need to be stored on the file system accessible to the server runtime environment. The encryption key is also required by anyone who encrypts a password placed in the server configuration. For an attacker that has access to exactly the same set of files as the Liberty profile server instance, applying AES encryption to the password therefore provides no additional security over and above "exclusive or" (XOR) encoding.

Nonetheless, there are still reasons why we might consider encrypting passwords in the Liberty profile configuration. The Liberty profile configuration is designed to be highly composable and sharable. The administration subsystem of the full profile (the administrative console and wsadmin scripting) prevents an administrator from gaining access to an XOR-encoded password. The Liberty profile is designed to be configured without an administration subsystem, and so any XOR-encoded password is visible to any administrator. Given these design features, consider the following scenarios:

• The passwords are not sensitive, so encoding them provides little value.

• The passwords are sensitive, so either the configuration files containing the password are security sensitive and access needs to be controlled, or the passwords are encrypted and the encoding key is then protected as security sensitive.

The encryption key used for decrypting can be overridden from the default by setting the wlp.password.encryption.key property. This property should not be set in server.xml that stores the password, but in a separate configuration file included by server.xml. This separate configuration file should contain only a single property declaration, and should be stored outside the normal configuration directory for the server. This ensures that the file containing the key is not included when we are running the server dump or package command. The encryption key property can also be specified as a bootstrap property. If we choose this option, we should put the encryption key in a separate properties file included in the server bootstrap.properties file.

For information about using XOR or AES to protect the passwords see the related links, especially securityUtility command.

Parent topic: Security

Tasks:

Set up BasicRegistry and role mapping

Configure LDAP user registries with the Liberty profile

Configure RunAs authentication

Enable SSL communication

Reference:

securityUtility command

Application-defined data sources

SSL configuration attributes