MySQL-Passwort im Klartext
Marc Reichelt
- datenbank
0 André Laugks0 Ludger0 Elderan0 Dennis
Hallo an alle,
ich versuche mich in letzter Zeit ein wenig an MySQL und PHP im Duett, und nun bin ich an einer Sache hängen geblieben die mir keine Ruhe lässt - das MySQL-Passwort steht jedes Mal im Klartext in einer Datei.
Bei meinem Hoster (all-inkl.com) habe ich keinen Zugriff auf Verzeichnisse außerhalb des Document Root - das soll sich in den nächsten Monaten AFAIK ändern.
Bis dahin behelfe ich mir mit folgenden Methoden, um das Passwort zu schützen:
1. Die MySQL-Daten stehen in einer einzigen Datei, die bei direktem Zugriff nichts zeigt.
2. Diese Datei wird immer nur von den entsprechenden PHP-Dateien includet.
3. Die Datei mit den Daten steht in einem Verzeichnis, auf das via .htaccess-Datei kein Zugriff möglich ist.
Aber trotz all diesen Punkten steht das MySQL-Passwort immer noch als Klartext in der Datei - das möchte ich einfach nicht belassen. Kann man das Passwort auf irgendeine Methode verschlüsselt an MySQL übergeben? Mir ist klar dass wenn die Methode nicht im MySQL selbst drin steckt die Entschlüsselungsmethode direkt im Quelltext steht - das ist auch keine Lösung.
Wie mache ich das also am Besten?
Bis dann!
Marc Reichelt || http://www.marcreichelt.de/
Hallo!
- Die MySQL-Daten stehen in einer einzigen Datei, die bei direktem Zugriff nichts zeigt.
Eine Include-Datei sollte auch mit einer Endung versehen werden, die der Server als PHP-Dateien parst. So wird die Include-Datei, wenn sie separat aufgerufen wird, auch geparst. Die Dateiendung inc ist oft nicht als PHP-Datei konfiguriert.
Also das hast Du gemacht.
- Diese Datei wird immer nur von den entsprechenden PHP-Dateien includet.
Naja, wenn Du sie überflüssigerweise in andere Dateien einbindest, ist das kein Sicherheitsrisiko.
- Die Datei mit den Daten steht in einem Verzeichnis, auf das via .htaccess-Datei kein Zugriff möglich ist.
Perfekt!
Mehr kannst Du nicht tun. Also mache Dir kein Stress.
Den einzige Fehler ist, den Du noch machen kannst, die FTP-Zugangsdaten einem Fremden zu geben.
André Laugks
Hallo André,
- Die MySQL-Daten stehen in einer einzigen Datei, die bei direktem Zugriff nichts zeigt.
Eine Include-Datei sollte auch mit einer Endung versehen werden, die der Server als PHP-Dateien parst. So wird die Include-Datei, wenn sie separat aufgerufen wird, auch geparst. Die Dateiendung inc ist oft nicht als PHP-Datei konfiguriert.
Also das hast Du gemacht.
Die Datei heißt "mysql.inc.php"... ;-)
[...]
Mehr kannst Du nicht tun. Also mache Dir kein Stress.
Wirklich nicht? Auch nicht wenn ich z.B. das Passwort mit md5() oder so verschlüssele, bzw. auf die Art wie MySQL es gespeichert hat?
Den einzige Fehler ist, den Du noch machen kannst, die FTP-Zugangsdaten einem Fremden zu geben.
Das ist mir schon klar, aber davon gehe ich nicht aus. :-)
Bis dann!
Marc Reichelt || http://www.marcreichelt.de/
Hallo!
Wirklich nicht?
Nein, mache Dir keinen Stress!
Ich kümmere mich um Webseiten, die ziemlich in der Öffentlichkeit stehen. Dort lege ich die "Datenbank-Benutzerdaten" so ab wie Du.
Ich habe das von mir aus technisch Möglichste getan.
Sollte der Provider Mist bauen, PHP-Dateien werden nicht geparst oder .htacces wird ignoriert, und somit Fremde an die Benutzerdaten kommen, hat der Provider ein großes Problem.
André Laugks
Hallo André,
Wirklich nicht?
Nein, mache Dir keinen Stress!
Und es geht doch! Einfach das Klartext-Passwort nehmen, mit der MySQL-Funktion password() verschlüsseln und so zum Server connecten. Ein solches Passwort ist vor einer Brute-Force-Attacke natürlich nicht sicher, aber immerhin steht es nicht mehr als Klartext in der Datei. Super, echt zu empfehlen!
Ach ja, hier kann man das Passwort entsprechend verschlüsseln lassen:
http://www.php.breitenbuecher.de/kunden/dmt/tools/passwort.php
Bis dann!
Marc Reichelt || http://www.marcreichelt.de/
Hi,
Und es geht doch! Einfach das Klartext-Passwort nehmen, mit der MySQL-Funktion password() verschlüsseln und so zum Server connecten. Ein solches Passwort ist vor einer Brute-Force-Attacke natürlich nicht sicher, aber immerhin steht es nicht mehr als Klartext in der Datei. Super, echt zu empfehlen!
ist es ein symetrisches oder asymetrisches Verschluesselungsverfahren? ;-)
Gruss,
Ludger
Moin!
Und es geht doch! Einfach das Klartext-Passwort nehmen, mit der MySQL-Funktion password() verschlüsseln und so zum Server connecten. Ein solches Passwort ist vor einer Brute-Force-Attacke natürlich nicht sicher, aber immerhin steht es nicht mehr als Klartext in der Datei. Super, echt zu empfehlen!
Damit ist dir doch in keiner Weise geholfen!
Statt des Originalpasswortes (das du hoffentlich "gut" gewählt hast, also beispielsweise "018i19KTf8uo") steht jetzt das "verschlüsselte" Passwort als Klartext in deiner Datei.
Und ein böser Angreifer, der diesen Klartext lesen kann, kann diesen String nehmen und bei mysql_connect einsetzen, um sich zu deiner Datenbank zu verbinden - genauso, wie du es auch kannst.
Natürlich kann man das Originalpasswort nicht mehr ermitteln - aber solange das verschlüsselte Passwort genauso gut funktioniert, ist das auch vollkommen egal.
Hallo Sven,
Und ein böser Angreifer, der diesen Klartext lesen kann, kann diesen String nehmen und bei mysql_connect einsetzen, um sich zu deiner Datenbank zu verbinden - genauso, wie du es auch kannst.
Natürlich kann man das Originalpasswort nicht mehr ermitteln - aber solange das verschlüsselte Passwort genauso gut funktioniert, ist das auch vollkommen egal.
Das ist immerhin schon mal ein kleiner Erfolg. Da das MySQL-Passwort gleichzeitig auch das FTP-Passwort bei all-inkl.com ist, kann jeder der das MySQL-Passwort hat auch meine Dateien ändern - also nicht nur die Datenbank.
Bestimmt ändert all-inkl.com das bald (auch dass man das MySQL-Passwort seperat ändern kann), ich werde auf jeden Fall dort den Support anrufen und dies für das neue KAS vorschlagen.
Derzeit ist dies bestimmt die maximale Sicherheit die ich erreichen kann.
Bis dann!
Marc Reichelt || http://www.marcreichelt.de/
Und 99,99% aller Datenbanken bei den Providern, sind nur über das Netzwerk des Providers zu erreichen. Es besteht also nur Zugriff von den Servern des Providers aus.
Das bedeutet, auf Deiner Datenbank kann sich nur jemand einloggen, der Kunde bei deinem Provider ist.
Dein Provider muss dafür sorgen, dass keiner in den Webspace des anderen schauen kann, um eventuell Benutzernamen und Passwörter auszuspähen.
Um sich bei einem Angriff zu schützen, sind regelmäßige Backups nötig.
André Laugks
Hi,
Aber trotz all diesen Punkten steht das MySQL-Passwort immer noch als Klartext in der Datei - das möchte ich einfach nicht belassen.
ja, sowas wurde bei uns auch schon mal diskutiert. (Als ob man nichts Besseres zu tun hat.)
Andre hat natuerlich recht. Bedenke: Dein Script, das bspw. im Kontext eines anonymen Internetnutzers ausgefuehrt wird, muss ja den Sicherheitskontext wechseln um an das RDBMS ranzukommen. Und da beruhigen Verschluesselungen und so zwar immer das Gewissen, sind aber letztlich sinnlos.
Gruss,
Ludger
Tach,
wie schon erwähnt wurde, kann der DB Server zu 99.99% nur per Netzwerk erreicht werden, meistens ist der DB-Server der gleiche Rechner wieder der Webserver (localhost), so das keine Daten über ein Kabel laufen.
Dennoch kann man mit mysqli_connect(); (mysqli) eine Verbindung per SSL mit dem DB Server aufbauen.
Das Passwort in der PHP Datei per md5 oder ähnlichem zu verschlüssel wäre totaler Schwachsinn.
Denn wenn ein Angreifer die PHP Datei auslesen kann, dann hat er zwar nicht das PW im Klartext, aber mit dem PasswortHash könnte er dennoch eine Verbindung zu dem Server aufbauen.
Und wenn du für die MySQL Datenbank ein Passwort verwendest, welches du bei keinem anderem Dienst benutzt, dann ist es egal ob der den Passworthash oder das Klartextpasswort erhält.
Einloggen kann er sich in beiden Fällen, aber weil du es niergendwo anders benutzt, bringt es ihn auch nicht viel weiter.
Was noch wichtig ist, außer das nicht jmd. anderes FTP Zugang erhält, das der Server unter Safe mode (phpinfo.php) läuft, so kann ein anderer Benutzer nicht mehr auf deine Daten zugreifen.
Wie man die Datei auch noch schützen kann, ist: CHMOD 400.
Somit bekommt nur der Benutzer wwwrun (sofern Unix/Linux) die Leserechte auf die Datei, wenn jmd. Shell Zugriff auf den Server hat, und _nicht_ als wwwrun angemeldet ist, dann kann er diese Datei nicht mehr lesen/zugriff verweigert.
Allerdings muss die Datei auch von wwwrun erstellt werden. Darum musst du einen Script schreiben, der dir die Datei erstellt.
Dann Script löschen und die Lese/Schreibrechte ändern.
Schreibrechte sollte man auf der Datei auch nicht gewähren, denn wenn jmd. beliebige Dateien bearbeiten kann, dann entfernt er z.B. <?php am Anfang und sieht den Dateiinhalt.
Elderan
Hi Marc,
Bei meinem Hoster (all-inkl.com) habe ich keinen Zugriff auf Verzeichnisse außerhalb des Document Root - das soll sich in den nächsten Monaten AFAIK ändern.
Ich hatte mich deswegen schon mal bei allinkl.com bzgl. der neuen Version von KAS erkundig und dies auch hier erwähnt - gibts aber leider i.M. einen 500er, wenn ich das versuche aufzurufen....
Jedenfalls wird es in Zukunft (so wie ich es verstanden habe) ähnlich wie bei 1und1 laufen, also dass man (Sub-) Domains in beliebige Unterordner routen lassen kann. Wenn du allerdings jetzt schon Zugriff auf Ordner außerhalb des Doc-Roots benötigst, so rufe doch mal bei denen an, dann können die dir die Domain auch manuell in einen Unterordner routen. Btw: Das neue KAS ist z.Z. testweise bei einzelnen Kunden eingesetzt - bis zur Veröffentlichen wird es aber noch etwas dauern.
MfG, Dennis.