[Postfixbuch-users] Passwörter in Dovecot

[Peer Heinlein]

Am Montag 11 Oktober 2010 18:22:00 schrieb Pascal:


Moin,

> Als ich mir nun einmal angeschaut habe, was eigentlich hinter
>  CRAM-MD5 steckt, hat sich mir die Frage aufgedrängt, wie Dovecot die
>  vom Client übermittelte Response (und damit das Passwort)
>  verifizieren kann, wenn in der Datenbank das Passwort nicht im
>  Klartext, sondern in der oben genannten Form steht. Meinem

Richtig.

Das, was Du als CRAM-MD5 bezeichnest ist genauer übrigens ein "HMAC-
MD5". CRAM-MD5 ist das Procedere, HMAC-MD5 ist der Hash, den Du da vor 
Dir hast.

>  bisheringen Verständnis von CRAM-MD5 zufolge kann dies dann
>  eigentlich nur möglich sein, wenn aus dem String in der Datenbank
>  das Passwort ermittelt werden kann. 

Nicht ganz. :-) Es gibt noch einen Plan-B.

Aber prinzipiell hast Du recht und das zeigt, daß Du das Problem völlig 
korrekt verstanden und durchdacht hast. 

>  Falls dem so ist, könnte man
>  allerdings eigentlich gleich direkt das Passwort im Klartext in der
>  Datenbank speichern.

Das sowieso, damit renne ich seit jeher durch die Gegend und versuche zu 
vermitteln, daß gehashte Passwörter unsicher und Klartextpasswörter 
sicher sind.

> 1)   Gibt es eine Möglichkeit, auch ohne "dovecotpw" den
>  Passwort-String zu generieren? Wenn ja, wie ist dies möglich?

Naja, mit irgendeinem Code halt, der HMAC-MD5 erzeugt. 

> 2)   Was hat es mit diesem Passwort-String genau auf sich, lässt sich
> aus diesem Tatsächlich das Klartext-Passwort ermitteln?

Nein.

>        - Wenn nein, wie lässt sich damit dann die vom Client
> übermittelte Response verifizieren?

Weil der HMAC-MD5-Hash ein Zwischenschritt vor dem eigentlichen "CRAM" 
ist.

Client: Aus "geheim" macht er zunächst einen HMAC-MD5-Hash und benutzt 
diesen (!) quasi als Klartextpasswort. Mit dem Hash (!) rechnet der 
jetzt die Challence durch um das Response zu bekommen (CRAM).

Server: Der Client hat bereits einen HMAC-MD5-Hash, mit diesem rechnet 
der jetzt seinerseits Challenge zu Response. Für ihn entfällt der erste 
Hash-Schritt, aber Ausgangsbasis für das CRAM ist immer auf beiden 
Seiten der Hash.

Das bedeutet aber: Jeder, der den HMAC-MD5-Hash hat, kann sich damit 
mittels CRAM-MD5 anmelden.  Wer glaubt, er müsse auf seine angeblich 
sicher gehashten Passwörter darum nicht mehr so aufpassen, unterliegt 
also einem schwerwiegenden Irrtum. Ob Klartext oder HMAC-MD5-Hash ist 
IMHO egal.

Der ist quasi genauso wertvoll wie das Klartextpasswort selbst -- 
allerdings kann man sich damit nicht mehr bei Klartextverfahren wie 
einer Web-GUI anmelden, insofern, ja, gibt es einen klitzekleinen 
Vorteil.

Andererseits kann man mit einem HMAC-MD5-Hash nun keine sicheren 
Methoden mehr wie CRAM-SHA256 o.ä. durchführen -- denn dazu bräuchte man 
entweder das Klartextpasswort oder eben bereits einen HMAC-SHA256-Hash. 

Das bedeutet: Wenn man die Hashes speichert ist einem der Weg in die 
Zukunft zu sicheren/besseren Hash-Methoden verbaut und man kann 
gegenüber dem Client nun auch nicht mehr "*" anbieten, sondern eben nur 
PLAIN, Login und CRAM-MD5 und das war's dann.

Und aus diesem Grunde halte ich Klartextpasswörter für eigentlich 
sicher. Und vor dem Admin braucht man das Passwort eh nicht verstecken. 
Ich kann alle Mails lesen, sogar mit Inhalt. Wozu interessiert mich das 
PW. Ich könnte ja sogar einen eigenen Hash setzen, die Mails abrufen und 
dann den Orginal-Hash wieder einsetzen -- und keiner würde es merken. 

Vor dem Admin etwas verbergen zu wollen ist also Unsinn. Darum muß man 
die Methoden nehmen, die höchstmögliche Sicherheit bei der Übertragung 
der PWs durch die Weiten des Internets bietet. Und das sind 
Klartextpasswörter als Ausgangsbasis für beliebige CRAM-Verfahren.

Peer


P.S.: Zwischen MD5 und HMAC-MD5 besteht übrigens ein Unterschied. Das 
wird gerne für identisch gehalten und dann wundern sich die Leuten, wenn 
das nicht geht. :-) Wer nur MD5 hat, der kann damit auch kein CRAM-MD5 
mehr anbieten. Details habe ich dazu aber auch wieder vergessen.

-- 

Heinlein Professional Linux Support GmbH
Linux: Akademie - Support - Hosting

http://www.heinlein-support.de
Tel: 030 / 40 50 51 - 0
Fax: 030 / 40 50 51 - 19

Zwangsangaben lt. §35a GmbHG:
HRB 93818 B / Amtsgericht Berlin-Charlottenburg,
Geschäftsführer: Peer Heinlein  -- Sitz: Berlin