HOSTBLOGGER.de

Das ist kein fairer Kompromiss, das ist IMHO die einzig richtige Möglichkeit.
"Dass wir dein Passwort im Klartext speichern ist alternativlos" ist ein Unding.

Mich würde interessieren, warum ihr es überhaupt gespeichert habt? Und natürlich, ob es auch die Option gibt, zukünftige Datenbanken ohne PW-Speicherung anlegen zu lassen ...

Nicht ganz.
1. Nur when des 1-click-Mechanismus? Find ich ja dann krass.
2. Wird irgendwie nicht durch den Post beantwortet.

Du kannst eine neue Datenbank nicht ohne Passwort anlegen, so wie es aussieht – zumindest bisher nicht. Du kannst es aber direkt nach dem Anlegen löschen. Natürlich wäre es angenehmer, wenn man direkt beim Erstellen eine 1-Klick-unfähige Datenbank (ohne Speicherung) erstellen könnte, aber das würde wieder Programmieraufwand bedeuten – und mal unter uns: Man kann's auch übertreiben.

*für

Das Passwort wird doch dann sowieso als Klartext in der Config des entsprechenden PHP Scripts gespeichert - sprich: Ja es wird irgendwo gespeichert. Als Klartext. So wie Manuel es auch oben geschrieben hat in seinem Beitrag. Also hast du es nicht vorher gelesen O_o

Ehrlich?
Es geht doch gar nicht darum, dass das Passwort im Klartext in irgendeiner Konfigurationsdatei steht. Das ist mir klar - wie wohl den meisten hier.

Es geht darum, dass das Passwort _zusätzlich_ (in diesem Fall in einer Datenbank) wie-auch-immer-kodiert steht. Darum geht es. Und dass der Kunde bisher darauf keinen Einfluß nehmen konnte.

Und dass ich genau diese Dinge nicht nachvollziehen konnte. Weder, warum es in der Datenbank stehen mußte (wohl wegen des 1-Click-Mechanismus, den ich nur anders kannte) noch warum der Kunde darauf keinen Einfluß nehmen konnte.

Und zusätzlich noch wissen wollte, ob es jetzt auch präventiv möglich ist, dass keines angelegt wird beim Einrichten einer neuen DB.

Echt jetzt - nicht gelesen scheint ja der neue Trollsatz zu werden, wenn ich das mal so überspitzen darf
Klar hab ich das alles gelesen.

Achtung: Du hast als Kunde keinen Einfluss darauf, dass der Hoster zur Not auch ohne dein Passwort Zugriff auf deine Datenbank hat.

Man kann es echt übertreiben ey

Du kannst deine Passwörter übrigens aus dieser internen DB löschen lassen.

Warum spielt es so eine Rolle, ob der Hoster für seine Services das Passwort nochmal irgendwo gut abgesichert speichert? Fürchtest du dich vor dem Hoster? Dann brauchst du ne eigene Maschine ^^

Um mal etwas Druck rauszunehmen ...

Es gibt mehrere Gründe, warum wir die Zugangsdaten bisher immer gespeichert haben:

1. (wie geschrieben) für den 1-Klick-Installer

Praktisch 100% aller unerfahrenen Kunden erwarten, dass Sie sich das Datenbank-Passwort nicht nochmal woher "zuppeln" müssen (sprich selbst irgendwo merken müssen). Sie erwarten, dass ein WordPress mit 1 Klick installiert ist, ohne großes Tam-Tam.

2. Das Datenbank-Passwort muss auch ohne Neu-Setzen verfügbar sein

Viele Kunden erwarten, dass sie das Passwort bei UNS einsehen können, ohne es Neu-Setzen zu müssen - z.B. für eine manuelle Installation einer Anwendung. Sie suchen für die Konfiguration ihrer Anwendung nach den Zugangsdaten, und wenn sie diese nicht direkt finden, fragen sie den Support. Wäre das Passwort nicht mehr vorhanden und müsste neu gesetzt werden, wären ggf. andere Anwendungen in derselben Datenbank betroffen.

Dass es mehrere Datenbanken und die Möglichkeit einer Trennung gibt, leuchtet nicht jedem ein, und hier wäre es eine Abstrafung unerfahrener Kunden. Mal abgesehen vom Verlust von Vertrauen von Kunden, die es gerne "einfach haben".

3. Kein zusätzliches Sicherheitsrisiko

Die Zugangsdaten müssen (mal abgesehen von seltenen, proprietären Lösungen) immer im Klartext vorliegen, damit PHP/Python/Perl/...-Anwendungen auf die Datenbank zugreifen können. Im Webspace ist das Passwort - sorry - praktisch am unsichersten. Dort, wo wir es speichern, ist es sicherer als sonstwo

Nun zu Deiner Frage bzgl. "zukünftig ohne speichern". Aufgrund des Prozesses, wie es derzeit gehandelt wird, geht das noch nicht, wird aber in einigen Monaten kommen. Derzeit sind die Prozesse "anlegen" und "Kunde informieren" getrennt, und müssen es aus technischen Gründen erst einmal auch so bleiben. Das werden wir ändern, sobald sich die Gelegenheit aufgrund geänderter interner Strukturen ergibt.

zu "3. Kein zusätzliches Sicherheitsrisiko"

das stimmt so nicht (mathematisch jedenfalls. Das zusätzliche Risiko mag vernachlässigbar sein, Null ist es nie.

ganz so arg gering ist es m.E. ohnehin nicht, denn immerhin muss es automatisch ausgelesen werden können für 1-Klick -- und es ist dem Kunden anzeigbar. Das heißt es gibt eine automatisierte Schnittstelle, die das Passwort abgreifen kann. Es liegt also nicht nur verschlüsselt auf einem USB-Stick im Tresor für den "Fall der Fälle" sondern ist Dauer-Online. Natürlich nicht auf demselben Server wie die Kundendatenbank, aber immerhin.
Im Falle einer Sicherheitslücke könnte also ein Angreifer gleich alle Passwörter auf einmal abgreifen. Das macht es ein potentiell lohnendes Ziel. Ebenso könnte jemand potentiell die DB "am Stück" klauen und entschlüsseln (wenn alles mit demselben Schlüssel verschlüsselt st, wenn es dagegen z.B. den hash des Kundenkennworts braucht...)

Schön wäre, wenn dem Kunden dies mitgeteilt werden würde bei der Einrichtung und er dort entscheiden könnte. Gerne mit dem Hinweis auf "liegt ohnehin prinzipbedingt unverschlüsselt auf 'deinem' Server". Passwort-Recovery durch den Support (das scheint ja eine Befürchtung zu sein) darf dann auch was kosten.

"Viele Kunden erwarten, dass sie das Passwort bei UNS einsehen können, ohne es Neu-Setzen zu müssen" klingt für mich ganz stark nach "der Kunde kann es online abfragen". Oder muss er etwa persönlich vorbeikommen und kann es dann aus dem bankschließfach abholen?

Deshslb ja verschlüsselt. ..

Und: Ein Mitarbeiter mit Berechtigung zum Datenbank -Server kann wh alle Daten lesen. Das geht auch ohne Passwort!

Und: Du kannst bei mysql dein Passwort ändern, dann kennt es Manitu auch nicht mehr.