Richtiger Umgang mit Passwörtern

Lesetipps

1. Sicherer Umgang mit der Request Variablen
2. Psychologisch richtiger Einsatz des PHPCodeSniffers

Heute will ich mal ein paar Worte über den Umgang mit Passwörtern, die man in PHP verwendet verlieren. Ich denke jeder von euch hatte bereits ein Projekt, in dem mit eben solchen hantiert wurde. Login und noch häufiger Datenbank Passwort seien hier genannt. Ich werde meinen Artikel am Beispiel von Datenbank Passwörter aufhängen, gilt aber natürlich auch für alle anderen.

In den meisten Datenbank Klassen habe ich einen Konstruktor, der Passwort, Datenbank, User und Tabelle als Parameter mitbekommt. Diese werden dann in einer privaten Membervariablen hinterlegt und die Verbindung zum DB Server aufgebaut. Auf diese, meistens als Singleton gehaltene Klasse, können jetzt alle Module, Plugins und Kernkomponenten eines Projektes zugreifen. Klingt bis jetzt ja sehr angenehm und komfortabel. Aber macht doch mal einen var_dump auf eure Datenbank Klasse. In den meisten Fällen, wird dort das Passwort mit ausgegeben. Ist das denn nötig? Nein, denn nachdem die Verbindung zum Datenbank Server aufgebaut wurde, ist sie persistent, bis das Skript vollständig durchlaufen. Ich sollte also, sobald die Verbindung steht, das Passwort löschen um mögliche Angriffe zu umgehen.

Ihr erschwert es einem Angreifer auf diese Weise zumindest an die Passwörter zu kommen, falls ihr eine Schwachstelle im System habt. Auch so etwas wie ein var_dump auf ein Model, dass ja häufig einen Verweis auf die DB Klasse hält, würde das Passwort nicht auf den Schirm bringen. Besonders bei der Integration von Third Party Modulen, kann man ja nie wirklich sicher sein, was diese machen. Oder schaut ihr euch den Code von den Plugins an, die ihr installiert.

2 Kommentare »

• 
  

  robo47

  am 20. Dezember 2008 um 19:56 Uhr

  Hmm,
  ich denke wenn jemand es schafft dir irgendwo ein var_dump() einzuschleusen, dann ist eh bereits alles zu spät, weil dann kann er mit einer sehr hohen Wahrscheinlichkeit auch anderen Code ausführen.

  Ausserdem setzt der weg über var_dump() vorraus, dass die eingesetzte Applikation irgendwoher dein “Design” kennt, weil sonst weis man ja nicht was man dumpen soll. Wenn eh der komplette Code des Systems bekannt ist, kann man auch direkt das Array/Objekt der Config ausgeben lassen oder direkt die Config-Datei.

  Auch wenn es vielleicht eher nicht alltäglich ist, aber was es auch beispielsweise verhindert ist, dass das Datenbank-Objekt an irgendeiner Stelle serialisiert wird um in einem anderen Scriptaufruf entserialisiert zu werden und wieder eine Verbindung aufzubauen … warum auch immer man das tun will

• 
  

  unset

  am 20. Dezember 2008 um 20:02 Uhr

  Man muss ja nicht unbedingt ein var_dump einschleusen, man muss evtl. nur sagen, was geanuer unter die Lupe genommen werden soll. Ich denke da an unsaubere “toJSON”-methoden o.Ä.

  Das Argument “wenn Fall X eintritt, hat man größere Probleme als Fall Y” habe ich früher auch immer wieder angewandt. Das blöde ist nur, wenn die großen Probleme weg sind, hat man dann immer noch die kleinen, die man vorher als so unwichtig erachtet hat. Insofern sollte man da vorsichtig sein

  Im großen und ganzen Stimme ich euch beiden zu. Sinnloses speichern ist aus mehreren Sichten quatsch. Auf der anderen Seite gibt es aber auch Stellen, die vorher abgeschert werden sollten. Datenbankzugriff limitieren, IP-Bereiche whitelisten, etc.

RSS-Feed für Kommentare zu diesem Artikel. TrackBack-URL

Einen Kommentar hinterlassen