Password encryption
The IBM® Tivoli® Directory Server enables
you to prevent unauthorized access to user passwords. The administrator
may configure the server to encrypt userPassword
attribute
values in either a one-way encrypting format or a two-way encrypting
format. The encrypted passwords are tagged with the encrypting algorithm
name so that passwords encrypted in different formats can coexist
in the directory. When the encrypting configuration is changed, existing
encrypted passwords remain unchanged and continue to work.
Using one-way encryption formats, user passwords may be encrypted and stored in the directory, which prevents clear passwords from being accessed by any users including the system administrators. Using two-way encryption formats, passwords are encrypted while stored in the database, and decrypted when returned to an authorized client. Use of two-way encryption protects the password stored in the database, while supporting use authentication methods like DIGEST-MD5 that require the server to have access to the clear text password, and supporting applications that may need the clear-text password.
One-way encrypted passwords can be used for password matching but they cannot be decrypted. During user login, the login password is encrypted and compared with the stored version for matching verification.
Even if the server is configured to store new passwords in a particular format, it will accept passwords previously encrypted using another method. For example, the server could be configured to use AES256 password encryption, but still allow an administrator to load data from another server that contained SHA-1 encrypted passwords. Both sets of passwords can be used to authenticate to the server using simple password authentication, but the SHA-1 passwords will be returned as encrypted strings and cannot be used with DIGEST-MD5 authentication.
One-way encrypting formats are:
- Salted SHA-1
- SHA-1
- MD5
- crypt
- SHA-2
- Salted SHA-2
After the server is configured, any new passwords (for new users) or modified passwords (for existing users) are encrypted before they are stored in the directory database. Subsequent LDAP searches will return a tagged and encrypted value.
For applications that require retrieval of clear passwords, such as middle-tier authentication agents, the directory administrator needs to configure the server to perform either a two-way encrypting encryption on user passwords. In this instance, the clear passwords returned by the server are protected by the directory ACL mechanism.
Two-way encrypting formats are:
- None
- AES
A two-way encryption option, AES, is provided to allow values of the userPassword attribute to be encrypted in the directory and retrieved as part of an entry in the original clear format. It can be configured to use 128, 192, and 256-bit key lengths. Some applications such as middle-tier authentication servers require passwords to be retrieved in clear text format; however, corporate security policies might prohibit storing clear passwords in a secondary permanent storage. This option satisfies both requirements.
Additionally, when AES password encryption is used in a replicated network, if all servers are configured with the same AES passphrase and salt, password data will be replicated in its encrypted form, better protecting the password data. If a server does not support AES, or is configured with different AES information, passwords will be decrypted and replicated as clear text.
- AES is not supported on LDAP servers prior to IBM i 6.1. Specifically, replication of AES encrypted data is not supported on pre-6.1 LDAP server.
- On other platforms, when the 'None' choice is selected, clear text passwords are stored in the database. If this server is participating in a network that includes the IBM Tivoli Directory Server on other platforms, it is recommended that one of the AES encryption options be used.
A simple bind will succeed if the password provided in the bind request matches any of the multiple values of the userPassword attribute.
When you configure the server using Web Administration, you can select one of the following encryption options:
- None
- Passwords are stored two-way encrypted in a validation list and are retrieved as part of an entry in the original clear text format. The QRETSVRSEC system value must be set to 1 to use this setting.
- crypt
- Passwords are encrypted by the UNIX crypt encrypting algorithm before they are stored in the directory. When crypt is used, only the 1st 8 characters of a password are used. Passwords longer than 8 characters are truncated.
- MD5
- Passwords are encrypted by the MD5 hash algorithm before they are stored in the directory.
- SHA-1
- Passwords are encrypted by the SHA-1 encrypting algorithm before they are stored in the directory.
- Salted SHA-1
- Passwords are encrypted by the Salted SHA-1 encrypting algorithm before they are stored in the directory.
- SHA-2
- Passwords are encrypted by the SHA-2 family of encrypting algorithm
before they are stored in the directory. The supported encryption
schemes under the SHA-2 family of encryption algorithm are:
- SHA-224
- SHA-256
- SHA-384
- SHA-512
- Salted SHA-2
- Passwords are encrypted by the Salted SHA-2 family of encrypting
algorithm before they are stored in the directory. The supported encryption
schemes under the Salted SHA-2 family of encryption algorithm are:
- SSHA-224
- SSHA-256
- SSHA-384
- SSHA-512
- AES128
- Passwords are encrypted by the AES128 algorithm before they are stored in the directory and are retrieved as part of an entry in the original clear format.
- AES192
- Passwords are encrypted by the AES192 algorithm before they are stored in the directory and are retrieved as part of an entry in the original clear format.
- AES256
- Passwords are encrypted by the AES256 algorithm before they are stored in the directory and are retrieved as part of an entry in the original clear format.
The default option for the Tivoli Directory Server for IBM i is SHA-1, which is compatible with earlier releases and does not require setting an AES passphrase and salt.
In addition to userPassword
, values of the secretKey
attribute
are always AES256 encrypted in the directory. Unlike userPassword
,
this encrypting is enforced for values of secretKey
.
No other option is provided. The secretKey
attribute
is an IBM defined schema. Applications may use this
attribute to store sensitive data that need to be always encrypted
in the directory and to retrieve the data in clear text format using
the directory access control.
To change the type of encryption using the command line, for example changing to crypt, issue the following command:
ldapmodify -D <adminDN> -w <adminPW> -i <filename>
dn: cn=configuration changetype: modify replace: ibm-slapdPWEncryption ibm-slapdPWEncryption: crypt
To cause the updated settings to take effect dynamically, issue the following ldapexop command:
ldapexop -D <adminDN> -w <adminPW> -op readconfig -scope single "cn=configuration" ibm-slapdPWEncryption