Es wird beispielsweise gerne zur Authentifizierung gegenüber SMTP- oder IMAP-Servern eingesetzt, da es die Übertragung des Passworts im Klartext vermeidet. Durch dieses Verfahren kann auch über unverschlüsselte Kanäle eine sichere Authentifizierung gegenüber einem Server erfolgen.
In RFC 2195 ist das Verfahren näher beschrieben:[1]
Der Server sendet eine Zeichenkette (Zahlen, Zeitstempel und voll qualifizierter Hostname des Servers) zum Client (Challenge).
Der Client antwortet mit einer Zeichenkette aus Nutzernamen, Leerzeichen und einem „Digest“. Dieses Digest ist der Base64 kodierte MD5-HMAC-Hash eines Wertes berechnet aus Challenge und Passwort (Response).
Der Server kann das erhaltene Digest überprüfen, indem er dieselbe Berechnung durchführt und das Ergebnis mit dem vom Client erhaltenen vergleicht.
Bei geschickter Implementierung (RFC 2104[2]) muss der Server das Passwort nicht im Klartext speichern.
Die Berücksichtigung des Zeitstempels vom Server bei der Berechnung des Passwort-Hashs verhindert also, dass Angreifer über unsichere Verbindungen an die direkten Authentifizierungsmerkmale (Passwort) eines Benutzers gelangen können. Würde das Passwort des Benutzers lediglich gehasht, brauchte ein Angreifer nur diesen Hash abzugreifen und könnte sich damit gegenüber einem Server beliebig authentifizieren. Selbst unter Kenntnis des Zeitstempels, den der Server zum Client geschickt hat, gelingt einem Angreifer dies nicht mehr, weil sich der Zeitstempel vom Server bei jedem Authentifizierungsvorgang ändert, der Angreifer aber nicht im Besitz des Passwortes ist, um dieses inklusive des Zeitstempels hashen und selbst an den Server schicken zu können. Es besteht lediglich die Möglichkeit, den Zeitstempel des Servers und den daraus generierten Digest des Clients abzugreifen und mit verschiedenen kryptografischen Attacken, Brute-Force, Dictionary Attack, Rainbow Table usw., ausgehend von Hash und Zeitstempel wieder auf das Klartextpasswort zurück zu schließen. Da dies als sehr aufwändiger Prozesse angesehen wurde, galt CRAM-MD5 als sicher. Replay-Angriffe werden aufgrund der immer neuen, Challenge verhindert, solange diese vollständig zufällig ist.
Der Client verifiziert den Server nicht. Da jedoch CRAM-MD5 häufig über TLS ausgeführt wird, ist dies ein geringeres Problem.
Einige Implementierungen speichern das Passwort auf dem Server im Klartext.
Wird ein Verbindungsaufbau abgefangen, ist wie erwähnt ein Offline-Angriff auf das Passwort bspw. mittels Wörterbuchangriff oder Brute-Force möglich. Dies ist selten vermeidbar, jedoch wird in modernen Algorithmen mittels Key Stretching das Erraten des Passworts erschwert. Hingegen ist MD5-CRAM leicht und schnell zu berechnen, was einen Angriff mit relativ wenig Rechenleistung ermöglicht.
Das Protokoll ist anfällig gegen aktive Man-in-the-middle-Angriffe, da es auf Client und Server kein gemeinsames bekanntes Geheimnis gibt. Ein Angreifer kann eine Verbindung zum Server eröffnen, eine Challenge erhalten, diese an den Client weiterleiten und die Client-Antwort an Server weiterleiten. Danach kann dieser alle Nachrichten des Clients ignorieren und stattdessen im Namen des Clients weiter agieren.
Die Sicherheit des Verfahrens basiert allgemein auf HMAC-MD5, welches zwar bisher nicht direkt von den Angriffen gegen MD5 betroffen ist, für neue Protokolle jedoch nicht mehr empfohlen wird.[3]
Im November 2008 wurde vorgeschlagen das Protokoll als veraltet zu markieren. Es wurde empfohlen, dieses nicht mehr ohne zusätzliche Sicherungsmaßnahmen (wie TLS) zu verwenden. In Verbindung mit TLS soll stattdessen auf SASL PLAIN gewechselt werden und „Salted Challenge Response Authentication Mechanism“ statt CRAM-MD5 genutzt werden.[4]