Comments on AUTH CRAM-MD5
Susam Pal said:
Matt, you make a very good point. Yes, the server needs to store the passwords in plaintext in case of CRAM-MD5 authentication so that it can compute the expected response and match it with the received response.
Here is a sample entry in the /etc/exim4/passwd file for the curious:
alice:$1$vRPkzzDi$3sqk2e4Jcgn/YEeB1JqgT1
In case of PLAIN or LOGIN authentication mechanism, the above entry
is enough to setup the user 'alice' with password 'wonderland' that
has been used in this post. In this example, the second field
contains the password hashed with MD5 and a random salt. After the
server receives the password from the client, it would compute a
hash from the password using the same hashing algorithm and salt
(vRPkzzDi in this case) and check that the result
matches with the hash in this file.
For CRAM-MD5 authentication mechanism to work properly, we'll need
an entry like this in the passwd file.
alice:$1$vRPkzzDi$3sqk2e4Jcgn/YEeB1JqgT1:wonderlandStrictly speaking, the second field is not necessary. It could have been empty since only the third field containing the password in plaintext is used to compute the expected response to the challenge during CRAM-MD5 authentication.
Matt Mullins said:
The problem with challenge-response authentication, however, is that it requires the server to store passwords in plaintext. There are very few servers I trust enough to store my password without properly hashing it first.
In practice, most systems use PLAIN authentication over a secured connection, such as by SSL, so that it's not susceptible to the man-in-the-middle problem described.
You can also use Kerberos through GSSAPI to trust a single source for authentication tickets. A Kerberos key distribution center does store password-equivalent data as plain-text, but it minimizes the number of systems that need to be protected to such a high degree.