The DIGEST-MD5 SASL Mechanism provides a way for clients to perform Authentication to the Directory Server with a username and Password in a manner that does not expose the clear-text password., so it is significantly safer than Simple Authentication or the PLAIN SASL Mechanism when the connection between the client and the server is not secure.
The process is as follows:
- The client sends an LDAP Protocol Exchange to the server with a Bind Request type using an authentication type of SASL with a mechanism name of "DIGEST-MD5" and no credentials.
- The server sends a Bind Response message back to the client with a Result Code of 14 (SASL bind in progress) and a server SASL credentials element including, among other things, some randomly-generated data (the Nonce).
- The client takes the Nonce provided by the server, and some randomly generated data of its own (the cnonce), an authentication ID, an optional AuthorizationID, the user's clear-text password, and some other information and uses that to create an MD5 digest. The client then sends a second Bind Request message including that digest and some other clear-text information back to the server.
- The server uses the Authentication ID to identify the user, and then retrieves the clear-text password for that user (if the clear-text password cannot be obtained, then Authentication will fail) and uses it to determine whether the provided digest is valid. The server will then send an appropriate Bind Response to the client (usually with a result of either "success" or "invalid credentials") indicating whether the authentication was successful.
- If the client requested a Quality of Protection (QoP) value indicating that the connection should be protected with integrity and/or confidentiality, then the server will initiate the necessary negotiation with the client.
The DIGEST-MD5 SASL Mechanism is very similar to CRAM-MD5 SASL Mechanism, but it is somewhat strong because CRAM-MD5 SASL Mechanism only includes random data from the server whereas DIGEST-MD5 includes random data from both the client and the server. DIGEST-MD5 also provides a provision for ensuring connection integrity and/or confidentiality, which CRAM-MD5 SASL Mechanism does not offer.SASL DIGEST-MD5 mechanism in a BIND request requires that the directory server have access to the password of the user. For the directory server to have access to the password, the password must be stored in clear text or be encrypted with a reversible password scheme. Reversible password schemes are inherently less secure than the salted SHA hash, particularly a salted SHA-2 hash with a long digest. As a result, using SASL with DIGEST-MD5 is less secure than using a simple BIND request over a secure connection, where a secure connection is a connection encrypted from the beginning via SSL or a non-secure connection promoted to a secure connection with the StartTLS extended operation, and less secure than the SASL Mechanism or Kerberos.
The misunderstanding is the notion "password sent over the network in plain-text" is not secure, when in fact, storing the password in the directory server using a Salted SHA-2 hash (modern professional-quality directory servers have the capability to use salted SHA-2 hashes with long digest lengths) and transmitting the clear text password over a secure connection is more secure than having the directory server store the password in clear text or in a reversible encryption scheme. Therefore, SASL with DIGEST-MD5 should be avoided. SASL with the EXTERNAL mechanism where the server extracts the authentication information from the Certificate presented during the establishment of the encrypted session is a better alternative. Kerberos is also a better alterDIGEST-MD5Plain-text over the network is also more secure if the server is storing the passwords after hashing them with a salted SHA algorithm.
If it is absolutely vital to use SASL with DIGEST-MD5, the directory server should be configured to encrypt the passwords with the strongest encryption scheme available, which unless I am mistaken, is AES. Professional-quality servers can encrypt passwords using AES.
More Information#There might be more information for this subject on one of the following:
- Authentication ID
- Authentication Protocol
- Best Practices for LDAP Security
- CRAM-MD5 SASL Mechanism
- Digest SSP
- Glossary Of LDAP And Directory Terminology
- On-Demand Password Synchronization
- Quality of Protection
- RFC 6331