Passwörter in einer SQL Datenbank speichern

[Ynnus]

Das ganze "ich verschlüssele die Daten, liefere aber alles zum Entschlüsseln Benötigte mit"-System ist der Grund, warum frühe DRM-Systeme schnell umgangen waren.

...

Wo liefere ich denn bitte alles zum Entschlüsseln mit? Es ist gängige Praxis, dass der Verschlüsselungsalgorithmus offengelegt ist (z.B. durch Ausschreibungen wird der beste Algorithmus gesucht, sehr verbreitete Algorithmen wie RSA (ein bekanntes asymetrisches Public-Key Verfahren) sind sehr sehr sicher und dennoch öffentlich bekannt). Das Geheimhalten des Schlüssels reicht bei diesen Algorithmen aus, um die Sicherheit zu gewehrleisten. Denn ein Algorithmus kann durch Analyse des Codes und Disassembling herausgefunden werden. Ein offengelegter Algorithmus, bei dem man durch den Algorithmus und den verschlüsselten Wert nicht (bzw nur mit Jahren Rechenaufwand) auf den Schlüssel rückschließen kann, ist deutlich sicherer.
Soviel dazu.
Ob das nun oversized ist für dieses Projekt oder nicht muss jeder selbst wissen. Sicher gibt es andere Methoden der Realisierung, diese ist mir halt gestern so in den Sinn gekommen.

[Jesus_666]

Wo liefere ich denn bitte alles zum Entschlüsseln mit? Es ist gängige Praxis, dass der Verschlüsselungsalgorithmus offengelegt ist[...]

...

Ich spreche nicht vom Algorithmus. So wie du dein System beschrieben hast interpretiere ich es wie folgt:

- Die Passwörter liegen verschlüsselt lokal vor.
- Der Schlüssel liegt ebenfalls lokal vor oder werden vom Anwender eingegeben.
- Um ein Passwort zu benutzen, wird es entschlüsselt. In diesem Moment liegt es unverschlüsselt im Speicher.

Wenn jemand lokalen Zugriff hat, bieten sich zwei Angriffsflächen: Er kann sich Schlüssel und Passwörter schnappen und hat damit die Passworter im Klartext. Oder er findet heraus, wo im Speicher du das Klartext-Passwort ablegst und liest es direkt aus.
Selbst, wenn der Schlüssel selbst nicht einfach so gespeichert ist, mußt du ihn auch irgendwann im Speicher haben und dort kann er dann ausgelesen werden. Ein Angriff auf AACS funktionierte so; der Speicher des Abspielprogramms wurde nach den Title Keys durchsucht.

Letztenendes ist die Sicherheit gegenüber einer lokalen Speicherung im Klartext nur insofern größer, daß der Angreifer den Schlüssel extrahieren muß. Da jemand mit nennenswertem Lokalzugriff sich einfach sämtliche Dateien kopieren kann und dann effektiv unendlich viel Zeit (und Prozessorzyklen) für den Angriff hat, ist dieser Schutz nicht wirklich relevant. Zumal es nicht gerade einfach ist, Schlüssel und Klartextdaten so im Speicher zu verstecken, daß ein Angreifer sie nicht schnell finden kann.


Effektiver Schutz muß (so weit wie möglich) gewährleisten, daß alle involvierten Rechner vor Angriffen geschützt und die Verbindungen zwischen ihnen verschlüsselt werden. Sobald der Angreifer signifikanten Zugriff auf den lokalen Rechner hat, ist davon auszugehen, daß er jede weitere Sicherheitsvorkehrung umgehen kann, da er alles kann, was der Rechner kann – und der Rechner soll ja gerade auf die Passwörter zugreifen können.

Ein paar elementare Weisheiten der Sicherheit:
- Das Internet ist böse; jede unverschlüsselte Verbindung muß bei der Planung der Sicherheitsvorkehrungen als automatisch kompromittiert angesehen werden. (Korrolar: Sensible Daten dürfen unter keinen Umständen unverschlüsselt übertragen werden.)
- Wer lokalen Zugriff hat, der kann alles tun, was sein Account tun kann. (Wenn also deine Webanwendung kompromittiert wird, dann wird alles kompromittiert, auf das die Webanwendung Zugriff hat; hier also die Passwörter.)

[dead_orc]

Um nochmal was zu Whiz ursprünglicher Frage zu sagen (wieso ist das eigentlich auf einmal zu ner Sicherheits-Diskussion explodiert?):

Ich würde die Speichermethode der Serverdaten davon abhängig machen, wie die Anwendung später benutzt wird. Wenn die Server für immer und ewig (oder wenigstens ne lange Zeit [einige Jahre]) die selben bleiben (bzw. deren IPs/deren DNS-Adressen), würde ich sie in einer Config-PHP-Datei in ein Array klatschen. Wenn es durchaus mal vorkommen kann, dass n Server dazu kommt, einer wegfällt und dergleichen würde ich sie versuchen, in ne DB zu lagern. Dafür dann aber NOCH eine MySQL DB zu nehmen, halte ich für unschlau. Vielleicht wäre da sqlite o.Ä. angebracht. Vielleicht sogar einfach nur ne CSV-Datei, aber halt was, was du maschinell lesen und schreiben kannst, damit du auch ein nettes Webinterface zum Ändern der SQL-Server bereitstellen kannst.

@Jeez: thx fürs Backup

[NeoInferno]

Speichere niemals Passwörter (verschlüsselt oder nicht) direkt in einer DB!
Wenn jemand irgendwie doch an den Schlüssel kommt, hast du verloren.
Wenn jemand auch ohne Schlüssel an deine DB kommt, ist es nur eine Frage der Zeit bis der Schlüssel rekonstruiert ist und die Passwörter im Klartext rausziehbar sind.

Speichere stattdessen nur den *Hash* eines Passwords, idealerweise mit einem geheimen sog. Salt Wert, etwa:

Salt = "lf34ha";
pw = Hash(Salt + UnhashedPw);
Store(pw);

Selbst wenn dann jemand an deine gesamte Passwort-DB kommt, wird er so niemals das Klartext-Passwort rekonstruieren können.

Meines Wissens nach ist das die gängigste Methode und Passwörter zu speichern.