Guten Morgen Jan,
richtig. Das Problem scheint geloest zu sein, jetzt kommt die Feinarbeit.
JanC wrote:PLAIN und LOGIN: Beide übermitteln das Passwort unverschlüsselt (Base64-kodiert), nur schickt LOGIN Username und Passwort einzelnd, während PLAIN beides auf einmal schickt. Eigentlich kein Unterschied.
Ok, wenn ich also SMTP-Auth ohne Verschluesselung zulassen moechte, lasse ich beide Optionen drinnen, bzw hab eh noch nicht gesehen, wie ich das trennen koennte. Unverschluesselt zulassen/verbieten funktioniert ja ueber die Option
Code: Select all
smtpd_sasl_security_options = noplaintext
in der main.cf, gell?
CRAM-MD5 und DIGEST-MD5: Bei beiden wird das Passwort selbst gar nicht übertragen, sondern auf Basis eines Zeitstempels und des Passworts eine Sequenz berechnet, die übertragen wird. Daher sehr sicher für das Passwort, aber keine Verschlüsselung der Emails selbst! Der Unterschied ist, dass CRAM immer das Klartext-Passwort braucht, DIGEST hingegen theoretisch auch mit dem bereits in MD5 gebildetem Hash auskommt. Mehr dazu unten.
Aha. Ok, so tief habe ich mich bisher noch nicht mit der Materie beschaeftigt, deswegen freut es mich umso mehr, dass ich das hier so einfach erklaert bekomme. :-)
SSL: In Verbindung mit PLAIN oder LOGIN wunderbar, da der gesamte Verkehr inklusive Passwort verschlüsselt wird.
Mit SSL in Verbindung mit SMTP habe ich mich noch ueberhaupt nicht beschaeftigt. Aber klar, wenn die Verbindung verschluesselt laeuft, dann koennen auch die Passwoerter sozusagen PLAIN uebertragen werden, da sie innerhalb des restlichen Verkehrs ja eh verschluesselt uebertragen werden.
Jetzt kommen die Probleme. Outlook und Outlook Express können beide nur PLAIN / LOGIN mit oder ohne SSL. Also alles oder nichts. Die meisten anderen Mailer können MD5, was die Passwörter sicher macht. Noch schlimmer wirds bei POP. Da gibt es entweder nur POP3(unverschlüsselt) , APOP (MD5) oder POP3-SSL. Das Problem ist, das viele Mailer und vor allem der Courier-Server APOP nicht unterstützen.
Sprichst Du jetzt nur von POP oder auch von SMTP? SMTP-maessig kann ich bei TheBat ausser einer "Regular Port 25" Connection noch "Secure Port 25" bzw "Secure Port 465" auswaehlen. Wobei ich die Ports natuerlich aendern kann. Aehnliche Optionen gibt es auch fuer POP3, naemlich "Regular", "Secure Port 110" und "Secure Port 995". Habe jetzt mal Outlook Express (das erste und hoffentlich letzte Mal, oh Graus!) gestartet. Da erzaehlt er sowohl bei POP3 als auch SMTP etwas von "Secure Password Authentification" (sorry, hab alles auf englisch installiert), die ich optional einschalten kann. Laut Deiner Aussage von oben waere das dann PLAIN oder eben PLAIN ueber SSL, richtig?
Am schönsten wäre es also SSL-PLAIN und MD5 anzubieten. Damit kann quasi jeder Mailer arbeiten. Problem dabei, das klappt nur mit Klartext-Passwörtern. Ob die nun wirklich ein so grosses Sicherheitsrisiko sind ist Ansichtssache. Klar, Vorteil ist, du kannst die Passwörter einsehen, falls ein Kunde sie mal vergisst. Nachteil, falls jemand deinen Server hackt, hat er alle Passwörter. Die kannst du dann natürlich neu vergeben, aber dazu musst du erstmal wissen, dass der GAU passiert ist. Ich persönlich halte Klartext-Passwörter zwar nicht für toll, aber in vielen Fällen für praktisch, wenn der Rest des Servers gut abgesichert ist.
Genau, das mit der Sicherheit ist alles Ansichtssache. Die Frage ist naemlich, ob jemand, der meine Kiste knackt, sich dann als allererstes, wenn ueberhaupt irgendwann, fuer Mailpasswoerter interessiert. Wichtig waere in dem Zusammenhang natuerlich, den Lesen-User fuer Postfix von postfix / postfix auf was anderes zu aendern. Denn auch mit skip-networking kann einer meiner Kunden ja per PHP auf diese Datenbank zugreifen und alles auslesen.
Die Traum-Lösung wäre natürlich die eben besprochene Lösung mit SSL, DIGEST-MD5 und MD5-verschlüsselten Passwörten. Dass Problem ist, das SASL das nicht unterstützt. Es unterstützt zwar CRAM und DIGEST, aber nicht die Berechnung nur auf Basis des Hashs. Ich hoffe das war verständlich. :)
Nun gibt es einen Patch der SASL das ermöglicht. Ich habe ihn allerdings nie benutzt und kann dir auch nicht sagen woher du ihn bekommst und wie gut er funktioniert. Auf jeden Fall musst du dafür SASL neu kompilieren. Falls du dich näher damit beschäftigst und Erfolg hast, würde ich mich freuen, wenn du mich dann mal informierst.
Fassen wir mal meine Konfiguration zusammen:
Courier-POP3/IMAP
Postfix
Postfix Admin 2
SMTP-Auth ueber SASL2
(und alles per MySQL)
Nun legt Postfix Admin 2 alle Passwoerter in "md5crypt", wobei man seit Version 2 das auch auf plain aendern kann. Courier kommt damit zurecht, da habe ich in der Datei authmysqlrc einen Eintrag
fuer die Tabellenspalte, in der das verschluesselte Passwort abgelegt ist. Wenn ich mich richtig erinnere, gibt es optional auch ein Feld
oder so aehnlich, richtig? Koennte so also dem Courier auch Passwoerter in plain vorsetzen.
Der Verkehr per POP3/IMAP laeuft bei mir unverschluesselt, wobei die Passwoerter unverschluesselt uebertragen, im System aber verschluesselt geprueft werden.
Anders der Auth-SMTP-Verkehr. Hier laeuft der Verkehr oft per CRAM-MD5 verschluesselt, leider koennen die Passwoerter im System unverschluesselt geprueft werden, da SASL2 keine verschluesselten Passwoerter kann ohne diesen ominoesen Patch.
Zu diesem Patch: Bin irgendwie als verwoehnter Debian-Juenger aus Bequemlichkeitsgruenden ein Fan dieser apt-get Geschichte, die mir fertige Pakete installiert und sogar grundkonfiguriert. Gibt es was nicht als Debian-Paket, dann ist das was anderes. Wenn ich jetzt SASL2 patche, dann hab ich spaetestens wenn ich ein Upgrade machen moechte, wieder das gleiche Problem. apt-get ueberbuegelt mir wahrscheinlich die gepatchte Version weil ich inzwischen vergessen habe, dass da ja mal was war. Oder noch besser, das Upgrade wird wegen ner anderen Installation vorgenommen und ich krieg das nicht mit, weil ich in Eile war.
Auf den ersten Blick sieht es fuer mich dann so aus: Wohl oder uebel die Mailpasswoerter auf plain aendern (dazu muss ich wohl nur den einen Eintrag in der Postfix Admin Config aendern, den Kunden einen Zeitpunkt nennen, zu dem sie alle ihre Passwoerter aendern muessen, Postfix Admin legt dann die geaenderten Passwoerter plain ab) und Courier zeitgleich beibringen, dass die Passwoerter nun plain vorliegen. Gibt es diese MYSQL_PLAIN_PWFIELD Option tatsaechlich, sollte das kein Problem sein.
Allgemein dazusagen muss ich noch, dass meine Konfiguration end(l)userfreundlich sein muss, sprich Outlook (Express) User duerfen nicht im Regen stehen bei mir. :-)
Aber erzähl mir auf jeden Fall wie du dich entscheidest.
Siehe oben. Gute Entscheidung, schlechte Entscheidung? :-)
Wie laeuft das bei Dir? Ich nehme an, genau so, oder?
Viele Gruesse,
Martin