McSodbrenner

Hi,
ich möchte ein Projekt auf die Beine stellen, welches in der Datenbank relativ sensible Daten enthält. Da ich mich vor einem Datenbank-Klau absichern möchte, würde ich gern die sensiblen Daten per AES verschlüsseln. Das Passwort für die Verschlüsselung sollte dann am besten das Passwort des Users sein und nicht in der Applikation hinterlegt sein, damit der Dieb auch beim Diebstahl der gesamten DB nichts in der Hand hat.

Ich möchte also on-the-fly, wenn der User eingeloggt ist, seine Daten entschlüsseln und ihm zur Verfügung stellen. Aber wie? Er soll ja nicht bei jeder Detail-Seite (es gibt recht viele Datensätze pro User) sein Passwort neu eingeben müssen. Und das Passwort in die Session zu schreiben wäre riskant, da beim Bruch der Applikation zumindest die Passwörter aller aktuell eingeloggten User offen darliegen.

Würde es hier Sinn machen, das User-Passwort in ein Cookie zu schreiben. Ich erhöhe damit zwar immens das Risiko einer XSS-Attacke, dafür aber nur für den einen User. Alle anderen Datensätze wären in dem Fall trotzdem sicher.

Und das Passwort hätte noch den Nachteil, dass, wenn der User sein Passwort ändern will, ich alle seine Daten neu verschlüsseln müsste.

Wie würdet ihr das machen?

Viele Grüße,
Christoph

__________________
http://mcsodbrenner.blogspot.com/
Serpent PHP Template Engine: http://code.google.com/p/serpent-php-template-engine/

Mister Ad

ChrisB

Hm, da scheint mir die Session aber doch der bessere Ablageort.

Über das, was auf deinem Server passiert, hast du die Kontrolle.
Über das, was auf dem Client vor sich geht, eher nicht.

Du könntest zweistufig arbeiten.
Entschlüssle mit dem Passwort, das der Nutzer eingibt, einen individuellen Schlüssel, den du zur Verschlüsselung der Daten verwendest.
Ändert der Nutzer sein Passwort, verschlüsselst du damit seinen Datenschlüssel neu. Damit kann die Verschlüsselung der Daten gleich bleiben.

lstegelitz

Was ist, wenn der Benutzer sein Paßwort vergisst (kommt relativ häufig vor)?

Oder wenn ein Benutzer kompromitiert wird (passiert auch häufiger, als das ein Server wirklich gehackt wird)? Sekretärin Fr. Müller-Lüdenscheidt schreibt ihr Passwort eh auf ein Post-It und klebt den an den Monitor, wenn es nicht dem Namen der Katze entspricht...

Verschlüsselungspasswörter sollten sehr stark sein - will ich einem 08/15 Userpasswort wie "müller123" vertrauen?

IMHO solltest du die Verschlüsselung auf EIN starkes Passwort aufbauen, welches dann an EINER (oder WENIGEN) sicheren Stellen aufbewahrt wird.

__________________
Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

McSodbrenner

Ja schon, aber WENN der Server ausgelesen wird, ist zumindest nur der eine User betroffen.

Stimmt, gute Idee. Löst leider nicht das Problem, dass ich seinen Schlüssel mit herumtragen muss.

Sollte mit ChrisBs Lösung zu erledigen sein.

Naja, es ist das Passwort für seine eigenen Daten. Wenn es zu schwach ist, ist das sein Problem. Wenn ich auf ein Passwort setze, muss halt nur das zu bekommen sein, um das System zu kompromittieren. Und da ich on-the-fly dekodieren muss, liegt das Passwort auf dem Webserver. Wahrscheinlich nicht der Ort, den du als sichere Stelle einstufst

__________________
http://mcsodbrenner.blogspot.com/
Serpent PHP Template Engine: http://code.google.com/p/serpent-php-template-engine/

ChrisB

Wenn dir der Client der sicherere Ort zu sein scheint - dann übertrage die verschlüsselten Daten, und dekodiere sie clientseitig

lstegelitz

Warum dann überhaupt verschlüsseln oder Sicherheit einsetzen?

Was ich meinte war: BENUTZER schreiben sich komplizierte Passwörter auf und bewahren diese Info nahe dem Rechner auf, ergo am Arbeitsplatz. Dieser wird frequentiert, Kollegen kommen vorbei, Kunden, Besucher, manchmal ist der Platz nicht besetzt (Mittag) und es bietet sich die Gelegenheit für Diebe.

Der Serverraum sollte abgeschlossen sein. Nur authorisiertes Personal sollte Zugang haben - kein Ort, an dem Besucher, Kunden oder die Putzkolonne durchkommt.

__________________
Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

McSodbrenner

Was soll das ändern?
Ich meinte ja nicht, dass der Client sicher ist. Doch wenn er kompromittiert ist, sind es zumindest nicht gleichzeitig auch alle anderen Kunden.

Ganz einfach, damit beim Diebstahl der Datenbank nicht alle User-Daten offenliegen.

Klar, kann immer passieren, betrifft dann aber nur diesen User.

Der Angriff kommt ja auch nicht unbedingt von innen, sondern von außen. Ich hatte vor kurzem das Problem, dass ein Root-Server innerhalb von drei Stunden, nachdem die Meldung einer Sicherheitslücke in SSH bekannt wurde, ein Rootkit drauf hatte. 3 Stunden... da hab ich mal gut gestaunt und aus Respekt den Hut abgenommen.

Weitere Meinungen, Lösungen? Arbeitet vielleicht jemand mit sensiblen Daten?

__________________
http://mcsodbrenner.blogspot.com/
Serpent PHP Template Engine: http://code.google.com/p/serpent-php-template-engine/

Chriz

Du kannst das schon machen, dass du die Daten mit dem Passwort des Users verschluesselst. Nur musst du dir eben auch klar sein, welche Konsequenzen das hat: Sehr viel Arbeit, keine Suche, keine Sortierung, keine Statistiken, viel Rechenaufwand, (hoffentlich!) unloesbare Probleme wenn das Passwort vergessen wird, trotz allem keine wirklich bedeutend hohe Sicherheit und einen Spezialfall abgedeckt, der vermutlich nie (?) auftreten wird. Da stellt sich mir die Frage nach der Verhaeltnismaessigkeit.

Klar, jeder findet seine Daten, die er zu verwalten hat wichtig, aber sind sie es auch objektiv? Ich behaupte mal, dass selbst Kontoinformationen auf einem Hostingserver mit guten, langen, sich regelmaessig aendernen Zugangspasswoertern, einer soliden, professionellen Anwendungsentwicklung sicher genug sind.

__________________
"Nuschel ich?" - "Was?"

robo47

Du schreibst nicht zufällig Software für einen gewissen Staat in den USA ?

-> States' Rights Come to Security Forefront -- Massachusetts State Data Protection Law

__________________
robo47.net - Blog, Codeschnipsel und mehr
| Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

McSodbrenner

Der Witz bei diesen Daten ist folgender. Es ist kein schwerer Verlust für den User selbst, wenn nur er sie verliert (zum Thema "unloesbare Probleme wenn das Passwort vergessen wird"), da die Daten geplant nur 7 Tage gespeichert werden. Der würde wahrscheinlich nur sagen: "Pech". Sie dürfen nur unter keinen Umständen jemand anders in die Hände fallen. Denn dann werden diese Daten ziemlich brisant.

Krass, aber nein. Es sind nicht mal persönliche Daten.

__________________
http://mcsodbrenner.blogspot.com/
Serpent PHP Template Engine: http://code.google.com/p/serpent-php-template-engine/