Heute mal eine kurze Abhandlung über ein Thema, das öffentlich nicht breitgeschlagen wird, und dennoch eigentlich jeden betrifft: Speicherung von Passwörtern.
Im Zeitalter der sozialen Netze, der Mitmachcommunities, Web2.0 und Konsorten. Bei jeder Anwendung brauch man einen Login mit Nutzername und Passwort. Doch niemand kann hinter die Fassade blicken, wie mit den personenbezogenen Daten umgegangen wird, wird ja aktuell heiß diskutiert. Weiterverkauf von Adressen, Namen und Telefonnummern sind ständig in den Schlagzeilen. Doch viel kritischer ist eigentlich der Umgang mit den Passwörtern.
Im schlimmsten Fall wird das Passwort im Klartext in einer Datenbank oder anderen Persistenzen gespeichert. Dabei hat der Administrator Zugang zu dem Passwort und kann, sofern er die zugehörige Email Adresse hat, z.b. in das Mail Postfach eindringen. Klar würde hier der rat helfen, für jede Anwendung ein neues Passwort zu nutzen, aber wahrscheinlich machen das die wenigsten Anwender.
Ein wenig besser ist die Verschlüsselung des Passwortes, dabei wird das Passwort mit einem festen Algorithmuss verschlüsselt gespeichert. Man spricht hierbei von einem gehashten Passwort. Problem ist allerdings, das solche Passwörter Dictonary Attacken offen gegenüber steht. Dabei wird eine Liste von Wörtern mit der selben Methode wie das Passwort verschlüsselt und mit dem gespeicherten Wert verglichen, sind beide Werte gleich, ist das Passwort geknackt.
Desweitern kann z.B. ein Admin in einer Seite sehen, wieviele User als Passwort Gott, Party oder Sex haben, indem er einen User anlegt, das Passwort vergibt und dann in der DB nach eben diesem erzeugten Wert sucht.
Die sicherste Möglichkeit wird in Unix Systemen seit Jahren eingesetzt: sogenannte gezalzene, salted, Passwörter.
Hintergrund ist die Schwachstelle, das die Passwörter im hashed Verfahren immer gleich verschlüsselt werden, durch einen dynamischen Anteil zu verwässern.
Um das Passwort zu entschlüssen bedarf es dadurch eine weitere Komponente: den Zusatz, das Salz. Dies kann entweder ein freier Wert, der zufällig generiert wird sein, aber auch der Benutzername, um den Speicheraufwand zu senken. Um das Passwort rauszubekommen, muss ein Angreifer jetzt alle Wörter mit dem Salt verschlüsseln, was den Aufwand ins unermessliche steigen lässt, da jedes Wort mit jedem möglichen Salt kombiniert werden müsste.
Funktional muss man dadurch aber auf ein „Passwort senden“ verzichten, denn wie auch dem Angreifer ist es dem System nicht möglich, das Passwort herzustellen.
Alles in allem aber eine Sache, die ein Nachwuchsadministrator beachten sollte, um nicht irgendwann negative Schlagzeilen zu machen, denn in diesem Zusammenhang ist nicht jede Meldung eine gute Meldung, den Ruf, unsicher mit Daten umzugehen, wird man schwer wieder los.
Bildquelle:
http://de.wikipedia.org/wiki/Bild:Salzstreuer.jpg Fotograf: Ketchupfreak88
Pingback: WordPress manuell mit Hausmitteln gegen Angriffe absichern › Web Development Blog
Funktioniert das auch mit .htaccess Files?
Denke nicht das viele Benutzer Passwörter wie „Gott, Party oder Sex“ haben. Wer macht den so was.
Hi Christina,
danke für deinen Kommentar, das einzige was ich dazu finden konnte ist: https://stackoverflow.com/questions/4175707/adding-a-salt-to-htpasswd
Vllt hilft das ja
Alex