[Postfixbuch-users] saslauthd oder auxprop?

[Patrick Ben Koetter]

* hm0 at gmx.net <hm0 at gmx.net>:
> ich möchte unseren Mailserver von bisher auth via pam/shadow auf mysql
> umsetllen. Nun geht das ja wohl via saslauthd und/oder auxprop? Wo lieg da
> der Unterschied/was ist besser (Performace etc)?

saslauthd kann nur plaintext-Mechanismen.
Das auxprop-Plugin sql kann plaintext- und shared-secret-Mechanismen; letztere
sind VIEL sicherer, setzen aber voraus, dass die Mailclients in der Lage sind
shared-secret-Mechanismen zu nutzen. Outlook kann beispielsweise NICHT
shared-secret-Mechanismen nutzen.

> U.u. möchte ich/muß ich währen der Übergangszeit die shadow-auth als
> fallback lassen...

smtpd.conf
pwcheck_method: auxprop saslauthd

Durch das aneinanderhängen wird der zweite aufgerufen, wenn der erste kein
positives Ergebnis bringt.

> Und woher bekomme ich die? (=> mittlweile sind sie zwar auf dem System drauf
> - aber im hab k.a. aus welchem Paket die waren / = Debian 3.1)

Keine Ahnung. Mit Debian kenn ich mich nicht gut aus.

> btw.: Ich würde die Passwörter gerne verschlüsselt in der DB ablegen... nur
> die frage ist: Wie muß ich sie verschlüsseln, damit postfix/courier die auch
> unterstützen? (also z.B. so wie in der shadow mit $... MD5 oder wie?) (ich
> hoffe es ist klar was ich meine)

Also wieso denn wollen alle denn immer die Passwörter in der MySQL-Datenbank
verschlüsseln? (Sorry, dass es Dich jetzt mit dem Ärger erwischt...)

Es ist einfach so:

shared-secret-Mechanismen benötigen den Zugriff auf unverschlüsselte
Passwörte. Das bedingt das Prinzip von shared-secret-Mechanismen.

Damit hat jeder, der SQL als authentication backend in SASL nutzen will jetzt
die Wahl:

1. Passwörter nicht verschlüsseln
Damit kann das sql-Plugin von SASL genutzt werden. Es stellt dem Mailclient
shared-secret-Mechanismen zur Verfügung. Dadurch wird die Übertragung von
Authentifizierungsdaten _viel_ sicherer als bei plaintext-Mechanismen.

2. Passwörter verschlüsseln
Das geht mit dem sql-Plugin _nur_ wenn es vorher mit dem FROST-Patch behandelt
wurde. Dann ist es möglich, auf verschlüsselte Passwörter in der DB
zuzugreifen, aber (!) das Patch disabled shared-secret-Mechanismen. Wer also
den FROST-Patch einsetzt, ist sicherheitsmäßig wieder da wo er mit saslauthd
eh schon war - nämlich bei klartext-Übertragung von Benutzernamen und
Kennwort.


Wann ist das Risiko größer, dass Benutzername und Kennwort ausgespäht werden?

Das Risiko ist in der Regel _viel_ größer, dass irgendein VollHeinz [TM] die
Übertragung der Authentifizierungsdaten ausspäht, als dass derselbe VollHeinz
die Daten meiner DB ausliest. Wenn er nämlich die die Daten der DB auslesen
kann, habe ich meist ein ganz anderes Problem...

Meine Empfehlung also: Kickt diesesn FROST-Patch in die Tonne. Ei drüber
schlagen und ab dafür. Der FROST-Patch kauft Sicherheit indem er an anderer
Stelle wichtigere Sicherheits-Features wegnimmt...

p at rick

P.S.
Courier authdaemond kann man mitteilen, dass die Passwörter unverschlüsselt in
der DB liegen. Von der Seite sind also auch keine Probleme zu erwarten.

-- 
Das »Postfix«-Buch
<http://www.postfix-buch.com>
saslfinger (debugging SMTP AUTH):
<http://postfix.state-of-mind.de/patrick.koetter/saslfinger/>