MD2 RFC 1319 MD4 RFC 1320 MD5 RFC 1321 SHA1 RFC 3174
Grundlage sind die RFC 1320 und 1321. Sie definierten ein MD4 und MD5 welche als Ausgabe einen MD4 bzw. MD5 als Digest liefern.
MD4 besitzt inzwischen nur noch historischen Wert. Im Jahre 2001 wurde auch SHA1 in RFC 3174 standardisiert. SHA1 liefert ebenfalls einen Digest. SHA1 liefert ebenfalls einen Digest, der im Gegensatz zu MD5 mit wesentlich weniger Konstanten auskommt und deshalb theoretisch sicherer ist als MD5. Gegen SHA1 ist bisher auch, im Gegensatz zu MD5, kein theoretischer Angriff bekannt.. SHA1 liefert einen 160-Bit-Digest (20 Byte), MD5 hingegen nur einen 128-Bit-Digest (16 Byte). Der Angriff gegen MD5 ist ausschließlich theoretischer Natur, da es nicht ausreichend Rechenzeitkapazität gibt ihn zu brechen. Setzt man die Lebensdauer von MD5 in ein Verhältnis zur Lebensdauer von Passwörtern, ist MD5 auch in den nächsten Jahrzehnten sicher. Bei SHA1 muss man bezüglich der Sicherheit ebenfalls bedenken, dass er in allen Aspekten noch nicht so gut untersucht ist wie MD5. Meiner Einschätzung nach ist der Unterschied zwischen MD5 und SHA1 bezüglich Sicherheit eher paranoid und eine Glaubensfrage. Ein weiterer Aspekt bezüglich der Sicherheit dieser Verfahren ist die praktische Implementation der Hash Algorithmen. Um die Hash-Algorithmen auch für kurze Textfetzen, wie zum Beispiel Passwörter, unangreifbar zu machen, wird der jeweilige Hash-Algorithmus im HMAC-Verfahren doppelt auf das Passwort angewendet. Die Formel hierfür lautet:
ipad = String gefüllt mit dem Byte 0x36 entsprechend der Länge des Hash opad = String gefüllt mit dem Byte 0x5C entsprechend der Länge des Hash K = Das zu sichernde Passwort H = Hash-Funktion, zum Beispiel MD5 oder SHA1 Hash = H(K XOR opad, H(K XOR ipad, text))
Weiterhin ist entscheidend, ob nur der Server den Client oder auch der Client den Servern authentifiziert, um einen "man in the middle”-Angriff zu vermeiden. Das CRAM-Verfahren authentifiziert nur den Client, nicht aber den Server. Erst das DIGEST-Verfahren(z.B. DIGEST-MD5) ermöglicht auch eine Authentifizierung des Servers.
Um das Login sicherer zu gestalten, wurden im Laufe der Zeit unterschiedliche Methoden für die einzelnen Protokolle entwickelt:
IMAP4-Auth RFC 2060 POP-Auth RFC 1734 POP-SASL-AUTH RFC 2449 APOP RFC 1939 HTTP-Auth RFC 2069 SMTP-Auth RFC 2554 SMTP after POP3 (nicht standardisiert)
Diese Protokolle nutzen unterschiedliche Methoden für das sichere Login, aber teilweise die selben Hash-Funktionen und Key-Verwaltungsverfahren.
HMAC RFC 2104 CRAM RFC 2195 SESS RFC 2617 SASL RFC 2222
Zum Beispiel verwendet APOP den MD5-Digest (nicht verwechseln mit dem SASL-Verfahren MD5-DIGEST). Zu Beginn wurden das unverschlüsselte "LOGIN"-Verfahren und mehr oder minder sichere Verfahren wie KERBEROS, S/Key und GSSAPI verwendet. Für POP und IMAP wurde dann erstmalig das für beide Protokolle gemeinsame HMAC-Verfahren eingeführt, welches von CRAM verwendet wird. CRAM definiert selber nur CRAM-MD5, da zu diesem Zeitpunkt SHA1 noch nicht als RFC standardisiert war. Für HTTP wurde parallel ein weiterentwickeltes Verfahren namens MD5-SESS eingeführt, was ebenfalls für andere Hash-Funktionen wie SHA1 vorbereitet war, ohne sie selbst zu definieren.
Um dem Wildwuchs der einzelnen Verfahren und Hash-Methoden einen vernünftigen Rahmen zu geben und das vom jeweiligen Server angebotene Verfahren automatisch auswählen zu können wurde dann mit SASL ein Auswahlverfahren für Login-Mechanismen eingeführt. Dieser RFC definierte sofort die SASL-Mechanismen für S/Key, KERBEROS und GSSAPI und übernahm LOGIN und CRAM-MD5 von IMAP/POP. Beim LOGIN-Mechanismus handelt es sich um ein primitives, unverschlüsseltes Verfahren, welches nur im Notfall verwendet werden sollte. In SMTP wurde SASL mit RFC 2554 übernommen. In RFC 2449 wurde SASL endgültig für POP3 definiert und in den CAPA-Befehl verlagert. Bis zu diesem Zeitpunkt wurde die Authentifikation bei POP3, wie bei IMAP, im AUTH-Befehl platziert. Es wird heute noch von vielen POP3-Servern die Authentifikation ohne SASL-Mechanismus angeboten. Inzwischen wurden weitere SASL-Mechanismen standardisiert, welche für alle Protokolle gültig sind. Das sind:^
| PLAIN und EXTERNAL | RFC 2595 | TLS/SSL unverschlüsselt, da SSL an sich schon sicher ist |
| SECURID | RFC 2808 | für RSA-Chipkarten-Anwendungen. SECURID ermöglicht auch andere HASH-Funktionen als z.B. SHA1 |
| DIGEST-MD5 und MD5-SESS | RFC 2831 | übernimmt die Digest-Methoden von HTTP und macht HTTP konform zu SASL. DIGEST ermöglicht auch andere HASH-Funktionen als MD5, z.B. SHA1. Dieses Verfahren ermöglicht auch den Server zu authentifizieren |
| OTP-MD5 | RFC 2444 | für "One Time Passwords". OTP ermöglicht auch andere HASH-Funktionen als MD5 z.B. SHA1 |
| ANONYMOUS | RFC 2245 | für anonymes Login |
| ISO/IEC 9798-3 | RFC 3163 | für die Benutzung von Zertifikaten als Ausweis fürs Login. Basiert auf der PKI-Infrastruktur |
Dazu kommen dann die schon bekannten Mechanismen
| KERBEROS | RFC 2222 | Für homogene Umgebungen. basierend auf Ticketserver |
| S/Key | RFC 2222 | Für auf einander folgende abhängige Keys. Das Verfahren ist nur schwer handhabbar bei öffentlichen Servern und eher gut für Intranetze |
| LOGIN | RFC 2222 | Klartext-LOGIN |
| GSS-API | RFC 2222 | Für Anwender-Applikationen in Verbindung mit Kerberos |
| CRAM-MD5 | RFC 2195 | Weit verbreitetes praktisch sicheres Verfahren. CRAM ist auch mit SHA1 als Hash-Algorithmus möglich. Methodischer Nachfolger ist DIGEST-SHA1 |
Eine Ausnahme bei den Authentifizierungsverfahren ist das "SMTP after POP3"-Verfahren. Bei diesem Verfahren wird ein dem eigentlichen SMTP-Login vorhergehender erfolgreicher POP3-Zugriff zur Authentifikation verwendet. Es ist im eigentlichen Sinne kein selbstständiges Authentifizierungsverfahren, sondern die Mitverwendung des Authentifizierungsverfahren eines anderen Protokolls. Dieses Verfahren besitzt erhebliche Sicherheitsmängel und sollte nach Möglichkeit nicht mehr verwendet werden.
Folgende Authentifikationsverfahren sind an allen lokalen Servern des Hamsters möglich:
LOGIN, CRAM-MD5, DIGEST-MD5, CRAM-SHA1, PLAIN
Der Mechanismus LOGIN ist unsicher und sollte nach Möglichkeit nicht verwendet werden. Er lässt sich im Setup-Menü aller lokalen Server abschalten. Der Mechanismus PLAIN kann nur zusammen mit dem SSL-Verfahren verwendet werden. Für den lokalen POP3-Server kann auch POP3-Auth ohne SASL-Mechanismus und das APOP-Verfahren zur Authentifikation verwendet werden. Für den lokalen SMTP-Server kann als Authentifikationsverfahren auch das "SMTP after POP3"-Verfahren verwendet werden. Eine gemeinsame Nutzung dieses Verfahrens mit SMTP-Auth ist technisch bedingt nicht möglich.
Allgemein ist aber von der Verwendung des "SMTP after POP3"-Verfahrens aus Sicherheitsgründen abzuraten.
Für die Authentifikation des Hamsters bei den Servern der Provider können folgende Verfahren verwendet werden:
LOGIN, CRAM-MD5, DIGEST-MD5, CRAM-SHA1, PLAIN
Der Mechanismus LOGIN ist unsicher und sollte nach Möglichkeit nicht verwendet werden. Um die Verwendung dieses unsicheren Verfahren zu vermeiden, lässt sich im Setup-Menü der externen Server bei der Passworteingabe ein sicheres Authentifizierungsverfahren, wie zum Beispiel CRAM-MD5, erzwingen. Der Mechanismus PLAIN kann nur zusammen mit dem SSL-Verfahren verwendet werden. Das "SMTP after POP3"-Verfahren kann mittels eines Scriptes nach folgenden Beispiel realisiert werden:
HamFetchMail( <server> ) HamWaitIdle HamSendMail( <server> )
Allgemein ist aber von der Verwendung des "SMTP after POP3"-Verfahrens aus Sicherheitsgründen abzuraten.
Für Verbindungen zu POP3-Servern kann das APOP-Verfahren verwendet werden. Um die Verwendung eines bestimmten Login-Verfahrens zu erzwingen kann dem Passwort der Name des jeweiligen Verfahrens, gefolgt von einem Doppelpunkt, vorangestellt werden. Zulässige Präfixe sind:
| PASS: | Klartext-Passwort |
| APOP: | POP3-APOP Verfahren |
| LOGIN: | LOGIN-Verfahren (Klartext) |
| PLAIN: | SSL-PLAIN-Verfahren (Klartext innerhalb eines SSL-Tunnels) |
| AUTH: | Auth-Verfahren für SMTP oder POP3 erzwingen |
| SASL: | SASL-Auth-Verfahren für SMTP oder POP3 erzwingen |
| CRAM-MD5: | CRAM-MD5-Verfahren |
| DIGEST-MD5: | DIGEST-MD5-Verfahren |
| CRAM-SHA1: | CRAM-SHA1-Verfahren |
Achtung: Die Präfixe müssen groß geschrieben werden!