DB-Passwort und Sicherheit
Julia
- php
0 Hans A. Plast0 Texter mit x0 hotti0 dedlfix
Hallo,
ich fülle eine Datenbank per PHP-Skript. Das Passwort für die Datenbank ist dabei (unverschlüsselt) eine normale Variable innerhalb dieses PHP-Skripts. Ist das sicher genug oder gibt es bessere Möglichkeiten? Ich habe schon versucht, die Variable über require in einer Datei außerhalb des httpdocs-Ordners abzulegen, aber da findet das Skript die Datei nicht mehr.
Danke schonmal im voraus für sachdienliche Hinweise :-)
Julia
Hallo,
ich fülle eine Datenbank per PHP-Skript. Das Passwort für die Datenbank ist dabei (unverschlüsselt) eine normale Variable innerhalb dieses PHP-Skripts.
Ist das nicht nahezu immer so?
Und selbst wenn nicht. Der User, der Zugriff zu Deiner PHP-Datei hat, die ein ausserhalb des htdocs liegendes Passwort abgreift, hat auch schon sehr bald Dein Passwort.
Grüße, Hans
Ist das nicht nahezu immer so?
Zumindest große Seiten machen das auch so - so schlimm kann das nicht sein, Passwörter unverschlüsselt im Klartext abzulegen.
Und selbst wenn nicht. Der User, der Zugriff zu Deiner PHP-Datei hat, die ein ausserhalb des htdocs liegendes Passwort abgreift, hat auch schon sehr bald Dein Passwort.
Wenn irgendjemand Zugriff auf Daten außerhalb des www-Wurzelverzeichnisses hat, ist ein unsicheres Admin-Passwort das kleinste Problem.
Es geht bei der Passwortsicherheit schlichtweg darum, dass jemand - sollte er an die Passwortdaten kommen - nicht das Klartextpasswort erhält, welches möglicherweise auch noch anderswo in Verwendung sein könnte. Ungeachtet dieser Tatsache: wer sein Admin-Passwort universell verwendet, ist aber ohnehin nicht zu retten.
Hi!
Es geht bei der Passwortsicherheit schlichtweg darum, dass jemand - sollte er an die Passwortdaten kommen - nicht das Klartextpasswort erhält, ...
Ein automatisiertes DBMS-Login wird sich ohne ein Klartext-Passwort nicht realisieren lassen. Auch wenn es einen andere Mechanismus gäbe, der dazu notwendige Code muss dem Script bekannt sein und ist damit lesbar. Eine kompilierte oder anderweitig verschleierte Form macht nur das Lesen aufwendiger.
... welches möglicherweise auch noch anderswo in Verwendung sein könnte. Ungeachtet dieser Tatsache: wer sein Admin-Passwort universell verwendet, ist aber ohnehin nicht zu retten.
Es lässt sich also nur Aufwanderhöhung (das Passwort zu finden) und Schadensbegrenzung betreiben. Letzteres zum Beispiel indem man eine Kennung auf eine Anwendung beschränkt und nur die wirklich benötigten Rechte vergibt.
Lo!
Ein automatisiertes DBMS-Login wird sich ohne ein Klartext-Passwort nicht realisieren lassen. Auch wenn es einen andere Mechanismus gäbe, der dazu notwendige Code muss dem Script bekannt sein und ist damit lesbar. Eine kompilierte oder anderweitig verschleierte Form macht nur das Lesen aufwendiger.
Das Login für ein DBMS wird dann aber auch noch (hoffentlich) anderweitig geschützt - z.B. Zugriffe auf localhost beschränken. bzw. unterschiedliche Benutzer/Kennwörter für Produktiveinsatz und Administration. Idr. müssen bei den meisten CMS im Produktiveinsatz keine Tabellen erstellt oder gelöscht, Zeichensätze geändert oder Felder ergänzt/entfernt werden.
Letzteres zum Beispiel indem man eine Kennung auf eine Anwendung beschränkt und nur die wirklich benötigten Rechte vergibt.
Siehe oben.
Aber man sieht leider immer wieder bei diversen Hostern entsprechende vorgehensweisen:
FTP, SSH, MySQL, Domainverwaltung - überall dasselbe Passwort.
Wenn irgend eine stelle kompromitiert wird, ist (sofern die Praxis bekannt ist) alles offen wie ein Scheunentor.
Man braucht nur das FTP-Passwort verlieren (und das ist bei dem Protokoll nur wirklich nicht schwierig) und schon hat man seine restlichen Zugangsdaten preisgegeben.
Eine php-Datei könnte angezeigt werden, wenn auf dem Server was schief geht. Eine Datei die außerhalb des erreichbaren Bereichs liegt und eingebunden wird, wäre besser aber wenn das nicht geht, ist eine Datei die vor Zugriffen per htaccess gesperrt ist die Notlösung.
hi,
Danke schonmal im voraus für sachdienliche Hinweise :-)
Der Hinweis von x ist gut. Also ich hab meine Passworte in einer ini-Datei, die liegt zwar innerhalb der DocRoot, könnte aber auch woanders liegen.
Die Erstellung einses DB-Handles in PHP sieht damit so aus:
$db->real_connect($cfg['mysql']['host'], $cfg['mysql']['user'], $cfg['mysql']['pass'], $cfg['mysql']['base']);
wobei $cfg das Array der iniDatei ist, die mit parse_ini_file() vorher eingelesen wird.
Hotti
Hi,
Also ich hab meine Passworte in einer ini-Datei, die liegt zwar innerhalb der DocRoot, könnte aber auch woanders liegen.
Wenn sie innerhalb liegt, dann hast du aber zusätzliche Maßnahmen ergriffen, um sie nicht per HTTP abrufbar zu machen?
MfG ChrisB
Hi,
Also ich hab meine Passworte in einer ini-Datei, die liegt zwar innerhalb der DocRoot, könnte aber auch woanders liegen.
Wenn sie innerhalb liegt, dann hast du aber zusätzliche Maßnahmen ergriffen, um sie nicht per HTTP abrufbar zu machen?
Richtig ;-)
Aber besser ists, die außerhalb der DocRoot zu haben, siehe x.
Hotti
Hi
Wenn sie innerhalb liegt, dann hast du aber zusätzliche Maßnahmen ergriffen, um sie nicht per HTTP abrufbar zu machen?
Richtig ;-)
wie genau hast du das gemacht?
Gruß bolle
Hi
Wenn sie innerhalb liegt, dann hast du aber zusätzliche Maßnahmen ergriffen, um sie nicht per HTTP abrufbar zu machen?
Richtig ;-)
wie genau hast du das gemacht?
Auf Dateien, die mit ".ht" beginnen verweigert der Apache den HTTP-Request.
Hotti
Hi,
wie genau hast du das gemacht?
Auf Dateien, die mit ".ht" beginnen verweigert der Apache den HTTP-Request.
ah, keine schlechte Idee. Deine ini-Datei heisst dann wohl in etwa .htini
? :)
hi,
ah, keine schlechte Idee. Deine ini-Datei heisst dann wohl in etwa .htini
? :)
Ne, die hei?t .htRumpelstilz.ini Aber sags bitte nicht weiter :D
Hotti
Hi!
Wenn sie innerhalb liegt, dann hast du aber zusätzliche Maßnahmen ergriffen, um sie nicht per HTTP abrufbar zu machen?
Auf Dateien, die mit ".ht" beginnen verweigert der Apache den HTTP-Request.
Das ist kein Gesetz sondern nur eine Default-Konfiguration in der Hauptkonfigurationsdatei des Apachen, die der Provider auch aus Versehen oder absichtlich wegnehmen kann oder man selbst als Anwender überschreiben kann.
Gegen Lesezugriffe auf Dateien selbst ist es besser und oft einfacher zu realisieren als man denkt, sie in nicht erreichbare Verzeichnisse zu verlegen. Wenn allerdings ein erreichbares Script manipuliert oder (beispielsweise ein Download-Script) unvorhergesehen aufgerufen werden kann, so dass es die inkludierten Daten ausgibt, hilft das natürlich auch nichts.
Lo!
hi,
Gegen Lesezugriffe auf Dateien selbst ist es besser und oft einfacher zu realisieren als man denkt, sie in nicht erreichbare Verzeichnisse zu verlegen.
Sag ich doch die ganze Zeit. Schreibt Texter mit x auch, hast Dus gelesen?
Hotti
Hi!
Gegen Lesezugriffe auf Dateien selbst ist es besser und oft einfacher zu realisieren als man denkt, sie in nicht erreichbare Verzeichnisse zu verlegen.
Sag ich doch die ganze Zeit. Schreibt Texter mit x auch, hast Dus gelesen?
Ja, doch, aber das "reicht ja auch ein <del>Stopp</del><ins>Verbots</ins>schild aufzustellen" wollte ich nicht so locker da stehen lassen.
Lo!
Also ich hab meine Passworte in einer ini-Datei
.ini? Warum wählst du eine Datei, deren Inhalt unter normalen Umständen ausgegeben wird?
Hi!
Ich habe schon versucht, die Variable über require in einer Datei außerhalb des httpdocs-Ordners abzulegen, aber da findet das Skript die Datei nicht mehr.
Danke schonmal im voraus für sachdienliche Hinweise :-)
Um das Nicht-Funktionieren zu kommentieren, benötigt man zunächst einmal sachdienliche Hinweise von dir, wie du das angestellt hast und was das genaue Resultat war, inklusive Fehlermeldungen.
Lo!
Ich habe schon versucht, die Variable über require in einer Datei außerhalb des httpdocs-Ordners abzulegen, aber da findet das Skript die Datei nicht mehr.
Man kann mit require Dateien ablegen? 8-|
Was hast du gemacht und wie lauten die Fehlermeldungen?