[Postfixbuch-users] MySQL-MAP über mehrere Tabellen verteilen?

[Patrick Ben Koetter]

* Sandy Drobic <postfixbuch-users at japantest.homelinux.com>:
> Thomas wrote:
> >> Es gibt einen Patch, den Frost-Patch, der es möglich macht, verschlüsselte
> >> Passworte in einer MySQL-DB zusammen mit Cyrus SASL zu nutzen. Der Patch
> >> deaktiviert aber gleichzeitig shared-secret-Mechanismen, so dass
> >> ausschließlich plaintext-Mechanismen genutzt werden können.
> >>   
> > Und ohne die Plaintext-Mechanismen dürfte es Probleme mit Outlook 
> > (Express) geben, oder?
> 
> Nein, das Problem ist eher, dass bei Plaintext eben die Passwörter 
> erlauschbar sind und deshalb nur über TLS/SSL verwendet werden sollten. 
> Shared-Secret schicken das Passwort nicht über die Leitung, sondern 
> arbeiten mit einem etwas komplizierterem Challenge-Response-Verfahren, wo 
> der Server eine Challenge schickt und der Client diese mit dem Passwort 
> verarbeitet zurückschickt. Wenn der Server mit dem Passwort in der 
> Datenbank das gleiche Ergebnis bekommt, war das eingegebenen Passwort das 
> gleiche und die Authentifikation ist erfolgreich.
> 
> Deshalb kann man hier auch ohne TLS eine sichere Authentifikation 
> implementieren. Ein vielbeschäftigter Server wird es dir danken, wenn er 
> nicht eine Menge CPU-Zyklen für Verschlüsselung verbraten muss.
> 
> Postfix z.B. versucht die sichersten Methoden zuerst für die 
> Authentifikation und fällt erst danach zu Plaintext-Mechanismen wie PLAIN 
> oder LOGIN zurück, wenn CRAM-MD5 oder DIGEST-MD5 nicht vorhanden sind.

Postfix (lies: der Postfix smtp-Client, der AUTH bei einem anderen Server
gesehen hat und es auch nutzen will) übergibt den gesamten Prozess der
Authentifizierung an das Cyrus SASL Authentifizierungs-Framework, d.h. Postfix
nennt Cyrus SASL einfach nur die verfügbaren Mechanismen und Cyrus SASL
(libsasl) wählt den besten (lies: sichersten) Mechanismus.

Weil das in der Praxis zu Problemen führen kann - der remote SMTP-Server
bietet beispielsweise GSSAPI an, aber der Server auf dem Postfix läuft wurde
nicht für KERBEROS konfiguriert oder hat kein passendes Ticket - hat Viktor
Duchovni vor gut einem Jahr einen weiteren Parameter -
smtp_sasl_mechanism_filter - hinzugefügt.

Mit diesem Parameter kann Postfix die Liste der angebotenen Mechanismen
'filtern', bevor es die bereinigte Liste dann an libsasl übergibt. So wird
vermieden, dass libsasl einen Mechanismus wählt, den es nicht erfolgreich
abwickeln kann.

Als Server haben Cyrus SASL und Postfix mehr Kontrolle darüber, welche
Mechanismen einem anderen Client angeboten werden können. Es beginnt damit,
dass man in der smtpd.conf mit dem mech_list-Parameter einschränken kann,
welche Mechanismen libsasl der Applikation (lies: smtpd-Dämon) zur Verfügung
stellen darf.

In der Praxis wird das am meisten genutzt, weil wir somit libsasl davon
abhalten können, bei Verwendung des saslauthd-Dämons Mechanismen anzubieten,
die der saslauthd-Dämon gar nicht verarbeiten kann (lies: alles ausser
plaintext-Mechanismen).

In Postfix selbst steht uns ein weiteres Mittel - smtpd_sasl_security_options
- zur Verfügung, um zu bestimmen welche Mechanismen angeboten werden dürfen.
Auf dieser Ebene können wir festlegen, welche Eigenschaften an Mechanismen wir
generell in der Applikation zulassen oder sperren wollen - noplaintext,
mutual_auth (wechselseitiges AUTH), etc.


p at rick

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