Hi,
vielen lieben Dank für die Antwort.
Nunja - ich bin wie gesagt neu bei EGW und habe wenig Erfahrung mit MySQL
(insbesondere was Zugriffsmöglichkeiten von außen und der Verarbeitung der
Datenbankeinträge innerhalb von EGW angeht). Aus grundsätzlichen
sicherheitstechnischen Überlegungen sollte in meinem Verständnis ein
Passwort niemals in Klartext abgelegt werden - immerhin entsteht hierbei ein
potentielles Sicherheitsrisiko. Ich weiß nicht inwieweit dies gerechtfertigt
ist.
Ich habe nun einmal eine neue Installation von EGW mit eingeschaltetem
mcrypt aufgebaut.
Allerdings musste ich festellen dass nun immernoch die Passwörter der IMAP
Konten im Klartext abgespeichert werden (z.B. in Tabelle
’egw_felamimail_accounts’). Muss ich hier noch etwas zusätzlich einstellen
oder ist dies ein Bug (wie hier beschrieben:
http://www.egroupware.org/egroupware/index.php?menuaction=tracker.tracker_ui.edit&tr_id=1894)
Crypt und MD5 berechnen für einen beliebigen Eingabestring einen Hash.
Der Hash hat Eigenschaften, die für das Prüfen des EGroupware-Passwortes
nützlich sind.
Es ist fast unmöglich, dass zwei verschiedene Eingaben genau denselben
Hash-Wert ergeben;
die Funktion liefert bei gleichem Passwort immer den gleichen Hash;
Es lässt sich nicht vom Ergebnis auf die Eingabe schliessen (klar, außer
durch Ausprobieren).
Das Passwort für die Benutzeranmeldung muss nicht mehr in der Datenbank
gespeichert werden.
Für die Anmeldung an einem Mail-Server muss in der Regel eine
Kombination von Benutzername und Passwort geliefert werden, damit der
Server authentifizieren kann. Der Unterschied ist, dass EGroupware diese
Kombination kennen muss, um sie ausliefern zu können, also kann mdcrypt
nicht helfen.
Wohl kann das Passwort aber SSL-verschlüsselt übertragen werden.
Die grundsätzliche Überlegung, ein Passwort niemals im Klartext zu
speichern finde ich sicher richtig.
Ein Angreifer muss schon Zugriff auf die Datenbank haben (und kann den
ganzen Inhalt auslesen!).
Nehmen wir an, dass das Passwort verschlüsselt in der DB abgelegt ist.
EGw hat also eine Funktion, um zu verschlüsseln und um das
verschlüsselte Passwort wiederherzustellen.
Ein Angreifer könnte kurz gesagt versuchen, die gleiche Funktion zu
nutzen, um das Passwort zu berechnen. Eine zusätzliche Hürde könnte
sein, dass das vom Web-Server beschreibbare Dateisystem eingebunden wird.
Dadurch muss der Angreifer auch das Dateisystem lesen können, z.B.
FTP-Zugriff haben oder den Web-Server erfolgreich angreifen.
Mit dem Zugriff auf das Dateisystem im Kontext des FTP- oder Web-Servers
besteht immerhin die Möglichkeit, das Klartext-Passwort für die
EGw-Datenbank auszulesen.
Umgekehrt, bei jeder Anmeldung über HTTP oder FTP wird die
Authentifizierung im Klartext übertragen, und jeder Teilnehmer der
Übertragung kann einfach mitlesen.
Du musst zumindest deinem Provider und dem Webhoster voll vertrauen, und
zumindest sicherstellen, dass weder auf deinem Internet-Router noch auf
deiner Maschine mitgelesen wird.
Grüße,
Sebastian
Eine andere Sache ist mir hierbei noch aufgefallen. Vielleicht kann dies
jemand nachvollziehen: Wenn ich das Standardkonto in emailadmin einrichte
(IMAP, währens des Setups) und hier alle Kennwörter hinterlege so kann er
nicht mit dem IMAP-Server verbinden: ‘NO, authetification failure’.
Hinterlege ich dageben DIE GLEICHEN Daten in den "persönlichen Identitäten’
klappt der Zugriff. Die hinterlegten Zugangsdaten stimmen in beiden Fällen
(Lässt sich ja sehr einfach nachvollziehen dank fehlender Verschlüsslung in
der DB, hehe)
Vielen Dank!
Gruß
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german