SASL- und IMAP-Authentifizierungsmechanismen von Dovecot/Postfix
Hallo,
ich denke schon die ganze Zeit darüber nach, ob der Authentifizierungsmechanismus „plain“ ein Sicherheitsrisiko ist, welchen ich in Postfix mit „smtpd_sasl_security_options“ bzw. „smtpd_sasl_tls_security_options“ und in Dovecot unter „auth_mechanisms“ angeben kann?! Ich bin geneigt dazu das Tor so weit wie möglich zu schliessen und nur die höchste und "verschlüsselste" Authentifizierungsmethode zuzulassen - aber ist das sinnvoll? Je nach Client kann es da zu Problemen führen, weil nicht alle Clients alle Möglichkeiten durchprobieren und deswegen der Erklärungsaufwand höher ist.
Wenn ich die diversen Dokus/Bücher richtig verstanden habe, dann wird bei IMAP logischerweise (wenn ich Dovecot als IMAP-Server einsetze) Dovecot als Authentifizierungsinstanz genutzt. Wenn ich jetzt
auth_mechanisms = plain, login, ...
setze - wie wird dann eine Anmeldung per IMAPS vorgenommen? Wird die Authentifizierung verschlüsselt ablaufen? Und stellt Plaintext in dem Falle ein Sicherheitsrisiko dar?
Und wie ist das bei Postfix? Ich kann mit
smtpd_sasl_security_options = noanonymous, noplaintext smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
festlegen, dass bei einer unverschlüsselten SMTP-Session sowohl keine anonyme Authentifizierung als auch keine im Plaintext stattfinden darf. Um es komfortabler zu machen, kann ich aber auch
smtpd_sasl_security_options = noanonymous, noplaintext smtpd_sasl_tls_security_options = noanonymous
festlegen. Damit kann ich TLS-verschlüsselt auch wieder Plaintext verwenden.
Würde denn auch
smtpd_sasl_security_options = noanonymous smtpd_sasl_tls_security_options = $smtpd_sasl_security_options smtpd_tls_auth_only = yes
zu dem gleichen Ergebnis führen, wenn ich nur verschlüsselte Authentifizierung erlauben will? Denn dann würde ja smtpd_sasl_security_options gar nicht zum Zuge kommen, oder?
Was ist nun eine sichere und zugleich komfortable Konfiguration, damit sich am besten alle möglichen Clients einfach per IMAPS/SMTPS authentifizieren können?
Viele Grüße, Michael
Hallo Michael,
PLAIN mit TLS bringt die höchste Sicherheit. Mit TLS erzwingst Du eine verschlüsselte Strecke. Mit dieser schützt Du die Datenübertragung des PLAIN Mechanismus. Der widerum ermöglicht, Kennworte verschlüsselt im Backend abzulegen.
Erzwinge TLS _vor_ AUTH oder lehne die AUTH ab bzw. biete sie dann nicht an.
smtpd_tls_auth_only = yes
p@rick
* Michael Köhler postfix-users@makomi.de:
Hallo,
ich denke schon die ganze Zeit darüber nach, ob der Authentifizierungsmechanismus „plain“ ein Sicherheitsrisiko ist, welchen ich in Postfix mit „smtpd_sasl_security_options“ bzw. „smtpd_sasl_tls_security_options“ und in Dovecot unter „auth_mechanisms“ angeben kann?! Ich bin geneigt dazu das Tor so weit wie möglich zu schliessen und nur die höchste und "verschlüsselste" Authentifizierungsmethode zuzulassen - aber ist das sinnvoll? Je nach Client kann es da zu Problemen führen, weil nicht alle Clients alle Möglichkeiten durchprobieren und deswegen der Erklärungsaufwand höher ist.
Wenn ich die diversen Dokus/Bücher richtig verstanden habe, dann wird bei IMAP logischerweise (wenn ich Dovecot als IMAP-Server einsetze) Dovecot als Authentifizierungsinstanz genutzt. Wenn ich jetzt
auth_mechanisms = plain, login, ...
setze - wie wird dann eine Anmeldung per IMAPS vorgenommen? Wird die Authentifizierung verschlüsselt ablaufen? Und stellt Plaintext in dem Falle ein Sicherheitsrisiko dar?
Und wie ist das bei Postfix? Ich kann mit
smtpd_sasl_security_options = noanonymous, noplaintext smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
festlegen, dass bei einer unverschlüsselten SMTP-Session sowohl keine anonyme Authentifizierung als auch keine im Plaintext stattfinden darf. Um es komfortabler zu machen, kann ich aber auch
smtpd_sasl_security_options = noanonymous, noplaintext smtpd_sasl_tls_security_options = noanonymous
festlegen. Damit kann ich TLS-verschlüsselt auch wieder Plaintext verwenden.
Würde denn auch
smtpd_sasl_security_options = noanonymous smtpd_sasl_tls_security_options = $smtpd_sasl_security_options smtpd_tls_auth_only = yes
zu dem gleichen Ergebnis führen, wenn ich nur verschlüsselte Authentifizierung erlauben will? Denn dann würde ja smtpd_sasl_security_options gar nicht zum Zuge kommen, oder?
Was ist nun eine sichere und zugleich komfortable Konfiguration, damit sich am besten alle möglichen Clients einfach per IMAPS/SMTPS authentifizieren können?
Viele Grüße, Michael
Hallo Patrick,
ich denke schon die ganze Zeit darüber nach, ob der Authentifizierungsmechanismus „plain“ ein Sicherheitsrisiko ist, welchen ich in Postfix mit „smtpd_sasl_security_options“ bzw. „smtpd_sasl_tls_security_options“ und in Dovecot unter „auth_mechanisms“ angeben kann?! Ich bin geneigt dazu das Tor so weit wie möglich zu schliessen und nur die höchste und "verschlüsselste" Authentifizierungsmethode zuzulassen - aber ist das sinnvoll? Je nach Client kann es da zu Problemen führen, weil nicht alle Clients alle Möglichkeiten durchprobieren und deswegen der Erklärungsaufwand höher ist. […]
PLAIN mit TLS bringt die höchste Sicherheit. Mit TLS erzwingst Du eine verschlüsselte Strecke. Mit dieser schützt Du die Datenübertragung des PLAIN Mechanismus. Der widerum ermöglicht, Kennworte verschlüsselt im Backend abzulegen.
Erzwinge TLS _vor_ AUTH oder lehne die AUTH ab bzw. biete sie dann nicht an.
smtpd_tls_auth_only = yes
Wenn ich es richtig verstehe, dann heisst das:
smtpd_sasl_security_options = noanonymous smtpd_sasl_tls_security_options = $smtpd_sasl_security_options smtpd_tls_auth_only = yes
Ist genau das richtige, oder? Ich verbiete mit smtpd_tls_auth_only = yes das unverschlüsselte AUTH und mit smtpd_sasl_tls_security_options definiere ich, dass alles ausser anonymous (siehe smtpd_sasl_security_options = noanonymous) angenommen wird, bzw. an Dovecot angefragt wird. In Dovecot wiederum definiere ich
auth_mechanisms = plain login
Und in der Datenbank wird das Ganze dann mit SHA512-Crypt abgelegt. Oder kann ich die ganze Option smtpd_sasl_security_options auch weglassen, wenn ich eh kein unverschlüsseltes AUTH anbiete?
Und nur noch mal konkret nachgefragt: Gibt es in Dovecot eine Option wie in Postfix „smtpd_tls_auth_only“? Oder wird als Standard die Authentifizierung verschlüsselt abgewickelt, wenn man nur IMAPs angeschlagen hat?! Ich frage jetzt nicht wegen der Postfix-Anbindung sondern wegen des IMAP-Zugriffs.
Viele Grüße, Michael
Moin.
On 08.01.2015 16:49, Michael Köhler wrote:
Und nur noch mal konkret nachgefragt: Gibt es in Dovecot eine Option wie in Postfix „smtpd_tls_auth_only“?
# Disable LOGIN command and all other plaintext authentications unless # SSL/TLS is used (LOGINDISABLED capability). Note that if the remote IP # matches the local IP (ie. you're connecting from the same computer), # the connection is considered secure and plaintext authentication is # allowed. # See also ssl=required setting. disable_plaintext_auth = yes
Mit freundlichen Grüßen Christian Schmidt
Tach,
Am 09.01.2015 um 15:01 schrieb Christian Schmidt Christian.Schmidt@chemie.uni-hamburg.de:
Und nur noch mal konkret nachgefragt: Gibt es in Dovecot eine Option wie in Postfix „smtpd_tls_auth_only“?
# Disable LOGIN command and all other plaintext authentications unless # SSL/TLS is used (LOGINDISABLED capability). Note that if the remote IP # matches the local IP (ie. you're connecting from the same computer), # the connection is considered secure and plaintext authentication is # allowed. # See also ssl=required setting. disable_plaintext_auth = yes
Danke - das war es, was ich wissen wollte :). [10-auth.conf & 10-ssl.conf]
Viele Grüße, Michael
Hallo Patrick,
On Thu, Jan 08, 2015 at 02:35:16PM +0100, Patrick Ben Koetter wrote:
Hallo Michael,
PLAIN mit TLS bringt die höchste Sicherheit. Mit TLS erzwingst Du eine verschlüsselte Strecke. Mit dieser schützt Du die Datenübertragung des PLAIN Mechanismus. Der widerum ermöglicht, Kennworte verschlüsselt im Backend abzulegen.
Erzwinge TLS _vor_ AUTH oder lehne die AUTH ab bzw. biete sie dann nicht an.
smtpd_tls_auth_only = yes
wenn ich das aktiviere, bekomme ich einen 554 Relay access denied. Ich bin SASL authentifiziert, aber Postfix leitet nicht mehr weiter. Deaktiviert klappt alles. Ist mein Client-MTA (auch Postfix) falsch konfiguriert und will kein TLS sprechen? Zumindest ist nichts dahingehend umkonfiguriert.
Tobias
* Tobias Walkowiak tw@count0.net:
Hallo Patrick,
On Thu, Jan 08, 2015 at 02:35:16PM +0100, Patrick Ben Koetter wrote:
Hallo Michael,
PLAIN mit TLS bringt die höchste Sicherheit. Mit TLS erzwingst Du eine verschlüsselte Strecke. Mit dieser schützt Du die Datenübertragung des PLAIN Mechanismus. Der widerum ermöglicht, Kennworte verschlüsselt im Backend abzulegen.
Erzwinge TLS _vor_ AUTH oder lehne die AUTH ab bzw. biete sie dann nicht an.
smtpd_tls_auth_only = yes
wenn ich das aktiviere, bekomme ich einen 554 Relay access denied. Ich bin SASL authentifiziert, aber Postfix leitet nicht mehr weiter. Deaktiviert klappt alles. Ist mein Client-MTA (auch Postfix) falsch konfiguriert und will kein TLS sprechen? Zumindest ist nichts dahingehend umkonfiguriert.
Sehr wahrscheinlich hast Du dann kein "permit_sasl_authentiated" vor "permit_mynetworks" geschaltet. So ist ein Sender dann zwar authentifiziert (Postfix kennt ihn), aber er darf halt nichts (Postfix erhöht nicht seine Rechte).
p@rick
On Mon, Jan 12, 2015 at 09:01:32AM +0100, Patrick Ben Koetter wrote:
smtpd_tls_auth_only = yes
wenn ich das aktiviere, bekomme ich einen 554 Relay access denied. Ich bin SASL authentifiziert, aber Postfix leitet nicht mehr weiter. Deaktiviert klappt alles. Ist mein Client-MTA (auch Postfix) falsch konfiguriert und will kein TLS sprechen? Zumindest ist nichts dahingehend umkonfiguriert.
Sehr wahrscheinlich hast Du dann kein "permit_sasl_authentiated" vor "permit_mynetworks" geschaltet. So ist ein Sender dann zwar authentifiziert (Postfix kennt ihn), aber er darf halt nichts (Postfix erhöht nicht seine Rechte).
Das war es leider nicht. Auf Clientseite habe ich keine tls-Settings und # postconf -n | grep sasl smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl-passwd als einzige SASL-Settings. Ich werd mal weitersuchen.
Danke schonmal! Tobias
On Mon, Jan 12, 2015 at 09:01:32AM +0100, Patrick Ben Koetter wrote:
smtpd_tls_auth_only = yes
wenn ich das aktiviere, bekomme ich einen 554 Relay access denied. Ich bin SASL authentifiziert, aber Postfix leitet nicht mehr weiter. Deaktiviert klappt alles. Ist mein Client-MTA (auch Postfix) falsch konfiguriert und will kein TLS sprechen? Zumindest ist nichts dahingehend umkonfiguriert.
Sehr wahrscheinlich hast Du dann kein "permit_sasl_authentiated" vor "permit_mynetworks" geschaltet. So ist ein Sender dann zwar authentifiziert (Postfix kennt ihn), aber er darf halt nichts (Postfix erhöht nicht seine Rechte).
Die Lösung war, daß ich explizit auf Clientseite noch smtp_tls_security_level = may setzen mußte.
Hallo Michael,
ich denke schon die ganze Zeit darüber nach, ob der Authentifizierungsmechanismus „plain“ ein Sicherheitsrisiko ist, welchen ich in Postfix mit „smtpd_sasl_security_options“ bzw. „smtpd_sasl_tls_security_options“ und in Dovecot unter „auth_mechanisms“ angeben kann?! Ich bin geneigt dazu das Tor so weit wie möglich zu schliessen und nur die höchste und "verschlüsselste" Authentifizierungsmethode zuzulassen - aber ist das sinnvoll? Je nach Client kann es da zu Problemen führen, weil nicht alle Clients alle Möglichkeiten durchprobieren und deswegen der Erklärungsaufwand höher ist.
Wenn ich die diversen Dokus/Bücher richtig verstanden habe, dann wird bei IMAP logischerweise (wenn ich Dovecot als IMAP-Server einsetze) Dovecot als Authentifizierungsinstanz genutzt. Wenn ich jetzt
auth_mechanisms = plain, login, ...
setze - wie wird dann eine Anmeldung per IMAPS vorgenommen? Wird die Authentifizierung verschlüsselt ablaufen? Und stellt Plaintext in dem Falle ein Sicherheitsrisiko dar?
Zunächst einmal hat die Art der Authentifizierung nichts mit einer verschlüsselten Verbindung zu tun. Ist eine Verbindung verschlüsselt, so werden jegliche Daten (auch das Passwort) nicht mehr im Klartext übertragen. Sowohl bei PLAIN als auch LOGIN sendet der Client das Passwort zum Server. Im Kontrast dazu gibt es CRAM-MD5, womit der Client den Server davon überzeugen kann, das Passwort zu kennen, aber ohne das Passwort tatsächlich zu übertragen. Bei CRAM-MD5 muss dagegen das Kennwort im Klartext auf dem Server gespeichert werden.
Und wie ist das bei Postfix? Ich kann mit
smtpd_sasl_security_options = noanonymous, noplaintext smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
festlegen, dass bei einer unverschlüsselten SMTP-Session sowohl keine anonyme Authentifizierung als auch keine im Plaintext stattfinden darf. Um es komfortabler zu machen, kann ich aber auch
smtpd_sasl_security_options = noanonymous, noplaintext smtpd_sasl_tls_security_options = noanonymous
festlegen. Damit kann ich TLS-verschlüsselt auch wieder Plaintext verwenden.
Würde denn auch
smtpd_sasl_security_options = noanonymous smtpd_sasl_tls_security_options = $smtpd_sasl_security_options smtpd_tls_auth_only = yes
zu dem gleichen Ergebnis führen, wenn ich nur verschlüsselte Authentifizierung erlauben will? Denn dann würde ja smtpd_sasl_security_options gar nicht zum Zuge kommen, oder?
Was ist nun eine sichere und zugleich komfortable Konfiguration, damit sich am besten alle möglichen Clients einfach per IMAPS/SMTPS authentifizieren können?
Erzwinge einfach eine verschlüsselte Verbindung für alle deine Benutzer, falls du einen dedizierten submission-Port verwendest: smtpd_tls_security_level = encrypt
Mithilfe von smtpd_tls_auth_only = yes lässt sich erzwingen, jegliche Art der Authentifizierung nur über verschlüsselte Verbindungen zuzulassen.
Viele Grüße Thomas
On 01/08/2015 01:46 PM, Thomas Preißler wrote:
in Dovecot unter „auth_mechanisms“ angeben
Bei CRAM-MD5 muss dagegen das Kennwort im Klartext auf dem Server gespeichert werden.
Wo steht bitte geschrieben, dass bei Verwendung von CRAM-MD5 das Passwort im Klartext gespeichert werden muss? Diese Aussage ist schlicht falsch.
Wer seine Passwörter — wie mit "doveadm pw [-s CRAM-MD5]" erzeugt —, als Hash in Dovecots passdb speichert, kann folgende Authentifizierungs-Mechanismen anbieten:
auth_mechanisms = plain login cram-md5
Wenn die authentifizierte Kommunikation mit Dovecot und Postfix aber eh über eine verschlüsselte Verbindung erfolgen soll, dann würde ich mich mit "auth_mechanisms = plain login" begnügen. Dafür aber nur Hashes der Passort-Schemes BLF-CRYPT oder SHA256-CRYPT/SHA512-CRYPT in Dovecots passdb speichern.
Gruß Pascal
Hallo Pascal,
On Jan 8, 2015, at 3:36 PM, Pascal Volk user+postfix-users-de@localhost.localdomain.org wrote:
On 01/08/2015 01:46 PM, Thomas Preißler wrote:
in Dovecot unter „auth_mechanisms“ angeben
Bei CRAM-MD5 muss dagegen das Kennwort im Klartext auf dem Server gespeichert werden.
Wo steht bitte geschrieben, dass bei Verwendung von CRAM-MD5 das Passwort im Klartext gespeichert werden muss? Diese Aussage ist schlicht falsch.
Bei CRAM-MD5 wird ein sog. HMAC-MD5-Hash des Passworts berechnet und von Server und Client auf die Challenge angewendet. Dovecot speichert dann einfach nur den HMAC-MD5-Hash. Dies bringt aber so gut wie keinen Vorteil, da dieser Hash von einem Angreifer genutzt werden kann um sich bei einem Server zu authentifizieren, so als ob er das Passwort hätte. Einzige Einschränkung ist, dass dieser Hash nur für CRAM-MD5 logins genutzt werden kann. Peer Heinlein erläutert das in seinem Dovecot-Buch auf Seiten 93-97 recht ausführlich
Viele Grüße Thomas
On 01/08/2015 03:22 PM, Thomas Preißler wrote:
Hallo Pascal,
On Jan 8, 2015, at 3:36 PM, Pascal Volk user+postfix-users-de@localhost.localdomain.org wrote:
Wo steht bitte geschrieben, dass bei Verwendung von CRAM-MD5 das Passwort im Klartext gespeichert werden muss? Diese Aussage ist schlicht falsch.
[...] Einzige Einschränkung ist, dass dieser Hash nur für CRAM-MD5 logins genutzt werden kann.
Nein, auch falsch.
Speicher einen CRAM-MD5 Hash in der passdb. Und Du kannst PLAIN, LOGIN und CRAM-MD5 zum Anmelden verwenden. Überzeuge Dich bitte selber davon.
Peer Heinlein erläutert das in seinem Dovecot-Buch auf Seiten 93-97 recht ausführlich
Nobody's Perfect ... Weder habe, noch vermisse, ich das genannte Buch.
Gruß Pascal
Hallo Pascal,
On Jan 8, 2015, at 3:36 PM, Pascal Volk user+postfix-users-de@localhost.localdomain.org wrote:
Wo steht bitte geschrieben, dass bei Verwendung von CRAM-MD5 das Passwort im Klartext gespeichert werden muss? Diese Aussage ist schlicht falsch.
[...] Einzige Einschränkung ist, dass dieser Hash nur für CRAM-MD5 logins genutzt werden kann.
Nein, auch falsch.
Speicher einen CRAM-MD5 Hash in der passdb. Und Du kannst PLAIN, LOGIN und CRAM-MD5 zum Anmelden verwenden. Überzeuge Dich bitte selber davon.
Diese Aussage ist etwas aus dem Kontext gerissen. Was ich meine: Sollte der HMAC-MD5 abhanden kommen, kann dieser von einem Angreifer genutzt werden, um sich damit per CRAM-MD5 anzumelden, nicht jedoch per PLAIN oder LOGIN. Bei CRAM-MD5 ist der HMAC-MD5 genau so viel Wert wie das Passwort. Einziger Vorteil gegenüber einem Passwort im Klartext ist, dass der HMAC-MD5 nicht für ein Webinterface o.ä. genutzt werden kann. Selbstverständlich kann ein Client trotzdem PLAIN und LOGIN nutzen. Der Server erzeugt aus dem Passwort dann einfach wieder ein HMAC-MD5 und vergleicht das mit dem gespeicherten Wert, genau wie wenn SSHA512 o.ä. zum Einsatz kommt.
Viele Grüße Thomas
Hallo Pascal,
Am 08.01.2015 um 15:36 schrieb Pascal Volk user+postfix-users-de@localhost.localdomain.org:
On 01/08/2015 01:46 PM, Thomas Preißler wrote:
in Dovecot unter „auth_mechanisms“ angeben
Bei CRAM-MD5 muss dagegen das Kennwort im Klartext auf dem Server gespeichert werden.
Wo steht bitte geschrieben, dass bei Verwendung von CRAM-MD5 das Passwort im Klartext gespeichert werden muss? Diese Aussage ist schlicht falsch.
Wer seine Passwörter — wie mit "doveadm pw [-s CRAM-MD5]" erzeugt —, als Hash in Dovecots passdb speichert, kann folgende Authentifizierungs-Mechanismen anbieten:
auth_mechanisms = plain login cram-md5
Wenn die authentifizierte Kommunikation mit Dovecot und Postfix aber eh über eine verschlüsselte Verbindung erfolgen soll, dann würde ich mich mit "auth_mechanisms = plain login" begnügen. Dafür aber nur Hashes der Passort-Schemes BLF-CRYPT oder SHA256-CRYPT/SHA512-CRYPT in Dovecots passdb speichern.
Zur Zeit habe ich noch Postfixadmin als Datengrundlage und hier habe ich es mit CRAM-MD5 gelöst - nur dass ich eben nur CRAM-MD5 zugelassen habe, was ab und an bei Nutzern zu Fehlern führte :(. Nun will ich auf Modeboa umsteigen und da werde ich es genau wie von Dir beschrieben machen. Danke nochmal für die Aufklärung - ich hatte mich etwas in den ganzen Verschlüsselung-/Authentifizierungmöglichkeiten verheddert.
Viele Grüße, Michael
participants (6)
-
Christian Schmidt -
Michael Köhler -
Pascal Volk -
Patrick Ben Koetter -
Thomas Preißler -
Tobias Walkowiak