!!! Overview

%%warning
[RFC 6331] Moving DIGEST-MD5 to Historic due to [Vulnerability] 
%%


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 DIGEST-MD5 SASL mechanism is described in [RFC 2831], but a revised specification is contained in [draft-ietf-sasl-rfc2831bis|https://opends.dev.java.net/public/standards/draft-ietf-sasl-rfc2831bis.txt|target='_blank'].  

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|LDAP Result Codes] 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.

!! Correcting a Misunderstanding[1]
Using the [SASL] [{$pagename}] 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 [{$pagename}] 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 [Salt]ed [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 [{$pagename}] 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 alter[{$pagename}]Plain-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:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Authenticate to LDAP using JNDI and Digest-MD5|http://stackoverflow.com/questions/11881969/how-to-authenticate-to-ldap-using-jndi-and-digest-md5|target='_blank'] - based on 2013-04-10