LDAP passwords are normally stored in the userPassword attribute. RFC4519 specifies that passwords are
not stored in encrypted (or hashed) form. This allows a wide range of password-based authentication
mechanisms, such as DIGEST-MD5 to be used. This is also the most interoperable storage scheme.
- SSHA password storage scheme
This is the salted version of the SHA scheme(sha 加密算法的加盐版本). It is believed to be the most secure password storage scheme(最安全的密码存储方案)supported by slapd.
These values represent the same password (下面这些值表示相同的密码):
userPassword: {SSHA}DkMTwBl+a/3DQTxCYEApdUtNXGgdUac3
userPassword: {SSHA}d0Q0626PSH9VUld7yWpR0k6BlpQmtczb - CRYPT password storage scheme
This scheme uses the operating system’s crypt(3) hash function. It normally produces the traditional
Unix-style 13 character hash, but on systems with glibc2 it can also generate the more secure 34-byte MD5
hash.
userPassword: {CRYPT}aUihad99hmev6
userPassword: {CRYPT} 1 1 1czBJdDqS$TmkzUAb836oMxg/BmIwN.1
The advantage of the CRYPT scheme is that passwords can be transferred to or from an existing Unix
password file without having to know the cleartext form. Both forms of crypt include salt so they have some
resistance to dictionary attacks.
Note: Since this scheme uses the operating system’s crypt(3) hash function, it is therefore operating system
specific. - MD5 password storage scheme
This scheme simply takes the MD5 hash of the password and stores it in base64 encoded form:
userPassword: {MD5}Xr4ilOzQ4PCOq3aQ0qbuaQ==
Although safer than cleartext storage, this is not a very secure scheme. The MD5 algorithm is fast, and
because there is no salt the scheme is vulnerable to a dictionary attack. - SMD5 password storage scheme
This improves on the basic MD5 scheme by adding salt (random data which means that there are many
possible representations of a given plaintext password). For example, both of these values represent the same
password:
userPassword: {SMD5}4QWGWZpj9GCmfuqEvm8HtZhZS6E=
userPassword: {SMD5}g2/J/7D5EO6+oPdklp5p8YtNFk4=
OpenLDAP Software 2.6 Administrator’s Guide - SHA password storage scheme
Like the MD5 scheme, this simply feeds the password through an SHA hash process. SHA is thought to be
more secure than MD5, but the lack of salt leaves the scheme exposed to dictionary attacks. (但是缺乏盐值使该方案暴露在字典攻击下)
userPassword: {SHA}5en6G6MezRroT3XKqkdPOmY/BfQ= - SASL password storage scheme
This is not really a password storage scheme at all. It uses the value of the userPassword attribute to delegate
password verification to another process. See below for more information.
Note: This is not the same as using SASL to authenticate the LDAP session.
Since OpenLDAP 2.0 slapd has had the ability to delegate password verification to a separate process. This uses the sasl_checkpass(3) function so it can use any back-end server that Cyrus SASL supports for checking passwords. The choice is very wide, as one option is to use saslauthd(8) which in turn can use local files, Kerberos, an IMAP server, another LDAP server, or anything supported by the PAM mechanism.
The server must be built with the --enable-spasswd configuration option to enable pass-through
authentication.
Note: This is not the same as using a SASL mechanism to authenticate the LDAP session.
Pass-Through authentication works only with plaintext passwords, as used in the “simple bind” and “SASL PLAIN” authentication mechanisms.
Pass-Through authentication is selective: it only affects users whose userPassword attribute has a value marked with the “{SASL}” scheme. The format of the attribute is:
userPassword: {SASL}username@realm
The username and realm are passed to the SASL authentication mechanism (SASL 身份验证机制) and are used to identify the
account whose password is to be verified. This allows arbitrary mapping between entries in OpenLDAP and accounts known to the backend authentication service.
It would be wise to use access control to prevent users from changing their passwords through LDAP where
they have pass-through authentication enabled.