Verschlüsselung aller Passwörter

  • diese closed source panels kenne ich und die zeigens sogar im kundenbereich an^^ Man sollte sich bei denen aber kein Vorbild nehmen..
    Dein Szenario stimmt insofern, wenn die Passwörter sehr schwach sind. Im Adminbereich kann man aber eine Mindestlänger, Mindestzeichen und co einstellen, wenn das aktiviert ist hat der Angreifer sogut wie keine Chance mehr oder muss wirklich einen starken Willen zum knacken haben..
    Von daher würde ich es persönlich nach Jadawins Szenario auch gesichert haben. Security by obsurity sollte hier vermieden werden. Hoffe ich bringt das in die nächste Version mit rein, dass die Admins auch keine Bedenken haben diesbezüglich :))


  • Verstehe mich bitte nicht falsch. Ich nehme Deine Gedanken ernst und tue es nicht einfach so ab. Ein richtiger Angreifer kennt sich mit der Materie aus.
    Ihm würde der Root Zugriff auf die Datenbank vollkommen ausreichen. Ob verschlüsselte Passwörter ein großer Wall für ihn sind, will ich bezweifeln.
    In kürzester Zeit hat er diese entschlüsselt.
    Das ist einfach kein Schutz der Dein Szenario nur ansatzweise schützen würde.


    Wenn die Passwortverschlüsselung richtig gemacht wird nützen dem Angreifer die Hashes gar nichts. Hab dazu kurz was im ersten Post geschrieben, kanns dir aber gerne noch detaillierter darlegen.



    Auch wenn ich die Thematik selbst schon mal im Internen angestoßen habe, werde ich es gerne noch einmal ansprechen.


    Ja gerne :)



    Aber wenn ich mich nicht täusche gibt es auch große closed Sources Panel die auch ihre Mail-, FTP- und DB-Passwörter Plain abspeichern.


    Unter anderem ein Grund, warum ich Open Source bevorzuge...

  • Ich stimme Jadawin auch zu, es muss ja nicht unbedingt darum gehen, dass der Angreifer root-Zugriff auf die DB bzw den Server hat, sondern einfach Zugriff auf die imscp-DB bekommt. Mir geht es unteranderem um die Diskretion zum Kunden, wenn der fragt, ob die PWs alle verschlüsselt gespeichert sind und man mit Nein antworten muss, sehen das bestimmt Kunden als Sicherheitsmangel.


    Flo

  • Hi


    zuerst muss die Frage geklärt werden, ob ein Passwort Hash reicht.


    i-MSCP kann verschiedene MDA (pop3/imap) bedienen (courier und dovecot). Und zumindest bei Courier ist es so, dass die Benutzerdatenbank von i-mscp verwaltet wird und da beim erstellen oder ändern eines Mail-Users dessen Passwort übergeben werden muss. Ausserdem kommt das Passwort auch in die sasldb für Postfix.
    Solange i-mscp das Klartext-Passwort rekonstruieren kann, solange ist es mit wenig Aufwand möglich, alle diese Konfig-Dateien wieder neu anzulegen. Mit den Hashs alleine geht das kaum - man müsste ja fast alle Varianten von Hashes anlegen, um all die verschiedenen Programme zu bedienen.
    Ausserdem kann ein Link zu pma, welcher dann gleich einen Benutzer einloggt nur gemacht werden, wenn das MySQL-PW bekannt ist.
    Bei den FTP-Zugängen wurde früher (Vorgänger) nur ein Hash gespeichert.


    Somit ergibt sich nun die Frage: verschlüsseln oder nicht. Wenn jemand "nur" Zugriff auf die DB hat, kommt er mit den verschlüsselten PWs nicht weit - zum Entschlüsseln braucht man ja die Key-Dateien.
    Ist aber jemand als root drin oder konnte sich via i-mscp-Panel ins System hacken, dann kommt er an diese Datejn ran.
    Wirklich sicher wäre wohl nur ein Verwahren:
    Key zum Entschlüsseln liegt beim Administrator zuhause - und der kann es einsetzen, um ein System-Recovery zu machen oder um einen MDA zu wechseln etc... der Rest muss mit Hashs oder anders gelöst werden.
    Direkt Links auf pma würde es nicht mehr geben.


    Gruss
    Joxi


  • Wirklich sicher wäre wohl nur ein Verwahren:
    Key zum Entschlüsseln liegt beim Administrator zuhause - und der kann es einsetzen, um ein System-Recovery zu machen oder um einen MDA zu wechseln etc... der Rest muss mit Hashs oder anders gelöst werden.
    Direkt Links auf pma würde es nicht mehr geben.


    Denke genau das ist die beste Alternative. Sollte bei nem Update das Passwort im Klartext benötigt werden, so kann es der Admin dann beim Setup eingeben und alles ist gut. Also diesen Weg beführworte ich sehr, ist halt etwas Programmieraufwand..

  • Moin


    Dann werf ich mal was neues in den Raum: LDAP
    Die meisten Dienste können mittlerweile LDAP, proftpd, courier, dovecot, postfix, selbst SASL kann via LDAP authentifizieren.


    Vorteil ist, die Passwörter sind zentral und verschlüsselt gespeichert (keine Redundanzen -> neu anlegen der UserDB für jedes Programm entfällt -> niemand braucht ein unverschlüsseltes Passwort). Da LDAP einen hierarchischen Aufbau hat bleibt das ganze auch übersichtlich und kann notfalls auch mal ohne imscp administriert werden.


    Nachteil: Ein weiterer Dienst der möglicherweise abstürzen kann :shy: pma Login nicht mehr möglich... Aber hier kann ja für bequeme Kunden ein opt-in erstellt werden, wo sie explizit auf das Risiko (unverschlüsseltes PW) hingewiesen werden.


    Bei mir läuft openLDAP nach paar Konfigurationsschwierigkeiten problemlos seit paar Monaten. Ich nutz es zurzeit für Jabber, SVN via Apache und openVPN und ich muss sagen ich bin begeistert von :)


    Da ich mir LDAP auch in imscp wünsche, würd ich auch anbieten dabei mitzuhelfen :) (sicher mal für die LDAP Konfiguration und Einbindung in die jeweiligen Dienste. Das ganze Frontend diesbezüglich umgebaut werden, der Backendteil fällt afaik weg...)


    Hoffungsvoll
    Jadawin


    Edit: Mir ist grad ein grösseres Einfallstor für "Viren" aufgefallen: Der Pluginmechanismus. Wenn iwelche Admins Plugins von sonstwo runterladen ist die DB schnell mal exploited (Ja ok, der ganze Server auch)^^

    Edited once, last by Jadawin ().

  • Ich persönlich fände es auch wichtig das die Passwörter verschlüsselt hinterlegt sind.


    FTP, Mail und Panel-Login, sollten verschlüsselt hinterlegt sein.


  • Dann ist der direktlogin aber nicht mehr möglich ;)


    Abgesehen davon, dass es möglich wäre, kann auf den denke ich Jeder verzichten :D


    Möglich wäre es über ne zuvor erstellte und gültige session.. Ist halt etwas komplexer XD