# Passwortmanagement / Login mit UserAccounts



## nightcode (14. Juli 2016)

Hallo liebe Community, Hallo Till,

nach jahrelangem Betrieb mehrerer Server und notdürftiger Entwicklung eines eigenen, ähnlichen Systems habe ich mir nun einmal ISP Config angeschaut und mehrere dedizierte Server aufgesetzt .
Ich bin echt mehr als nur begeistert. Ich finde die Mischung zwischen zentraler Verwaltung und gleichzeitiger Anpassbarkeit einfach perfekt.
Nachdem ich alle bisherigen Probleme selbst lösen konnte bin ich nun an einer Stelle, an der ich etwas Hilfe bräuchte:

Von anderen Hostern mit ähnlichen Lösungen und auch meinem eigenen System war ich es gewohnt, die Möglichkeit zu haben, erstellte Passwörter auszulesen bzw. zumindest die Möglichkeit zu haben, mich über einen Klick z.B. in das Webmail System, den phpMyAdmin oder den WebFTP einzuloggen bzw. mir die generierten Passwörter anzeigen zu lassen. 

Das ist besonders wichtig wenn ein Kunde Probleme hat oder man sich mal schnell mit den Rechten des Kunden einloggen muss um z.B. Berechtigungen oder ähnliches zu überprüfen.
Mit ISPConfig ist das, soweit ich feststellen konnte, leider nicht möglich. Gibt es eventuell eine Möglichkeit das zu realisieren oder im Programm ein Event, welches bei jeder Passwortänderung ausgelöst wird, sodass ich dafür ein Plugin schreiben könnte?

Ich bin mir bewusst, dass dieser Mechanismus aus Sicherheitsgründen nicht vorhanden ist, jedoch macht es die effiziente Kundenbetreuung teilweise unmöglich.

Vielen Dank für die Hilfe!


----------



## Till (14. Juli 2016)

Zitat von nightcode:


> Mit ISPConfig ist das, soweit ich feststellen konnte, leider nicht möglich.


Richtig, ISPConfig verschlüsselt Passworte aus Sicherheitsgründen immer als hash mit salt, also nicht umkehrbar.



Zitat von nightcode:


> Gibt es eventuell eine Möglichkeit das zu realisieren oder im Programm ein Event, welches bei jeder Passwortänderung ausgelöst wird, sodass ich dafür ein Plugin schreiben könnte?


Jede Änderung die mittels eines Formulares in ISPConfig ausgeführt wird führt zu einem Event das Du abfangen kannst, es ist also möglich ein Plugin zu schreiben das alle Passwortänderungen abfängt.

Solche Interface Plugins findest Du unter interface/lib/plugins/, wenn Du dort mal in die Dateien rein siehst dann wirst Du feststellen dass alle einen ähnlichen Aufbau haben, in der onLoad Funktion registrieit sich das Plugin für alle Events, für die es aufgerufen werden will. Beispiel:

$app->plugin->registerEvent('client:clientn_after_insert', 'clients_template_plugin', 'apply_client_templates');

Event "client:clientn_after_insert" in der Form: Modul (Kundenmodul) Formular (Kundenformular) Event (Nach dem neu anlegen). Modulname ist der Name des Verzeichnisses des Modules, also client, mail, etc. Form name ist das Formular, findest Du in der jeweiligen Form Datei. Event gibt es on_after_insert und on_after_update.

Dann folgt "clients_template_plugin" das ist einfach der Name deines plugins, damit das eventsystem weiß welches plugin informiert werden soll.

Und 'apply_client_templates' ist die Funktion innerhalb Deines Plugins, die aufgerufen werden soll, also hier eine Funktion im Plugin "clients_template_plugin".

Die funktion bekommt immer 2 Parameter übergeben: $event_name, $page_form

Interessant für Dich ist vor allem $page_form, denn das ist das gesamte Formularpbjekt und in $page_form->id findest z.B. die primäre ID des Datensatzes (bei updates) und $page_form->dataRecord ist ein array mit allen Feldern des Formulares und deren Werten.


----------



## Till (14. Juli 2016)

Achja, noch ein ganz wichtiger Hinweis: Plugins werden bei Login eines Users eingelesen und dann für die Dauer der Session als Teil der Session verwaltet und sie registrieren sich selbst, wenn Du also ein neues Plugin programmierts, einmal ausloggen und dann wieder einloggen, sonst wird es nicht aufgerufen


----------



## nightcode (14. Juli 2016)

Klasse! Vielen Dank für den Hinweis! Ich bin begeistert und werde meine Ergebnisse hier teilen und versuchen (solange es die knappe Zeit irgendwie zulässt) ein Teil der ISPConfig-Entwicklercommunity zu werden.


----------



## nightcode (14. Juli 2016)

Vielen Dank an Till für dein enormes Engagement hier im Forum und bei der Entwicklung. 
Da wird wirklich jedem geholfen


----------



## nightcode (14. Juli 2016)

Nun stellt sich mir die Frage wie handhabt ihr denn diese Problematik?
Wenn man sich aus technischen Gründen mal in das E-Mail-Postfach des Kunden einloggen muss oder, um direkt die Dateiberechtigungen für suexec zu erhalten, sich über den für die Domain spezifizierten FTP-Account einloggen will ohne das Passwort zu kennen?

Macht es vielleicht sinn für solche fälle einen Auth token zu erstellen der dann z.B. den direkten Login in den phpMyAdmin, in Roundcube etc. ermöglicht?

*Sorry für die vielen Posts. Ich hab eine kleine Anleitung erstellt. In der hat das Forum Links gefunden obwohl gar keine vorhanden waren...*


----------



## florian030 (14. Juli 2016)

Ich wüsste nicht, was mich die Email-Konto der Kunden interessieren. Wenn jemand sein Paßwort verbummelt hat, bekommt er halt ein neues...

Was Webseiten angeht, kannst Du das doch bequem über die Shell machen.


----------



## nightcode (14. Juli 2016)

Die Konten interessieren mich nicht, jedoch ist es teilweise bei administrativen Aufgaben oder Hilfestellungen erforderlich, sich in ein Postfach einzuloggen. Idealerweise per Klick, nur dass sich Roundcube dann eben in bereits eingeloggtem Zustand öffnet (sowas habe ich z.B. bereits mit phpMyAdmin realisiert).

Natürlich kann ich das mit den Websites über die Shell machen, jedoch tut sich mein Mitarbeiter, der zwar ein hervorragender Webdesigner ist und sich gut mit CMS Systemen etc. auskennt, damit sehr schwer. Außerdem deployen wir unsere Applikationen unter anderem direkt aus dem phpStorm.


----------



## florian030 (14. Juli 2016)

Entweder der Kunde stellt Dir freiwillig seine Login-Daten zur Verfügung oder nicht. Sich heimlich irgendwo einloggen zu wollen halte ich für keine gute Idee.


----------



## nightcode (14. Juli 2016)

Ein "heimliches" Login findet natürlich nicht statt. Es ist ja auch nicht nur auf die E-Mails bezogen. Davon abgesehen komme ich als Hauptadministrator auch über Systemebene an die Postfächer wenn es wirklich darum geht.

Es ist einfach praktisch und erleichtert den Aufwand ungemein. 
Da ich Serverarbeiten meist nachts erledige fällt das "einen Kunden nach dem Passwort fragen" eh flach.

Das gehashte Konzept ist gut, sicher, sinnvoll und zeitgemäß keine Frage. Dennoch ist diese Möglichkeit für mich erforderlich.
Nur als Beispiel: Ich möchte nun über 100 E-Mail Konten auf den neuen ISPConfig MailServer migrieren.
Das wird kein Problem da mein aktuell genutzter Anbieter für den E-Mail Verkehr (all-inkl.com) eben Passwörter anzeigt bzw. ein OneClick Webmail-Login (ähnlich dem ISPConfig admin->user Login) zulässt.
Wäre ich jetzt jedoch bereits auf ISPConfig unterwegs hätte ich einen riesen Brettschiss und müsste alle E-Mail-Clients (in teilweise großen Unternehmen) rekonfigurieren.


----------



## florian030 (14. Juli 2016)

Wieso musst Du Mailclients neu konfigurieren? Der hash ändert sich nicht. Du musst ggf. nur die Datenbank (oder Teile davon) auf einen anderen Server kopieren.
Ich habe noch nie bei einem Umzug von einem Server irgendwelche Clients neu konfiguriert.


----------



## nightcode (14. Juli 2016)

Weil ich auf diesem Server keinen SSH-Zugriff habe. Er dient(e) lediglich als Mailserver und Relay-Host für meine Webserver.


----------



## Till (14. Juli 2016)

Das Hauptproblem mit dem reversibel verschlüsselten speichern von Passworten ist das Kunden (auch wenn sie es nicht sollten) Passworte häufig mehrfach verwenden, d.H. das Email Passwort geht dann unter Umständen auch bei Paypal, Amazon usw. Wenn es dann tatsächlich zum Supergau kommt das jemand unbefugt Zugriff auf die Datenbank mit den Klartextpassworten erhält, dann hat dieser unter Umständen auch Zugriff auf die Konten bei anderen (Zahlungs) Anbietern und es kann zu ernsten finanziellen Schäden kommen. Ich wäre mir in dem Fall nicht sicher ob dann das speichern von Klartextpassworten nicht grob fahrlässig wäre mit entsprechender Haftung Durch Dich für die Schäden denn es gibt ja keine technische Notwendigkeit dass diese nicht verschlüsselt sind sondern es geht um Bequemlichkeit.


----------



## nightcode (14. Juli 2016)

Keine Frage. Das ist ja der Sinn der Sache dessen bin ich mir bewusst.
Aber auch dieses Szenario lässt sich wieder beliebig weiterspielen.
Wenn der Supergau eintritt und jemand wirklich privilegierten Zugriff auf das System erhält dann ist der Zugang zum E-Mail Postfach auch äußerst wahrscheinlich und das Verwenden der "Passwort Vergessen" Funktion wäre bedeutend leichter als das Entschlüsseln der Passwörter und Durchprobieren beim Anbieter...

*Nachtrag:*
Ich bin es einfach aktuell so gewohnt und es ist einfach sehr komfortabel wenn es irgendwo mal Probleme gibt. Man kann sich halt per Mausklick "in die Situation des Kunden" begeben. Und ich glaube nicht dass in diesem Fall all-inkl.com haftet nur weil sie die Möglichkeit bieten, die Klartextpasswörter auszulesen bzw. sich direkt ins Webmail einzuloggen.


----------



## Till (14. Juli 2016)

So handhabe ich das:

Email: Wenn der Kunde möchte das ich auf sein Konto zugreife, dann teilt er mir sein Passwort mit oder ich setze es neu und teile das neue Passwort dem Kunden mit. Kontenspezifische Emailfehler die einen Zugriff auf das Postfach erfordern kommen auch eher selten bei mir vor, entweder es geht der ganze Server nicht, dann brauche ich keinen Login oder aber der Fehler erschließt sich aus dem Log, denn einen Zugang zum Postfach brauche ich nur um email Inhalte zu sehen und warum sollte ich das tun. Denn selbst mail header kann ich im Notfall einfacher als root im Maildir auf der Shell einsehen ohne einen Imap Zugang zu benötigen.

Webseiten / Dateien: Zugriff per FTP brauche ich hier nicht um dem Kunden zu helfen, da ich den root Zugang habe. Da alle FTP user der Website unter dem selben Linux User laufen, könntest Du Dir aber auch einfach ein 2. FTP Konto temporär anlegen, wenn Du das bevorzugst.

Datenbanken: Wenn ich Daten managen muss, kann ich das per MySQL root tun. Wenn sonst was nicht geht in der Webseite, dann muss ich eh in die config Datei des CMS sehen, dort steht ja auch der MySQL Zugang drin. entweder der geht dann oder ich muss ihn reparieren und sowieso neu in der config Datei setzen.


----------



## Till (14. Juli 2016)

Zitat von nightcode:


> Wenn der Supergau eintritt und jemand wirklich privilegierten Zugriff auf das System erhält dann ist der Zugang zum E-Mail Postfach auch äußerst wahrscheinlich und das Verwenden der "Passwort Vergessen" Funktion wäre bedeutend leichter als das Entschlüsseln der Passwörter und Durchprobieren beim Anbieter...


Jein, es kann sein dass derjenige nur an ein backup gekommen ist ads auf einem anderen system liegt oder nur lesenden Zugang zu den Daten hat usw. Außerdem geht es bei möglichen Schäden und Haftung immer darum ob Du das technisch mögliche unternommen hast um es zu verhindern.


----------



## nightcode (14. Juli 2016)

Danke für die Zeit die Ihr euch für diese Problematik nehmt. Ihr seid Spitze!

Diesen Gedankengang hatte ich ja auch auch schon...
Ich werde es auf diesem Weg versuchen und, wenn es mich wirklich zu sehr behindert, eine Lösung entwickeln.

Die Initialpasswörter sind halt auch so eine Sache. Oft hat sie der Kunde garnicht und es ist einfach praktisch diese abzurufen ohne jedes mal neu zu setzen oder gar einen Passwortmanager dafür zu verwenden. Insbesondere auch bei Schnittstellen oder anderen Systemen die den Zugriff auf bestimmte Konten nutzen und bei aktualisierten Passwörtern dann jedes mal neu konfiguriert werden müssten.

Beispiel: 
Ich habe ein Programm entwickelt, welches die Lieferscheine und Paketmarken eines Onlineshops automatisiert in der Versandabteilung ausdruckt. Dazu holt es die Dokumente per PDF vom IMAP Server und leitet sie an die entsprechenden Drucker weiter. Es gibt keinen externen SSH-Zugriff auf dieses System.
Will ich aus Debugging-Gründen nun in das Postfach (evtl. auch von Unterwegs wenns wirklich brennt) und habe das Passwort nicht zur Hand kann ich es nicht einfach neu setzen, da ich das System rekonfigurieren müsste was ebenfalls nicht möglich ist. Ein Ausfall wäre dort der Supergau und sehr teuer.

Aber wie gesagt: für solche Fälle werde ich halt einen vernünftigen Passwortmanager nutzen müssen...

Aber davon abgesehen bin ich echt meeeega happy mit eurem tollen ISPConfig.


----------



## nowayback (14. Juli 2016)

hi,

wenn ich lese das du dich in irgendwelche mailkonten einloggen willst, dann stellen sich bei mir die nackenhaare auf. 



Zitat von nightcode:


> Will ich aus Debugging-Gründen nun in das Postfach


Mal angenommen ich glaube dir, dass das ausschließlich für dieses Beispiel für dich wichtig ist:
Du kannst das Loglevel vom IMAP hochsetzen und siehst das der Client sich eingeloggt hat, und Daten angefordert und auch welche bekommen hat. Dazu kannst du am Eingang deiner Software debuggen und genau gucken was da angekommen ist. Wozu brauchst du das Postfach?
Sollte beim Login was schiefgehen, stehts im Log, sollte es ein Fehler mit dem Konto geben, stehts im Log, sollte es Übertragungsfehler geben, stehts im Log.... Es gibt keinen plausiblen Grund. 
Aber: wie kommt deine Software an den IMAP ohne Logindaten?  Richtig. Gar nicht. D.h. du hast doch die Daten und kannst sie sogar in deinem eigenen Programm nachlesen. Wozu brauchst du nun diese komische "ich log mich als Admin in dein Konto ein"-Funktion?

Ich weiß, klingt alles derbe, ist aber nicht böse gemeint. Es gibt nur einfach keinen plausiblen Grund, sich in ein Kundenkonto einzuloggen. In den vielen Jahren, die ich nun im IT Sektor bin, trat dieser Fall genau 0 mal auf. 

Grüße
nwb


----------



## nightcode (14. Juli 2016)

Wie gesagt den theoretischen Zugriff habe ich als Admin doch sowieso und ich achte die Privatsphäre meiner Kunden sehr und würde niemals in irgendwelchen Mailpostfächern stöbern. Es geht mir hier keinesfalls um Spionage was hier von dir eindeutig impliziert wird. Vertrauen zu seinem IT-Partner ist immer das wichtigste. Es war auch allgemein formuliert und nicht nur auf E-Mail Bezogen.

Dennoch: in den vielen Jahren, die ich nun im IT-Sektor tätig bin, trat dieses Szenario recht häufig auf!

Ich verstehe nicht wieso du dich daran so hochziehst. Es geht mir lediglich um ein einfach und effizient zu administrierendes System! 
Warum kann ich mich als Admin -> ISP User einloggen wenn ich doch auch einfach das Passwort neu setzen könnte?
Wieso kann ich das bei anderen Providern? Es macht einfach Sinn und erleichtert den Alltag.

Davon abgesehen: Wenn der ISPConfig Master-Server wirklich geknackt wird wären die "mit viel Aufwand entschlüsselbaren Passwörter" noch das geringste Problem. Man mag sich nicht ausmalen was ein Angreifer für Schaden anrichten könnte indem er DNS-Einträge umbiegt oder Websites infiziert. 
Und wenn einem durch diese Features das Sicherheitsrisiko zu hoch ist müsste man gleich auf ISPConfig oder ähnliches verzichten, denn die größte Stärke des Systems - die zentrale Verwaltung und einfache Erweiterbarkeit ganzer Serverlandschaften - ist gleichzeitig seine größte Schwäche.

Klar hab ich die Daten in der Software verankert aber wie schon gesagt kein Zugriff aufs System und die Daten nicht immer dabei. 
Der Vorteil den ich in ISPConfig sehe ist einfach die "All-in-One" Lösung also warum nicht auch zur Passwortverwaltung denn eine Kompromittierung des Systems ist und bleibt auch unabhängig davon der GAU!

Aber wie ich oben schon sagte: ich gehe jetzt diesen Weg des "neu setzens" und wir werden sehen ob der Aufwand dadurch im Rahmen bleibt.


----------



## nowayback (14. Juli 2016)

Zitat von nightcode:


> Dennoch: in den vielen Jahren, die ich nun im IT-Sektor tätig bin, trat dieses Szenario recht häufig auf!


Hast du Lust vielleicht mal für 2 Stunden mein Mailadmin zu sein? Ich bin auch zu blöd das Passwort richtig einzugeben und lass mir von dir ein neues schicken. Danach sage ich, das das auch nicht geht und dann probierst du dich einzuloggen mit dem ergebnis das ich zu blöd bin das einzugeben. Okay?
Ich leg auch meine Paypal E-Mails in das Postfach. Ich würde sogar einen Passwort vergessen Link anklicken, damit eine aktuelle Mail während deiner Adminzeit ankommt.
Nach 2 Stunden bin ich dann wieder selbst mein Admin. In der Zwischenzeit habe ich aber über VPN ein paar Einkäufe getätigt die ich via Paypal bezahlt habe. Natürlich würde ich Paypal gegenüber nicht zugeben das ich das selbst war. Ich würde sagen mein Konto wurde gehackt. Mein Passwort wurde schließlich geändert. Also muss der Angreifer ja Zugriff auf mein Mailkonto gehabt haben. Das Passwort kannte nur ich, und äh... genau DU!. Jetzt beginnt der Spaß für dich.

Das ist nur einer der Gründe warum so etwas für mich indiskutabel ist.


----------



## nightcode (14. Juli 2016)

Dieses Szenario hat für mich rein garnix mehr mit der ursprünglichen Intention dieses Themas zu tun!

Ich bin gern dein Mailadmin. Bitte hashe deine Passwörter, speicher sie nirgends im Klartext und gib mir dein root Passwort bzw Zertifikat.
Nach 2 Stunden darfst du wieder Mailadmin sein und du wirst sehen: *Es ändert rein garnix daran und dein Spielchen ist genauso möglich!*


----------



## nightcode (14. Juli 2016)

Oder noch besser: der Zugang zur ISPConfig DB reicht auch.
Ich ersetze kurz den Login, mach dein Postfach leer und setze danach den alten gesalzenen Hash wieder ein...

Läuft alles aufs gleiche hinaus. Ist nur eine geringfügige Verschiebung des Problems!

*Ich weiß zwar nicht wie, aber du speicherst das Passwort für ISPConfig und phpMyAdmin etc. doch bestimmt nicht einfach so im Klartext in einer Konfigurationsdatei oder? Kaum auszudenken was da alles passieren könnte *


----------



## nowayback (14. Juli 2016)

Zitat von nightcode:


> Dieses Szenario hat für mich rein garnix mehr mit der ursprünglichen Intention dieses Themas zu tun


Für mich schon. Dieses Beispiel ist nur eines von vielen Möglichkeiten, dein Business zu erden. Und wenn dieses Beispiel genau so abläuft wie ich es beschrieben habe, dann tritt auch genau der Fall so ein. 

Ich will dich nicht angreifen, nimm das bitte nicht persönlich. Ich will dir nur zeigen, dass es Möglichkeiten gibt, die dir Schaden zufügen können obwohl du evtl. gar keine bösen Absichten hattest. Man kann in der heutigen Zeit gar nicht dumm genug denken, um sich auszumalen was alles kommen kann. 

Übrigends würde mich auch mal interessieren was denn deine AGB's, DSE und Co zu dem Thema schreiben. Hast du die von nem Anwalt wirklich mal gegenchecken lassen und halten die einem Verfahren vor Gericht wirklich Stand? Die rechtliche Seite ist hier nämlich auch nicht zu vernachlässigen. 

Das soll es nun übrigends auch von mir zu dem Thema gewesen sein. 

Wir selbst setzen ISPConfig mittlerweile auch ein, allerdings da hauptsächlich die Remote-API weil ISPConfig sich in unsere Umgebung integrieren musste ;-) Das funktioniert auch ausgesprochen gut, war aber Arbeit. Nach 5 Jahren, die ich hier im Forum bin, haben wir es dieses Jahr tatsächlich geschafft, das auf einigen Live-Systemen auszurollen. Nach dem was ich im Git so sehe steht uns mit 3.1 gar nicht so viel Arbeit bevor ;-)


----------



## nightcode (14. Juli 2016)

Wie gesagt: schau dir z.B. einfach mal all-inkl.com an.
Ein sehr großer Hoster, besonders für Kunden die sich nicht mit Servermanagement auseinander setzen wollen.
Und siehe da: man kann sich jedes Passwort von jedem E-Mail, SQL, FTP, Unteraccount und sonstwas anzeigen lassen.
Bei der Gelegenheit kannst du gleich nochmal aus juristischer Sicht deren AGB (ohne S), DSE und Co zerpflücken


----------



## nowayback (14. Juli 2016)

Zitat von nightcode:


> Wie gesagt: schau dir z.B. einfach mal all-inkl.com an.
> Ein sehr großer Hoster, besonders für Kunden die sich nicht mit Servermanagement auseinander setzen wollen.
> Und siehe da: man kann sich jedes Passwort von jedem E-Mail, SQL, FTP, Unteraccount und sonstwas anzeigen lassen.
> Bei der Gelegenheit kannst du gleich nochmal aus juristischer Sicht deren AGB (ohne S), DSE und Co zerpflücken


Nicht mein Job und das war nicht meine Frage. Die Frage war, wie DU das regelst. Und die Frage wollte nicht ich dir stellen, sondern solltest du dir stellen. Schlaf mal ne Woche drüber. Das ist ein richtig heißes Eisen, welches du da anfässt.


----------



## nightcode (14. Juli 2016)

Und deshalb fahre ich, wie bereits mehrfach gesagt, den sicheren Weg.
Und ich werde nur davon abweichen, wenn es eines Tages zu sehr nervt bzw. zu viel Zeit raubt.

Dennoch lassen sich all diese Schreckensszenarien eben auch ohne diese Verfahrensweise realisieren!
Hosting ist immer ein heißes Eisen denn man ist immer ein potenzielles Opfer. 
Mein Kunde hat auch nichts davon wenn ich anderen den Fehler in die Schuhe schiebe. Es könnte genauso gut ein Backdoor in ISPConfig der Auslöser sein. Und wer hats dann überhaupt eingesetzt? Richtig: ICH!


----------



## planet_fox (4. Aug. 2016)

_Backdoor in ISPConfig der Auslöser _<<--- Nach 12 Jahren ISPConfig kann ich sagen sowas ist sehr unwahrscheinlich. ISPConfig wird mit viel Sorgfalt entwickelt. Backdoors kommen wenn nur durch gehackte ISP3 Server ins System oder miss Configuration. 
Zum Passwort Thema, ja es gibt diverse Provider bei denen die Passwörter angezeigt werden. ISPConfig hat das nicht aus nennten Gründen von 
Till. Alles was ich all die Jahre gebraucht habe als Admin von Linux Servern, war die shell und das Logfile System um Probleme zu finden . 
Das andere waren Probleme die beim client selber waren, dazu brauchte ich nur eine Fernwartungssoftware.


----------

