PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : fetchmailrc: Passwort verschlüsselt speichern (CRAM-MD5 Auth-Problem)



kai_f
21.05.12, 12:35
Hallo.

Ich habe ein Passwort-Problem mit fetchmail (v6.3.21) bzgl. CRAM-MD5 Authentifizierung.

Auf meinem openSUSE (12.1) Server (nur LAN, kein Root-Server) läuft Dovecot als IMAP-Server und Postfix für SMTP. Dies funktioniert ganz gut. Für externe Mail-Provider benutze ich Fetchmail im (Daemon-Mode) zum Abholen der Mails.

In meiner globalen /etc/fetchmailrc habe ich u.a. die Zugangsdaten für einen Unitymedia IMAP-Server konfiguriert, der die Auth-Varianten Plain, CRAM-MD5 und DIGEST-MD5 unterstützt. Wenn ich nun das Passwort im Klartext in die fetchmailrc eintrage und als Auth-Methode (Default also) CRAM-MD5 wähle, authentifiziert sich fetchmail ohne Probleme bei dem IMAP-Server und holt Mails ab.


# Meine /etc/fetchmailrc:
set daemon 300
...
poll imap.unitybox.de
protocol imap
auth cram-md5
username xxx@unitybox.de
password 'Passwort im Klartext'
is mailuser
fetchall
ssl
sslproto tls1
sslfingerprint "..."
sslcertck
sslcertpath /etc/ssl/certs
mda "/usr/lib/dovecot/deliver -d mailuser -m 'INBOX/xxx@unitybox.de'"
...


Folgendes möchte ich nun erreichen:

Das Passwort für den Mail-Server soll nicht im Klartext in der fetchmailrc gespeichert werden, sondern verschlüsselt bzw. der Hashwert vom Passwort.

Wenn ich es richtig verstehe, sollte es laut Man-Page von Fetchmail möglich sein, das Passwort verschlüsselt in der fetchmailrc zu speichern, anstatt im Klartext. Hier der relevante Text aus der Man-Page:


Legal authentication types are 'any', 'password', 'kerberos', 'kerberos_v4', 'kerberos_v5' and 'gssapi', 'cram-md5', 'otp', 'msn' (only for POP3), 'ntlm', 'ssh', 'external' (only IMAP). The 'password' type specifies authentication by normal transmission of a password (the password may be plain text or subject to protocol-specific encryption as in CRAM-MD5)

Den CRAM-MD5 Hashwert vom Klartext-Passwort berechne ich so:

doveadm pw -s cram-md5 -p 'PASSWORT'

Die fetchmailrc ändere ich dazu wie folgt ab:



...
poll imap.unitybox.de
...
password 'CRAM-MD5 Hashwert vom Klartext-Passwort'
...


Mit dem so erzeugten CRAM-MD5 Hashwert scheitert allerdings die Authentifizierung am Server und ich verstehe nicht warum. Der Server akzeptiert CRAM-MD5 als Auth-Methode auf jeden Fall, denn dies habe ich mit KMail bereits getestet.

Mein Ziel ist, dass Passwort nicht als Klartext in der fetchmailrc zu speichern.

Kann mir jemand sagen, was ich falsch mache? Vielleicht habe ich die Man-Page falsch interpretiert und Passwörter können unabhängig von der Auth-Methode immer nur im Klartext gespeichert werden?

Vielen Dank und Gruß...

TheDarkRose
21.05.12, 20:13
Nun ja, weißt du wie CRAM-MD5 funktioniert? Der Server schickt dir einen "Salt", mit diesem Salt wird dein Passwort per MD5 gehasht und du schickst diesen Hash zurück zum Server. Dieser macht genau das selbe und vergleicht beide Hashes.

Wobei ich IMHO von Providern die CRAM/DIGEST-MD5 unterstützen einen großen Bogen machen würde, denn diese Methoden erfordern, dass das Passwort im Klartext in deren DB hinterlegt sein muss.

kai_f
21.05.12, 22:43
Hi, danke für Deine Antwort. Ja, mir ist klar, was und wozu ein Salt ist. Du meinst aber, bei CRAM/DIGEST-MD5 wird generell immer ein SALT generiert und zusammen mit dem Passwort auf dem Server im Klartext gespeichert. Hmmm, bitte belehre mich, aber hier ein Gegenbeispiel:

Bei meinem lokalen Dovecot-Server lasse ich als Auth-Methode nur CRAM-MD5 zu (ein anderer Fall wäre, wenn der Server mehrere Auth-Methoden gleichzeitig zulassen würde, dann müsste das Passwort im Klartext gespeichert werden). Angenommen mein IMAP-User heisst 'max' und hat das Passwort 'test'. Mittels

doveadm pw -s CRAM-MD5 -p test

{CRAM-MD5}e02d374fde0dc75a17a557039a3a5338c7743304777dcc d376f332bee68d2cf6 generiere ich den CRAM-MD5 Hash und speichere diesen generierten String als Passwort für den User 'max' in meiner dovecot.conf ab. So steht es auch in der Dovecot-Doku. Das Passwort wird also nicht im Klartext auf dem Server gespeichert, sondern der Hash ohne einen zusätzlichen Salt-Wert. Nun kann ich mit einem beliebigen MUA (Thunderbird, KMail, ...) eine Verbindung zu dem Dovecot-Server aufbauen lassen, mit den Login-Daten (max/test). Die Authentifizierung funktioniert einwandfrei, sofern der Client das Passwort im Klartext kennt. Dieser generiert u.a. den Hash und schickt diesen zum Server, wo verglichen wird. Spielt nun keine Rolle, ob dabei ein Salt mit generiert wird oder nicht.

Mal sehen, aber da liegt doch wahrscheinlich mein Denkfehler. Fetchmail ist ja nichts anderes als eine Art MUA wie z.B. Thunderbird oder KMail, nur eben mit beschränkter Funktionalität, kann also nur Mails abholen. Hat Fetchmail das PW im Klartext, kann es gemäß Auth-Methode den Hash berechnen und zum Server senden. Dieser vergleicht dann die beiden Zeichenketten. Somit müsste es also nicht möglich sein, dass in der fetchmailrc verschlüsselte Passwörter bzw. die Hashes der Passwörter stehen. Die Passwörter dürfen also unabhängig vom verwendeten Auth-Verfahren nur im Klartext in der fetchmailrc stehen, sonst kann es nicht funktionieren, richtig?

Was aber hat es dann mit diesem Satz aus der Fetchmail Man-Page auf sich?


Legal authentication types are 'any', 'password', 'kerberos', 'kerberos_v4', 'kerberos_v5' and 'gssapi', 'cram-md5', 'otp', 'msn' (only for POP3), 'ntlm', 'ssh', 'external' (only IMAP). The 'password' type specifies authentication by normal transmission of a password (the password may be plain text or subject to protocol-specific encryption as in CRAM-MD5)

Ich hatte daraus eben fälschlicherweise abgeleitet, dass das Passwort je nach Auth-Methode entweder Plain oder verschlüsselt sein darf und auch so gespeichert wird. Das war wohl ein Trugschluss.