Dovecot/LDAP MD5
Stefan Dreyer
ich wï¿œrde gerne dovecot mit DIGEST-MD5 und/oder CRAM-MD5 einsetzen. Ich
habe jetzt mal probiert als PW-Hash im LDAP MD5 zu benutzen. Aber das
scheint trotzdem nicht zu funktionieren. Ich mï¿œchte natï¿œrlich nicht die
PWs im Klartext im LDAP stehen haben.
Wie kann man also dovecot mit MD5 Authentifizierung einrichten?
Sven Hartge
> ich würde gerne dovecot mit DIGEST-MD5 und/oder CRAM-MD5 einsetzen.
> Ich habe jetzt mal probiert als PW-Hash im LDAP MD5 zu benutzen. Aber
> das scheint trotzdem nicht zu funktionieren. Ich möchte natürlich
> nicht die PWs im Klartext im LDAP stehen haben. Wie kann man also
> dovecot mit MD5 Authentifizierung einrichten?
So? Gar nicht. Beide Verfahren brauchen ein Klartext-Passwort auf beiden
Seiten, Client wie Server.
Hast du dies nicht, geht es nicht. Das ist bei allen
Challenge-Handshake-Verfahren so.
S°
--
Sig lost. Core dumped.
Stefan Dreyer
Lässt sich dann ldap so absichern, dass man als Benutzer nicht sein
eigenes Passwort einsehen kann?
Oder anders gefragt, wenn ich imaps und pop3s anbiete. Wie hoch ist der
Sicherheitsgewinn dann noch mit *-MD5?
Clemens Zauner
>> Hast du dies nicht, geht es nicht. Das ist bei allen
>> Challenge-Handshake-Verfahren so.
>
> eigenes Passwort einsehen kann?
Ja.
cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS
Stefan Dreyer
> Stefan Dreyer <Stefan...@ddnetservice.net> wrote:
>>> Hast du dies nicht, geht es nicht. Das ist bei allen
>>> Challenge-Handshake-Verfahren so.
>>
>> L�sst sich dann ldap so absichern, dass man als Benutzer nicht sein
>> eigenes Passwort einsehen kann?
>
> Ja.
Ich w�re Dir zu tiefstem Dank verbunden, wenn Du mir einen Tip geben
w�rdest, wie. Ich bin mir da n�mlich nicht so richtig im Klaren, wie das
aussehen k�nnte.
Sven Hartge
> Am 17.05.2010 15:06, schrieb Clemens Zauner:
>> Stefan Dreyer <Stefan...@ddnetservice.net> wrote:
>>>> Hast du dies nicht, geht es nicht. Das ist bei allen
>>>> Challenge-Handshake-Verfahren so.
>>>
>>> Lässt sich dann ldap so absichern, dass man als Benutzer nicht sein
>>> eigenes Passwort einsehen kann?
>>
>> Ja.
> Ich wäre Dir zu tiefstem Dank verbunden, wenn Du mir einen Tip geben
> würdest, wie. Ich bin mir da nämlich nicht so richtig im Klaren, wie
> das aussehen könnte.
Normaleweise erfolgt eine Prüfung des Passwortes ja gegen LDAP
dergestalt, das der Server einen Bind an das Verzeichnis mittels des DNs
und Passwortes des Users versucht.
Ist dieser erfolgreich, so ist der Benutzer authentifiziert.
In deinem Fall funktioniert das so nicht mehr.
In deinem Fall nutzt du nicht mehr bind(DN, Passwort), sondern der
Server bindet sich mit einem "Service-Account", der immer gleich ist, an
den LDAP, liest dort das Klartext-Passwort aus und nutzt dieses dann für
das Challenge-Handshake-Verfahren.
Wenn du das Attribute userPassword nicht auf Klartext umstellen willst,
dann brauchst du ein separates Attribut mit dem Klartext-Inhalt.
Wenn du userPassword umstellen kannst/willst, dann musst du es mittels
ACL so schützen, dass nur "=x" für den User selbst gilt, aber "=r" für
den Service-Account, den dein Server zum Auslesen benutzt.
Wenn du POP3s und IMAPs verwendest, gewinnst du aber mit DIGEST-MD5 oder
CRAM-MD5 nichts.
Matthias Andree
> Wenn du POP3s und IMAPs verwendest, gewinnst du aber mit DIGEST-MD5 oder
> CRAM-MD5 nichts.
Es sei denn, die Kiste wäre etwas schwachbrüstig, mit ordentlich
Datenrate, ohne crypto-engines und mit vielen Benutzern - denn *-MD5
rechnet nur ein paar MD5-Hashes aus, während TLS dann alle Datenströme
durch die CPU nudeln muss.
--
Matthias Andree
Stefan Dreyer
Naja, bei MD5 werden nur die Passwörter verschlüsselt. Bei TLS wird dann
komplette Datenstrom verschlüsselt. Das ist schon ein
Sicherheitsunterschied. Die Kiste, auf dem das läuft, wird über
absehbare Zeit eine zweistellige Nutzerzahl haben. Das sollte die also
locker mitmachen.
Heiko Schlenker
> On 05/18/10 01:21, Matthias Andree wrote:
>> Am 17.05.2010, 15:31 Uhr, schrieb Sven Hartge:
>>
>>> Wenn du POP3s und IMAPs verwendest, gewinnst du aber mit DIGEST-MD5 oder
>>> CRAM-MD5 nichts.
>>
>> Datenrate, ohne crypto-engines und mit vielen Benutzern - denn *-MD5
>> durch die CPU nudeln muss.
>
> komplette Datenstrom verschlï¿œsselt. Das ist schon ein
> Sicherheitsunterschied.
Naja, was bringt es, nur die "letzte Meile" zu verschlï¿œsseln,
wï¿œhrend der restliche Transportweg unverschlï¿œsselt ist? Anders
formuliert: Sind die Daten sensibel, dann sollte zu einer
Ende-zu-Ende-Verschlï¿œsselung gegriffen werden. Zum Schutz von
Passwï¿œrtern ist TLS und Co. eher ï¿œberdimensioniert. Andererseits
besteht der Vorteil des Verfahrens darin, dass es
anwendungsunabhï¿œngig ist. Es gilt also abzuwï¿œgen. Erst nachdenken
(Schutzziele definieren usw.), dann handeln -- nicht umgekehrt. ;-)
Gruￜ, Heiko
Sven Hartge
Das ist korrekt.
Aber im Normalfall will ich nicht nur mein Passwort gesichert wissen,
sondern bitte auch alle restliche Kommunikation zwischen Server und
Client.
Stefan Dreyer
> Naja, was bringt es, nur die "letzte Meile" zu verschlï¿œsseln,
> wï¿œhrend der restliche Transportweg unverschlï¿œsselt ist? Anders
> formuliert: Sind die Daten sensibel, dann sollte zu einer
> Ende-zu-Ende-Verschlï¿œsselung gegriffen werden. Zum Schutz von
> Passwï¿œrtern ist TLS und Co. eher ï¿œberdimensioniert. Andererseits
> besteht der Vorteil des Verfahrens darin, dass es
> anwendungsunabhï¿œngig ist. Es gilt also abzuwï¿œgen. Erst nachdenken
> (Schutzziele definieren usw.), dann handeln -- nicht umgekehrt. ;-)
Nun der SMTP-Server bietet auch TLS an. Also liegt es ganz an den
Benutzern, bzw. der Gegenseite. Wenn dort der Mailserver auch TLS
unterstï¿œtzt, sollte das ganze ja kein Problem sein.
Aber ein Restrisiko bleibt immer und liegt letztendlich beim Benutzer.
Heiko Schlenker
> Am 18.05.2010 13:15, schrieb Heiko Schlenker:
>> Naja, was bringt es, nur die "letzte Meile" zu verschlï¿œsseln,
>> wï¿œhrend der restliche Transportweg unverschlï¿œsselt ist? Anders
>> formuliert: Sind die Daten sensibel, dann sollte zu einer
>> Ende-zu-Ende-Verschlï¿œsselung gegriffen werden. Zum Schutz von
>> Passwï¿œrtern ist TLS und Co. eher ï¿œberdimensioniert. Andererseits
>> besteht der Vorteil des Verfahrens darin, dass es
>> anwendungsunabhï¿œngig ist. Es gilt also abzuwï¿œgen. Erst nachdenken
>> (Schutzziele definieren usw.), dann handeln -- nicht umgekehrt. ;-)
>
> Nun der SMTP-Server bietet auch TLS an. Also liegt es ganz an den
> Benutzern, bzw. der Gegenseite.
Als Serverbetreiber sollte man dafï¿œr sorgen, dass auch dann, wenn
kein TLS o.ￜ. verwendet wird, keine Klartextpasswￜrter ￜbertragen
werden.
Gruￜ, Heiko
Stefan Dreyer
Wï¿œrde ich am liebsten auch. Das, was mich daran stï¿œrt ist, dass ich dann
die Passwï¿œrter im Klartext speichern muss und einigen anderen
Applikationen einen Account mitgeben muss, der alle Benutzernamen im
Klartext lesen kann. Wenn es nur der dovecot-Daemon wï¿œre, wï¿œre das ja
kein Problem. Da sich die Clients auch innerhalb meines(tm) Netzes
befinden, scheint mir das Risiko auf *-MD5 zu verzichten einfach das
geringste zu sein.
Heiko Schlenker
Wenn es Dir wirklich um den Schutz der Passwï¿œrter geht, dann wï¿œrde
ich das nicht in die Hï¿œnde der Kunden legen wollen. :->
Gruￜ, Heiko
Clemens Zauner
>>> L�sst sich dann ldap so absichern, dass man als Benutzer nicht sein
>>> eigenes Passwort einsehen kann?
>>
>> Ja.
>
> Ich w�re Dir zu tiefstem Dank verbunden, wenn Du mir einen Tip geben
> w�rdest, wie. Ich bin mir da n�mlich nicht so richtig im Klaren, wie das
> aussehen k�nnte.
Das h�ngt von der verwendeten LDAP-Software ab. Falls du openldap
verwendest - ich glaube da kommt sogar ein Beispiel in einer example-
slapd.conf.
Angenommen du verwendest openldap, dann ist der Abschnitt "Access Control"
auf jeden fall ein heisser Lesetip - abgesehen von der bestimmten
Aufgabestellung. Zu finden z.B. unter
<http://www.openldap.org/doc/admin24/access-control.html>