[Postfixbuch-users] Passwörter in Dovecot

[Pascal Uhlmann]

Hallo Peer,

danke für deine ausführliche Antwort. Sowas in der Art hatte ich eigentlich
schon fast vermutet. Prinzipiell hielte ich es auch für sinnvoller, die
Passwörter im Klartext zu speichern, da man dann eben - wie du ja bereits
sagtest - alle unterstützten Authentifizierungsmechanismen verwenden kann.
Es war eben der ausdrückliche Wunsch des Kunden, aber vielleicht lässt er
sich ja nun unter diesen Umständen doch überzeugen, die Passwörter im
Klartext in der Datenbank abzulegen.

Danke nochmals!

Pascal Uhlmann
 
===================================
Internet: www.it-blog.net



-----Ursprüngliche Nachricht-----
Von: postfixbuch-users-bounces at listen.jpberlin.de
[mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Peer
Heinlein
Gesendet: Montag, 11. Oktober 2010 18:40
An: Eine Diskussionsliste rund um das Postfix-Buch von Peer Heinlein.
Betreff: Re: [Postfixbuch-users] Passwörter in Dovecot

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
--
_______________________________________________
Postfixbuch-users -- http://www.postfixbuch.de Heinlein Professional Linux
Support GmbH

Postfixbuch-users at listen.jpberlin.de
https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users