Zugangsdaten schützen

[Steglich]

Zugangsdaten

Es ist sicherlich sehr praktisch, die Zugangsdaten zu einer SQL Datenbank in Vriablen einer php Datei auszulagern, die man dann wieder per require() einbindet. So kann man Änderungen an Benutzer und oder Passwort sehr zentral vornehmen.
Wie schütze ich aber diese Datei auf dem Server vor unbefugtem Zugriff?

 

[Delmar]

Wieso willst Du die extra schützen? Es weiß doch keiner wie die Datei
heißt und wo sie auf dem Server liegt. Und wenn jemand den Server
gekanckt hat, wird ein Verzeichnis- oder Dateischutz auch nicht viel
bringen.


In diesem Sinne ...

 

[Steglich]

Namensgebung

... dann brauche ich mir also nur einen hinreichend komplizierten Namen für die Datei ausdenken, den keiner so schnell errät und der Käse ist gegessen. Das ist ja einfach. Vielen Dank.

 

[maceis]

hallo zusammen,

das Konzept "Schutz durch Unauffälligkeit" ist zwar schon was, man kann es aber noch weiter treiben.

Man kann die Zugangsdaten (oder gleich die gesamten connect- und select_db-Befehle) in eine Datei mit beliebigem Namen und Suffix schreiben und diese mit require() oder auch include() einbinden.
Ich hab dazu immer dazu die Endung *.mid genommen, da die meisten Browser versuchen, eine solche Datei abzuspielen .
Nachteil: Mit "telnet" oder "curl" kommt man immer noch an den Inhalt der Datei, wenn man den Namen hat (oder errät bzw. mit einem Skript lange genug rumprobiert)

Wenn man es noch sicherer will (und ich will das inzwischen ), legt man die Datei in ein Unterverzeichnis, das man mit .htaccess schützt.
Für das "includieren" benötigt man das Passwort nicht; wenn man aber auf das Verzeichnis (oder dessen Inhalt) direkt zugreifen möchte, benötigt man das Passwort und den Benutzernamen.
Diese Daten kann man sogar außerhalb der DokumentRoot ablegen und das Passwort wird verschlüsselt gespeichert.

Nachdem der Aufwand dafür lächelich gering ist, nehm´ich das "mehr" an Sicherheit gerne mit.
Muss aber jeder - wie immer - für sich selbst entscheiden.

Delmar hat insofern Recht, dass ein Angreifer, der den root-Zugriff auf den Server erobert hat, damit auch nicht zu stoppen ist
Nur: Dahin ist der Weg um Einiges weiter, als wenn die betreffende Datei im direkten Zugriff über den Internet-Browser liegt.