Sichere Server Authentifizierung mit SASL Im heutigen Zeitalter wird es immer wichtiger, seine Passwörter für andere Internetteilnehmer zu verbergen. Gerade bei der Kommunikation zwischen Ihrem Computer und Ihrem Email-, FTP- oder News-Server sind Sie einer hohen Gefahr ausgeliefert. Hacker oder andere Leute, die es auf Ihre Verbindungsdaten abgesehen haben, benutzen Tracing-Programme um in Ihre Verbindung zu lauschen. Doch da gibt es Abhilfe
Autor:  Matthias Volk	Bewertung:     [ Jetzt bewerten ]	Views:  17.896

Geben Sie hier Ihre persönliche Bewertung ab! Anzahl Bewertungen bisher: 6 Bewertung insgesamt: sehr gut Durchschnittliche Bewertung: 4.7 von 5 Sternen

sehr gut     gut     nützlich     mittelmäßig     mangelhaft

Im heutigen Zeitalter wird es immer wichtiger, seine Passwörter für andere Internetteilnehmer zu verbergen. Gerade bei der Kommunikation zwischen Ihrem Computer und Ihrem Email-, FTP- oder News-Server sind Sie einer hohen Gefahr ausgeliefert. Hacker oder andere Leute, die es auf Ihre Verbindungsdaten abgesehen haben, benutzen Tracing-Programme um in Ihre Verbindung zu lauschen. Doch da gibt es Abhilfe.

Weltweit anerkannt, doch nur selten genutzt gibt es einen sicheren Weg, Ihre Verbindungsdaten vor solchen Angriffen zu schützen. Wenn man kein SSL zur Verfügung hat, kommt SASL (Simple Authentication and Security Layer) zum Einsatz. Mit dieser Methode können Sie Ihre Daten sicher verbergen.

Das Prinzip:
Das Prinzip jeder Server Kommunikation ist fast immer ähnlich. Der Client meldet sich mit einem Benutzernamen an und sendet anschließend das Passwort. Doch es geht auch anders. In diesem Workshop lernen Sie, wie Sie mittels verschiedenen Hashing und cryptografischen Mechanismen verhindern können, dass ein "Lauscher" Ihr Passwort lesen kann und es ggf. selbst verwendet. Bei fast allen sicheren Authentifizierungsmethoden wird das Hashing benutzt. Hashing ist eine Art Prüfsummenberechnung von Daten, die nicht wieder zurückberechnet werden kann. Einigen von Ihnen sind bestimmt schon mal die Worte MD5, SHA oder MessageDigest vor die Linse gekommen. Im folgenden Workshop gehen wir näher darauf ein.

Das benötigen Sie:
Der Workshop zeigt anhand eines Mail Servers POP3/SMTP, wie die sichere Anmeldung durchgeführt werden kann. Dazu benötigen Sie also einen POP3 und/oder einen SMTP Server. Diesen können Sie von Windows Installieren (IIS - Internet Informations Dienste) oder bei einem Provider Ihrer Wahl erstellen (Web.de, Freenet.de, Gmx.de). Wichtig ist noch zu sagen, dass nicht jeder Server alle Sicherheitsmöglichkeiten nutzt. So kann es sein, dass ein Server die unsichere Standardanmeldung durch User/Pass nicht mehr akzeptiert, dafür aber eine sichere wie Digest-MD5. Es kann aber auch umgekehrt sein. Vielleicht müssen Sie mehrere Server antesten, bis Sie alle Features testen bzw. nutzen können. Außerdem benötigen wir die besagten Hashing und cryptografischen Mechanismen, zusätzlich noch einen Base64 En-/Decoder. Diese Mechanismen sind sehr schwer umzusetzen und ein Mechanismus allein könnte schon einen ganzen Workshop füllen. Darum wollen wir uns nicht weiter darum kümmern und benutzen die  EncodeClasses ActiveX-DLL, die auch hier im Archiv angeboten wird. Diese Version können Sie 30 Tage lang kostenlos testen.

Was der Wokshop bietet:
Damit Sie einen Vergleich "Geschwindigkeit zu Sicherheit" haben, stellen wir Ihnen in diesem Workshop die Authentifizierungsmechanismen User/Pass, Login, Plain, APop, Cram-MD5, Digest-MD5, NTLM und OTP (One Time Password hat S-Key abgelöst) vor. Jede Anmeldung hat ihren eigenen Vorteil und wird auf den folgenden Seiten näher beschrieben. Diese Mechanismen werden von vielen Servern genutzt, nicht nur von SMTP/POP Diensten, auf die hier eingegangen wird. Durch einige Anpassungen kann man diese Mechanismen auch für NNTP, FTP oder andere Dienste nutzen. Auch eine Implementation in eigene Kommunikationssoftware ist bestimmt sehr sinnvoll ! Da der Workshop nicht überdimensional anschwellen soll, blenden wir den Teil für die eigentliche Kommunikation aus. Es gibt im Archiv bereits Workshops, die das beschreiben. Der Download enthält diesen Teil, damit diese Technologie auch getestet werden kann.

Standard Authentifizierung mit User/Pass

Beschreibung:
Diese Methode hängt immer mit dem betreffenden Dienst zusammen und wird nicht in einer einzelnen RFC beschrieben. Für den POP3 Dienst ist dieser z.B. in der  RFC 1939 nachzulesen. Diese Variante der Benutzeranmeldung ist die unsicherste und wird von einigen Servern nicht mehr unterstützt, da das Passwort in Klartext übermittelt wird. Eine Kommunikation sieht folgendermaßen aus:

Status: Verbinde mit Server Server: +OK <27293.1079264416@mx.freenet.de> Client: USER Standardbenutzer Server: +OK user ok Client: PASS geheim Server: +OK User logged in

Das Protokoll funktioniert wie folgt (POP3):

1. Der Client verbindet sich mit dem Server
2. Der Server sendet eine Willkommensnachricht
3. Der Client schickt "User" gefolgt von einem "Leerzeichen" und darauf den Benutzernamen
4. Der Server antwortet, dass entweder der Benutzername nicht akzeptiert wird, oder dass nun das Passwort verlangt wird
5. Der Client sendet "Pass" gefolgt wieder von einer "Leerstelle" und dem dazugehörigen Passwort
6. Der Server benachrichtigt über den Erfolg oder das Scheitern der Anmeldung
7. Der Client ist nun angemeldet und kann ggf. E-Mails abfragen

Resümee:

sehr unsicher

Authentifizierung mit Login

Beschreibung:
Login ist sehr verbreitet und wird auch von Outlook Express verwendet wenn kein SSL aktiviert ist. Dabei ist diese Methode genau so unsicher wie die User/Pass Variante, da das Passwort auch in Klartext übertragen wird. Es wird lediglich Base64 codiert, was aber keinerlei Sicherheit bietet. Auth Login wird in Internet-Draft  SASL-Login beschrieben. Ein Verbindungsprotokoll kann folgendermaßen aussehen:

Server: 220 Mail1.KONTENT.De KONTENT ESMTP MailService V2.00 Client: EHLO LonelySuicide666 Server: 250-Mail1.KONTENT.De Server: 250-PIPELINING Server: 250-SIZE 20971520 Server: 250-ETRN Server: 250-AUTH CRAM-MD5 DIGEST-MD5 LOGIN PLAIN OTP Server: 250 8BITMIME Client: AUTH LOGIN Server: 334 VXNlcm5hbWU6 (334 Username Client: U3RhbmRhcmRiZW51dHplcg== (Standardbenutzer) Server: 334 UGFzc3dvcmQ6 (334 Password Client: Z2VoZWlt (geheim) Server: 235 Authentication successful *Anmerkung: Die Klammern inkl. ihres Inhalts sind nicht Bestandteil desProtokolls und dienen nur der Übersicht

Das Protokoll funktioniert wie folgt (SMTP):

1. Der Client verbindet sich mit dem Server
2. Der Server sendet eine Willkommensnachricht
3. Der Client schickt eine Anmeldung "EHLO" oder "HELO" gefolgt von einem "Leerzeichen" und darauf die Clientidentifikation
4. Der Server antwortet und gibt ggf. einen Informationstext aus
5. Der Client sendet "AUTH LOGIN" um die Anmeldung einzuleiten
6. Der Server sendet in Base64 konvertiert, dass er den Benutzernamen erwartet
7. Der Client sendet in Base64 konvertiert den Benutzernamen
8. Der Server sendet in Base64 konvertiert, dass ein Passwort verlangt wird
9. Der Client sendet Base64 konvertiert das Passwort
10. Der Server antwortet mit einer Erfolgsbenachrichtigung
11. Der Client ist verbunden und kann nun ggf. Mails senden

Resümee:

sehr unsicher

sehr langsam, da viele Nachfragen übermittelt werden müssen

Authentifizierung mit Plain

Beschreibung:
Plain wird oft mit dem Kommando "Starttls" verwendet und bietet ohne TLS Kommunikation auch keinerlei Sicherheit, da es das Passwort auch in Klartext übermittelt. Plain wird im  RFC 2595 beschrieben. Ein anderer Vorteil ist allerdings die schnelle Anmeldung, da alle Informationen in einer einzigen Zeile übertragen werden. Eine Plain Anmeldung sieht wie folgt aus:

Server: 220 Mail1.KONTENT.De KONTENT ESMTP MailService V2.00 Client: EHLO LonelySuicide666 Server: 250-Mail1.KONTENT.De Server: 250-PIPELINING Server: 250-SIZE 20971520 Server: 250-ETRN Server: 250-AUTH CRAM-MD5 DIGEST-MD5 LOGIN PLAIN OTP Server: 250 8BITMIME Client: AUTH PLAINU3RhbmRhcmRiZW51dHplcgBTdGFuZGFyZGJlbnV0emVyAGdlaGVpbQ== (Standardbenutzer<vbnullchar>Standardbenutzer<vbnullchar>geheim) Server: 235 Authentication successful *Anmerkung: Die Klammern inkl. ihres Inhalts sind nicht Bestandteil desProtokolls und dienen nur der Übersicht

Das Protokoll funktioniert wie folgt (SMTP):

1. Der Client verbindet sich mit dem Server
2. Der Server sendet eine Willkommensnachricht
3. Der Client schickt eine Anmeldung "EHLO" oder "HELO" gefolgt mit einem "Leerzeichen" und darauf die Clientidentifikation
4. Der Server antwortet, und gibt ggf. einen Informationstext aus
5. Der Client sendet "AUTH LOGIN" gefolgt von einem Leerzeichen und den Base64 codierten Benutzerinformationen (Benutzername, Account, Passwort, jeweils getrennt durch ein 0-Zeichen)
6. Der Server benachrichtigt über den Erfolg der Anmeldung
7. Bei der erfolgreichen Anmeldung kann der Client nun E-Mails senden

Resümee:

sehr unsicher

sehr schnell

Authentifizierung mit Apop

Beschreibung:
Apop, wie der Name schon sagt, ist nur auf POP3 Servern verfügbar. Dieser Mechanismus zählt schon zu den sicheren Methoden und bedient sich dem Hashing. Außerdem ist diese Variante sehr schnell, da nur wenige Zeilen übertragen werden müssen. Apop ist in der  RFC 1939 beschrieben und ein Protokoll sieht folgendermaßen aus:

S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us> C: APOP Standardbenutzer c4c9334bac560ecc979e58001b3e22fb S: +OK maildrop has 1 message (369 octets)

Das Protokoll funktioniert wie folgt (POP3):

1. Der Client verbindet sich mit dem Server
2. Der Server sendet eine Willkommensnachricht (wird APOP unterstützt, ist in der Willkommensnachricht <Daten> vorhanden)
3. Der Client meldet sich mit "APOP" gefolgt von einem Leerzeichen, dem Benutzernamen, noch einem Leerzeichen und einer Prüfsumme an
4. Der Server sendet den Status des Erfolgs
5. Der Client kann bei Erfolg nun die E-Mails abrufen

Details:
Um die Prüfsumme zu ermitteln, benötigt man einen MD5-Algorithmus. Dazu wird die Hex-Prüfsumme (Lowercase) aus dem TimeStamp (ggf. auch Message-ID) und dem Passwort des Benutzers berechnet. Der TimeStamp wird in der Willkommensnachricht zwischen "<" und ">" übermittelt und garantiert somit bei jeder Anmeldung eine andere Prüfsumme. Dabei ist es nahezu unmöglich, aus dem "Hash" das Passwort zu extrahieren.

Resümee:

Nur bei POP Servern vorhanden		sicher
		sehr schnell
		Bei der Anmeldung kann schon ermittelt werden, ob APOP unterstützt wird

Authentifizierung mit Cram-MD5

Beschreibung:
Cram-MD5 (Challenge-Response Authentication Mechanism) ist sehr verbreitet und wird von nahezu jedem Server unterstützt, nicht nur seine Einfachheit und seine Sicherheit überzeugen, sondern auch die schnelle Anmeldung. Cram-MD5 wird in der  RFC 2195 beschrieben und baut sich wie folgt auf:

Server: +OK mail1.kontent.de Cyrus POP3 v2.1.11 server ready<3861763505.1079269067@mail1.kontent.de> Client: auth cram-md5 Server: + PDI1Mzg0OTQwOTEuNTUyNzMxMEBtYWlsMS5rb250ZW50LmRlPg==(<2538494091.5527310@mail1.kontent.de>) Client: U3RhbmRhcmRiZW51dHplciBlMmE3ZTk4YjIzMTczODVhZTI2MTY2M2E4MzI2NDcxZg== (Standardbenutzer e2a7e98b2317385ae261663a8326471f) Server: +OK Maildrop locked and ready *Anmerkung: Die Klammern inkl. ihres Inhalts sind nicht Bestandteil desProtokolls und dienen nur der Übersicht

Das Protokoll funktioniert wie folgt (POP3):

1. Der Client verbindet sich mit dem Server
2. Der Server sendet eine Willkommensnachricht
3. Der Client meldet sich mit "AUTH CRAM-MD5" an
4. Der Server sendet einen Base64 konvertierten Message-ID der bei jeder Anmeldung anders sein muss
5. Der Client sendet Base64, konvertiert den Benutzernamen gefolgt von einem Leerzeichen und einem Hash-wert, resultierend aus Passwort und Message-ID
6. Der Server antwortet mit dem Erfolg der Anmeldung
7. Der Client kann nun Mails abrufen/senden

Details:
Um die Hash-Prüfsumme zu ermitteln, benötigt man einen MD5-Alorithmus. Außerdem sollte der Algorithmus in der Lage sein, HMAC-Prüfsummen zu erstellen. Bei dieser Variante wird aus dem Message-ID eine HMAC-Prüfsumme mit Hilfe des Passworts des Users erstellt. Dadurch, dass die Message-ID bei jeder Anmeldung anders ist, kann sichergestellt werden, dass ein Extrahieren des Passworts, ähnlich wie bei APOP, nicht möglich ist.

Resümee:

sehr sicher

sehr schnell

sehr verbreitet

Authentifizierung mit Digest-MD5

Beschreibung:
Digest-MD5 ist auch sehr verbreitet, kommt aber nicht so häufig vor wie z.B. Cram-MD5. Bei Digest-MD5 kann der Server durch bestimmte Angaben die Sicherheit der Verschlüsselung etwas manipulieren, je nach dem, wie sicher die Anmeldung durchgeführt werden soll. Außerdem können bei dieser Variante weitere Details der Verbindung abgefragt werden, die für den Server evtl. interessant sind. Digest-MD5 wird in der  RFC 2831 beschrieben und gliedert sich wie folgt:

Server: +OK mail1.kontent.de Cyrus POP3 v2.1.11 server ready<2114356973.1079269879@mail1.kontent.de> Client: auth digest-md5 Server: +bm9uY2U9ImhneERmV1RLeUIwamZUYXFuNEdnczdxV0hBOTBUV0R5bkNPdjNSTG92UzA9IixyZWFsbT0ibWFpb DEua29udGVudC5kZSIscW9wPSJhdXRoLGF1dGgtaW50LGF1dGgtY29uZiIsY2lwaGVyPSJyYzQtNDAscmM0LTU2LHJjNCx kZXMsM2RlcyIsY2hhcnNldD11dGYtOCxhbGdvcml0aG09bWQ1LXNlc3M= (nonce="hgxDfWTKyB0jfTaqn4Ggs7qWHA90TWDynCOv3RLovS0=",realm="mail1.kontent.de",qop="auth,auth-int,auth-conf", cipher="rc4-40,rc4-56,rc4,des,3des",charset=utf-8,algorithm=md5-sess) Client: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iU3RhbmRhcmRiZW51dHplciIscmVhbG09Im1haWwxLmtvbnRlbnQuZGU iLG5vbmNlPSJoZ3hEZldUS3lCMGpmVGFxbjRHZ3M3cVdIQTkwVFdEeW5DT3YzUkxvdlMwPSIsbmM9MDAwMDAw MDEsY25vbmNlPSJoZ3hEcmdqUlN2QXV4ckNaMXdXNzJENldndURrY1NsblFSeXlqOTROcThPZyIsZGlnZXN0LXVya T0ic21wdC9zbXRwLmtvbnRlbnQuZGUiLHJlc3BvbnNlPTlhMDU0NmJhZTBmM2VkOTI4YTdlZDYxZmJiOWI2YmFiLHF vcD1hdXRo (charset=utf-8,username="Standardbenutzer",realm="mail1.kontent.de", nonce="hgxDfWTKyB0jfTaqn4Ggs7qWHA90TWDynCOv3RLovS0=",nc=00000001, cnonce="hgxDrgjRSvAuxrCZ1wW72D6WguDkcSlnQRyyj94Nq8Og",digest-uri="smpt/smtp.kontent.de", response=9a0546bae0f3ed928a7ed61fbb9b6bab,qop=auth) Server: + cnNwYXV0aD1hM2RkYzFkM2E1OTcxNmQ4YjJhODEzYzViNGU5MGRlNg== (rspauth=a3ddc1d3a59716d8b2a813c5b4e90de6) *Anmerkung: Die Klammern inkl. ihres Inhalts sind nicht Bestandteil desProtokolls und dienen nur der Übersicht

Das Protokoll funktioniert wie folgt (POP3):

1. Der Client verbindet sich mit dem Server
2. Der Server sendet eine Willkommensnachricht
3. Der Client meldet sich mit "AUTH DIGEST-MD5" an
4. Der Server sendet Base64 konvertiert die Initialparameter
5. Der Client sendet Base64 konvertiert die Ausgabeparameter inkl. dem berechnetem Response-Code
6. Der Server antwortet ebenfalls mit einem Response-Code, falls die Anmeldung erfolgreich ist
7. Der Client kann nun Mails abrufen/senden

Details:
Für eine Digest-MD5 Anmeldung benötigt man mindestens den MD5-Algorithmus. Kurz umrissen funktioniert Digest-MD5 folgendermaßen: Der Server sendet Parameter die dem Clienten zur Auswahl stehen. In den Parametern ist ein Parameter namens "nonce". Der Client wählt dann die entsprechenden Parameter aus, berechnet einen Response-Hash aus dem Server-Nonce und einem selbst erstellten Nonce. Anschließend überprüft der Server die Daten, sendet ebenfalls einen Response-Code, den der Client zum Vergleich noch prüfen könnte. Weitere Details können Sie aus dem Quelltext des downloadbaren Beispielprogramms entnehmen.

Resümee:

langsam		sehr sicher
zu komplex		verbreitet

Authentifizierung mit NTLM

Beschreibung:
NTLM (NT / LanManger) wird ausschließlich in der Windowswelt verwendet, das aber auch nur noch selten, da neuere Verfahren dies schon abgelöst haben. Nichts desto trotz ist NTLM relativ sicher und bedient sich außer dem Hashing auch noch der DES-Cryptographie. NTLM wird in keinem RFC beschrieben, Informationen dazu sind aber  hier erhältlich. Das Protokoll baut sich wie folgt auf:

Server: 220 lonelysuicide Microsoft ESMTP MAIL Service, Version:6.0.2600.1106 ready at Sun, 14 Mar 2004 14:40:48 +0100 Client: EHLO LonelySuicide666 Server: 250-lonelysuicide Hello [127.0.0.1] Server: 250-AUTH GSSAPI NTLM LOGIN Server: 250-AUTH=LOGIN Server: 250-SIZE 2097152 Server: 250-PIPELINING Server: 250-DSN Server: 250-ENHANCEDSTATUSCODES Server: 250-8bitmime Server: 250-BINARYMIME Server: 250-CHUNKING Server: 250-VRFY Server: 250 OK Client: AUTH NTLM TlRMTVNTUAABAAAAA7IAAAkACQApAAAACQAJACAAAABMT0NBTEhPU1RMT0NBTEhPU1Q= (keine anzeigbaren daten) Server: 334 TlRMTVNTUAACAAAAAAAAADAAAAABggAAC8Kk9RAi7gAAAAAAAAAAAAAAAAAwAAAA (keine anzeigbaren daten) Client: TlRMTVNTUAADAAAAGAAYAIQAAAAYABgAnAAAABIAEgBAAAAAIAAgAFIAAAASABIAcgAAAAAAAAC0AA AAAYIAAEwATwBDAEEATABIAE8AUwBUAFMAdABhAG4AZABhAHIAZABiAGUAbgB1AHQAegBlAHIATABPAEMAQQ BMAEgATwBTAFQAnhjgRJDJfX3TLxf1OQIlOg0CIWFehP0GhHCBSftFax5KjGgIzaeDkfODqrvQ/Uck (keine anzeigbaren daten) Server: 235 2.7.0 Authentication successful *Anmerkung: Die Klammern inkl. ihres Inhalts sind nicht Bestandteil desProtokolls und dienen nur der Übersicht

Das Protokoll funktioniert wie folgt (SMTP):

1. Der Client verbindet sich mit dem Server
2. Der Server sendet eine Willkommensnachricht
3. Der Client schickt eine Anmeldung "EHLO" oder "HELO", gefolgt von einem "Leerzeichen" und darauf die Clientidentifikation
4. Der Server antwortet, und gibt ggf. einen Informationstext aus
5. Der Client sendet "AUTH NTLM", gefolgt von einem Leerzeichen und dem Base64 codierten NTLM Challange-1
6. Der Server bestätigt den Challang-1 und erwidert mit Challange-2, der den Server-Nonce enthält
7. Der Client berechnet das NT und LanManger Passwort aus dem Server-Nonce und sendet Challange-3
8. Der Server benachrichtigt den Clienten über den Erfolg der Anmeldung
9. Der Client kann nun ggf. Mails senden/abrufen

Details:
Für die NTLM Anmeldung benötigt man den MD5-Hashalgorithmus und das Verschlüsselungsverfahren DES. Der Client beginnt die Anmeldung mit dem Senden einer Base64 konvertierten Struktur, die den zu erreichenden Service enthält. Anschließend sendet der Server eine Base64 konvertierte Struktur, die bestätigt, dass der Service erreichbar ist. Außerdem beinhaltet diese Struktur einen Server-Nonce, die Grundlage für weitere Berechnungen ist. Zu guter Letzt berechnet der Client die Passwörter für NT und den LanManager, füllt die Struktur mit den benötigten Informationen und sendet diese zum Server. Programmiertechnische Informationen entnehmen sie bitte dem Beispielprojekt.

Resümee:

langsam		sicher
Nur bei Microsoft Servern
veraltet

Authentifizierung mit OTP

Beschreibung:
OTP (One Time Passwort) wird immer beliebter. Dieses Verfahren hat das veraltete S-Key abgelöst und glänzt durch eine "lesbare" Passworteingabe. Lediglich die hohe Prozessorauslastung ist negativ zu bewerten. OTP wird im  RFC 2289 beschrieben und folgende Protokolle stellen eine Anmeldung dar:

Server: +OK mail1.kontent.de Cyrus POP3 v2.1.11 server ready<3693978166.1079273942@mail1.kontent.de> Client: auth otp U3RhbmRhcmRiZW51dHplcg==(Standardbenutzer) Server: + b3RwLW1kNSA0OTkgYWJjZGVmZw== (otp-md5 499abcdefg) Client: TEVFIEhVR08gU0tFVyBTRUxGIE9SRSBTQUQ= (LEE HUGOSKEW SELF ORE SAD) Server: +OK Maildrop locked and ready Server: +OK mail1.kontent.de Cyrus POP3 v2.1.11 server ready<3693978166.1079273942@mail1.kontent.de> Client: auth otp U3RhbmRhcmRiZW51dHplcg==(Standardbenutzer) Server: + b3RwLXNoYTEgMzM3IGFiY2RlZmcgZXh0 (otp-sha1 337abcdefg ext) Client: aGV4OkRDQTI3RkFBQUU1MjkwNUU=(hexCA27FAAAE52905E) Server: +OK Maildrop locked and ready Server: +OK mail1.kontent.de Cyrus POP3 v2.1.11 server ready<3693978166.1079273942@mail1.kontent.de> Client: auth otp U3RhbmRhcmRiZW51dHplcg==(Standardbenutzer) Server: + b3RwLXNoYTEgMzM3IGFiY2RlZmcgZXh0 (otp-sha1 337abcdefg ext) Client: d29yZDpTSU5HIEZJTiBUSElTIEJPT00gTU9EIE9MRA== (word:SINGFIN THIS BOOM MOD OLD) Server: +OK Maildrop locked and ready *Anmerkung: Die Klammern inkl. ihres Inhalts sind nicht Bestandteil desProtokolls und dienen nur der Übersicht

Das Protokoll funktioniert wie folgt (SMTP):

1. Der Client verbindet sich mit dem Server
2. Der Server sendet eine Willkommensnachricht
3. Der Client sendet "AUTH OTP", gefolgt von einem Leerzeichen und dem Benutzernamen
4. Der Server sendet Base64 konvertiert die OTP-Paremeter die zur Berechnung verwendet werden sollen
5. Der Client sendet Base64 konvertiert den berechneten OTP-Wert
6. Der Server benachrichtigt den Clienten über den Erfolg der Anmeldung
7. Der Client kann nun ggf. Mails senden/abrufen

Details:
Bei der OTP Berechnung wird das Passwort und der übermittelte "Seed" für eine Bestimmte Anzahl (Sequence) oft gehasht, dazu wird MD4, MD5 oder SHA1 verwendet. Dies kann mitunter sehr prozessorauslastend sein. Ist OTP in der erweiterten Version verfügbar ("ext" ist vorhanden), so kann anstatt der "Wort Kalkulation" auch ein Hexwert angegeben werden. Die Wörter werden anhand einer 2048 Bytes großen Tabelle aus dem OTP-Hash ermittelt (siehe Beispielprojekt).

Resuemee:
+ sehr sicher
- prozessorauslastend
+ Passwort-Hash ist lesbar in der "Wortform"

Resümee:

prozessorauslastend		sehr sicher
		Passwort-Hash ist lesbar in der "Wortform"

Portabilität

Die gezeigten Mechanismen beziehen sich in diesem Workshop immer nur auf einen Server-Dienst. Um alle Varianten auf POP3/SMTP zu testen, downloaden Sie bitte das Beispielprojekt. Natürlich können diese Verfahren auch bei anderen Servermodellen verwendet werden, lediglich ein paar Anpassungen müssen für das jeweilige Protokoll vorgenommen werden. Im Grunde werden immer die selben Informationen transportiert.

Wer nun meint, dass dies nicht alles sei, hat Recht ! Außer den hier beschriebenen Mechanismen gibt es noch die sehr bedeutsamen Mechanismen Kerberos und GSSAPI. Diese Verfahren sind wohl die sichersten SASL Verfahren, zählen aber auch zu den komplexesten. Wer wirklich auf 100% gehen möchte, sollte sich mit der SSL/TLS Kommunikation befassen; außer einer sicheren Anmeldung bieten diese Verfahren eine Verbindungsverschlüsselung. Vielleicht konnte dies dem einen oder anderen ein paar Fragen beantworten, hoffentlich ist nun einiges "sicherer".

Download-Links:
 EncodeClasses ActiveX-DLL