Passwörter

  • Glückwunsch erstmal an alle Entwickler für den aktuellen RC - habe ihn in einem Kubuntu (hatte ich noch "rumliegen") (12.10)-Testsystem in einer VM mal installiert und getestet. Musste lediglich den Paketnamen "diff" auf "diffutils" ändern, da sich dpkg sonst beschwerte und die Installaton mit Fehler 100 ausstieg. Der Rest der Installation lief ohne Probleme und es laufen auch alle Dienste wunderbar. Das kenne ich aus Zeiten von ispcp noch ganz anders, da musste ich wirklich massiv Hand anlegen.


    Zum Thema:
    Da ispcp out-of-the-box eigentlich gar nicht lief, musste ich an vielen Stellen patchen, was das Gesamte quasi auch unwartbar gemacht hat. Einmal hab ich ein Update versucht, aber das war quasi ein Desaster. Ich setze daher noch die 1.0.2 ein, die im Groben auch läuft, allerdings verzichte ich auch auf globale Redirects wie "^/imscp[\/]?$", da solche regelmäßig von Bots abgegrast werden. Das werde ich auch bei imscp deaktivieren, aber das soll jetzt nicht der Diskussionspunkt sein :-)
    Mit meinen gut 200 Domains und 1000 Mailkonten stehe ich nun vor der Aufgabe, von einem 32Bit Gentoo auf eines mit 64 Bit zu wechseln und dabei die Kunden von ispcp auf imscp zu migrieren. Wird einiges an Handarbeit sein, zumal Migrations-Scripte bei einer solch alten Installation ja nicht greifen, aber das werde ich schon hinkriegen.


    Jedoch ist mir das Speichern von Klartextpasswörtern ein Dorn im Auge - wohlwissend, dass es bei ispcp nicht viel besser ist. Ich möchte jetzt an dieser Stelle auch nicht über Sinn oder Unsinn streiten, spiele aber mit dem Gedanken, die Passwörter vorzugsweise als Hashes (md5 oder sha1) abzulegen.


    Da ich mich noch nicht durch den Code gearbeitet habe frage ich daher vorher: mit welchen Problemen werde ich, sofern ich das versuche umzusetzen, voraussichtlich zu kämpfen haben? Oder anders gefragt: an welchen Stellen werden die unverschlüsselten PWDs denn überall benötigt? Courier - das kann ich vorwegnehmen - ist keines, ich setze (zum Glück) seit vier Jahren Dovecot ein.


    Bitte um Hinweise und Tipps.


    Danke im voraus!

  • Ich glaub seine Frage war nicht, ob das umgesetzt wird, sondern auf was er achten muss, wenn er selber Hand anlegt :)


    biologist verschlüssel mal ein Passwort in der Datenbank (mail, db...) und gugg, ob du dich immer noch in die Dienste anmelden kannst. Im besten Falle ja, im schlimmsten Falle solange, bis die configfiles für email und db mit dem imscp-db-Passwort generiert werden. Dann müsstest du wahrscheinlich den Weg des Erstellen von Configfiles ändern (direkt beim übergeben des PLAIN-Text die Files erzeugen oder nach Erzeugen das db-Passwort erst verschlüsseln)...

  • Hi biologist


    Deine Frage kann auch umformuliert werden: wo werden die (Klartext)Passwörter denn verwendet?
    Zurzeit werden MySQL- und Mailpasswörter im Klartext gespeichert.


    Für die MySQL-PWs würde ich *wenn*, dann die Passwörter in der imscp Tabelle auch so speichern, wie MySQL das tut (MySQL Standard Hash-Funktion) - was danach sehr wahrscheinlich nicht mehr geht: das direkte Einloggen mit einem Klick auf "phpMyAdmin" auf der Seite Datenbanken (beim Endkunden) - da wird ja ein POST Request simuliert (mit dem Klartext-Passwort), um dann ein Cookie zu erstellen und dann an pma weiterzuleiten... eingeloggt...
    Die Mailpassworte werden wohl bis jetzt nur für den Courier und sasldb2 -Unterhalt benötigt...
    Wenn sowohl POP/IMAP wie auch SASL über dovecot geht, dann nehme ich an, könnte es ok sein.


    Das Panel muss halt ein wenig mehr leisten und daher behält es das Originale Passwort mal - ob das verschlüsselt sein soll oder nicht... das ist ein anderes Thema. Die Ideen dahinter dürften folgende sein:
    - unterstützen eines anderen Mailservers (der wieder andere Hash-Werte benötigen könnte) oder zB. ein Umstieg auf eine andere DB (obwohl ich annehme dass zB. MariaDB dieselben PW-Hashs verwendet).


    Der beste Weg wäre wohl: speichere die Passwörter mit den aktuell guten Hash-Methoden und das Klartext Passwort verschlüsselt speichern - den Entschlüsselungs-Key muss der Admin bei Bedarf angeben (wird also nicht auf dem Server gespeichert) - damit sollte die Zukunft gesichert sein. Der Direktaufruf in ein eingeloggtes pma wird aber so wohl nicht mehr gehen (was auch keine Katastrophe darstellt).
    Essenziell dünkt mich noch (wenn wir das Thema grad haben :-), dass das Klartextpasswort und das verschlüsselte (oder der/die Hashes) nicht im selben Feld gespeichert werden: Die Probleme, dass Passwörter bei einem Update plötzlich zweimal verschlüsselt sind, kennen wir vom Fork-Vorgänger zur Genüge...
    Also ein Feld cleartextpw und pro Hash ein Feld und eines für das verschlüsselte... dann ist auch klar: wenn das Klartextpasswort nicht leer ist, wurde es neu gesetzt und muss noch in die anderen Felder umgewandelt werden - danach kann das Klartextpasswort gelöscht werden.


    Gut ist's OpenSource :-)


    /J

    Edited once, last by joximu ().