# POP3 und Passwörter



## anonym (28. Jul 2010)

Hallo Leute, 

ich implementiere gerade das POP3- Protokoll. Das ist notwendig, weil ich einen Mailserver brauche, der sich in ein vorhandenes Nutzerverwaltungssystem integriert und ich leider keine Implementierung finde, die mir das erlaubt. 
Mein Problem ist folgendes: 

POP3 kennt zwei Authentifizierungsmechnismen. 

Der Erste (USER und PASS- Befehle) überträgt das Passwort in Klartext. In der Implementierung kein Problem, aber sicherheitsmäßig kritisch. 

Der Zweite (APOP) erhält den Nuternamen und einen md5- Hash von Passwort und einem vorher vom Server festgelegten String (die RCF empfiehlt was aus Hostname, Prozessid und einem Timestamp zu bauen). Das wird dann verkettet als <[SERVERWERT]>[PASSWORT], also wenn das Passwort secret ist und der Server 1234567 (was nicht dem RFC- Vorschlag entspricht, es ist halt ein Beispiel) gesagt hat: 
<1234567>secret
Das wird dann gehashed und zurückgesendet. RFC 1460 (POP3) schlägt vor, der Server möge diesen String seinerseits konstruieren und hashen, um ihn prüfen zu können. 
Nun speichert der, wie gesagt vorhandene, Authentifizierungsmechnismus leider nur Hashwerte der Passwörter. 
Wie kann ich den das jetzt verifizieren?


----------



## XHelp (28. Jul 2010)

Ich weiß zwar nicht so ganz genau wo die Frage ist bzw was die Vorgeschichte zu bedeuten hat, aber ich nehme mal an du willst folgendes wissen:
- Du kriegst ein MD5-Hash von Kennwort und willst wissen, ob der Benutzer das richtige Kennwort gehasht hat.

Dann bildest du auf dem Server ebenfalls den Hash vom Passwort und vergleichst die Werte.

P.S. Bist du dir Sicher, dass du POP nachbauen willst? oO


----------



## anonym (28. Jul 2010)

Nein, ich will POP3 nicht nachbauen. Sag mir eine gute, open source Implementierung und ich verwende sie. 


Und: Nein, ich kann nicht einfach serverseitig auch den Hash bilden und vergleichen. Ich habe nämlich: 

Serverseitig einen Wert, sagen wir "123456", der wird an den Client übertragen. Ebenfalls Serverseitig den md5- Hash des Passworts (sagen wir "secret")

Clientseitig das Passwort ("secret") und gerade vom Server den Wert "123456" bekommen. 
Der Client baut dann
<123456>secret
und bildet davon den md5- Hash. Den bekommt der Server. 

Der Server hat jetzt also den md5- Hash des Passworts und den md5- Hash von <123456>secret. Nun ist der md5- Hash vo "secret" (als der des Passworts) was anderes als der von "<123456>secret". Einfach es vergleichen bringt mich also nicht weiter. 

Was kann ich dann machen?


----------



## mvitz (28. Jul 2010)

Wie wäre es folgendermaßen:

1) Client hasht das Passwort --> hash(secret)
2) anschließend verkettet es den festgelegten String und den vorher gebildeten hash --> <123456>hash(secret)
3) dieser neue Wert wird anschließend nochmal gehashed und an den Server übertragen --> hash(<123456>hash(secret))

Der Server kann nun, da er den hash vom PW schon hat einfach direkt bei Schritt 2 anfangen.


----------



## XHelp (28. Jul 2010)

anonym hat gesagt.:


> Serverseitig einen Wert, sagen wir "123456", der wird an den Client übertragen. Ebenfalls Serverseitig den md5- Hash des Passworts (sagen wir "secret")



Serverseitig liegt nicht der Hash des Passwortes, sondern das Passwort. Und wo ist das Problem aus dem Server "<123456>echtesPasswort" zu hashen?


----------



## mvitz (28. Jul 2010)

XHelp hat gesagt.:


> Serverseitig liegt nicht der Hash des Passwortes, sondern das Passwort. Und wo ist das Problem aus dem Server "<123456>echtesPasswort" zu hashen?



Ich hoffe doch nicht, Passwörter sollten Server seitig immer nur als Hash gespeichert und niemals als Klartext abgelegt werden.


----------



## XHelp (28. Jul 2010)

mvitz hat gesagt.:


> Ich hoffe doch nicht, Passwörter sollten Server seitig immer nur als Hash gespeichert und niemals als Klartext abgelegt werden.



Es ist ja alles festgelegt. Ob es Sinn macht oder nicht könnte mal Anfang 90er disskutieren (wenn nicht sogar früher). Auszug aus den RFC 1939 zu POP3:



> The `digest' parameter is calculated by applying the MD5 algorithm [RFC1321] to a string consisting of the timestamp (including angle-brackets) followed by a shared secret.  This shared secret is a string known only to the POP3 client *and server*.



Der Server muss das Kennwort kennen, sonst funktioniert das Verfahren nicht. (kann ja verschlüsselt werden, aber nicht gehasht)


----------



## mvitz (28. Jul 2010)

Ok. Dann ginge aber trotzdem meine Variante  Nur das dann halt das was man als User eingibt nicht das "shared secret" ist, sondern der Hash des eingegebenen Passworts.


----------



## XHelp (28. Jul 2010)

Theoretisch ja, aber dann wäre es nicht APOP und man müsste zu dem selbsterfundenem Server auch den dazugehörigen Client schreiben


----------



## mvitz (28. Jul 2010)

Stimmt.

Dank dir weiß ich jetzt jedenfalls, dass z.B. web.de mein Passwort unverschlüsselt speichert. Wobei ich mir das irgendwie nicht so wirklich vorstellen kann, auch wenn es im RFC steht... Jetzt aber erst mal wieder auf ne Antwort des TOs warten.


----------



## XHelp (28. Jul 2010)

mvitz hat gesagt.:


> Dank dir weiß ich jetzt jedenfalls, dass z.B. web.de mein Passwort unverschlüsselt speichert.


Nur weil es nicht als Hash vorliegt heißt es ja nicht, dass es unverschlüsselt ist  Selbst WENN das als MD5-Hash vorliegt, dann kann man es sich ja auch schenken (Rainbow-Tables lassen grüßen)


----------



## anonym (29. Jul 2010)

hi, 

also, wie ihr schon gemerkt habt ist der Client nicht in Diskussion. Hier sollen alle POP3- Clients funktionieren, dass heißt, ich muss die Vorgabe aus RFC 1939 (danke, XHelp, ich hatte mich im Eingangspost vertan und RFC1460 geschrieben) umsetzen. 
Die Datenbank ist serverseitig eigentlich auch fertig und speichert md5- Hashwerte. 
Aber wenn es keine schöne Möglichkeit gibt, das umzusetzen, muss sich halt ändern, was die Datenbank speichert. 

Danke schön, 
anonym


----------

