Verschlüsselung von Userdaten - temporärer Key in db, session, oder wo am besten?

[klaba]

Hallo Community,

ich arbeite an einem Projekt, bei dem jeder User in seinem persönlichen Bereich Daten abspeichern kann, die in einer db gespeichert werden, sowie Dateien hochladen kann. Daher sehe ich mich natürlich mit einigen Sicherheitsfragen konfrontiert, zu denen ich mir schon eine ganze Menge Gedanken gemacht habe, doch eine bestimmte Sache interessiert mich ganz aktuell. Vorher muss ich aber situationsbedingt ein wenig ausholen

Ich verschlüssele alle Daten, die ein User in der Datenbank einträgt mit dem Blowfish Algorithmus. Als Key für diesen dient das Loginpasswort des Users selbst, damit zum einen Fremde, und zum anderen auch ich als Anbieter, keinen Zugriff auf seine (evtl. persönlichen) hinterlegten Daten habe - letzteres also nicht nur aus Sicherheits- sondern eben auch Vertrauensgründen. Das Loginpasswort selbst wird nur als Hash in der db gespeichert, so kenne auch ich dieses nicht. Das Loginscript funktioniert über die aktuelle Session-id, die beim Login eingetragen wird und auf den geschützten Seiten abgefragt wird (es dürfte sogar weitgehend das Script sein, welches hier auf php-resource, ich glaube im Tutorial, besprochen wurde).

Das Problem an der Geschichte ist aber nun folgendes: Das Userpasswort wird nur ein einziges Mal im Klartext an den Server übermittelt, nämlich per POST beim Loginvorgang. Um dieses schließlich auch als Key nutzen zu können, ist es aber eben auch nötig, dass es dem Server im Klartext vorliegt, damit er den Blowfish Key daraus generieren kann. Da es natürlich Unterseiten gibt, muss es auch an diese übermittelt werden um den Key daraus generieren zu können. Nun sind mir bei der Entwicklung der ganzen Geschichte damals nur zwei Möglichkeiten eingefallen: Entweder als Sessionvariable, oder temporär in der Datenbank speichern. Da ich mich mit Sessionvariablen noch nicht besonders beschäftigt habe, habe ich zunächst die zweite Lösung umgesetzt, frage mich aber, ob das so praktikabel ist bzw. ob erstere Version nicht doch besser wäre.

Und deshalb wende ich mich nun an euch, um evtl. ein paar Tipps zu erhaschen. Momentan läuft das folgendermaßen ab: Beim Login wird das gePOSTete Passwort zunächst mit einem Masterkey verschlüsselt und so in der Datenbank temporär abgelegt. Bei jeder Usereingabe wird dann dieses verschlüsselte pw wieder aus der db geholt, wieder decrypted, daraus der Userkey generiert und mit diesem dann die Userdaten verschlüsselt und so in der Datenbank gespeichert. Klingt hoffentlich jetzt nicht all zu verwirrend

Ich hielt diese Lösung durchaus für praktikabel, da zumindest auf dem Clientrechner das Passwort nicht im Klartext vorliegt (wir gehen jetzt mal davon aus, dass der User die Webseite besonders nicht nur von seinem eigenen, sondern durchaus auch von fremden und öffentlichen Rechnern aus verwenden wird). Nur wird dadurch imho diese "Vertrauensgeschichte" wieder ein Stückweit ausgehebelt, da ich als Admin, der Kenntnis vom Masterkey hat, das temporäre Userpasswort decodieren könnte. Zumindest während einer Session, denn danach wird es ja wieder gelöscht.

Wie würdet ihr das lösen? So beibehalten, oder lieber in eine Sessionvariable packen, oder hätte jemand einen evtl. noch deutlich besseren Tipp? Oft sieht man ja den Wald vor lauter Bäumen nicht...

Freue mich über ein paar Tipps und hoffe, mein "Problem" nicht zu konfus dargestellt zu haben.

[Kropff]

also wenn du löblicherweise so darauf erpicht bist, das passwort nicht zu kennen, so solltest du mit sessions arbeiten. und das session timeout entsprechend niedrig setzen.

was die sicherheit angeht, solltest du dir ggf. das hier mal zu gemüte führen, speziell was dateiuploads angeht.

peter

[klaba]

Danke schonmal für diese überaus schnelle Antwort und den angehängten Link. Ich werde mir die Informationen dort auch noch einmal aufmerksam anschauen, denn über PHP Sicherheit kann man ja nie genug wissen

EDIT: Habe die Session-Version jetzt auch mal umgesetzt, was auch nicht sehr schwierig war. Das mit Masterkey verschlüsselte Userpasswort wird jetzt in einer Sessionvariable gehandhabt und in den entsprechenden Seiten dann wieder entschlüsselt und daraus der Key für den einzelnen User erzeugt. Was das Session Timeout allerdings betrifft, habe ich leider nur sehr wenig aufschlussreiche Informationen finden können. Ich bin mir daher im Moment nicht so sicher, wie lange diese Session Variablen ihre Gültigkeit behalten. Hat da vielleicht jemand weitergehende Infos für mich? Habe das daher erstmal so gelöst, dass der User zwangs-ausgeloggt wird, wenn diese Sessionvariable nicht mehr gesetzt ist und er versucht, eine Aktion auf der Seite zu starten (und gleichzeitig wird die komplette Session gelöscht). Darüberhinaus habe ich ohnehin noch einen Cronjob laufen, der nach xx Minuten der Inaktivität die Session-Id des Users aus der Datenbank löscht, wodurch dieser beim Aufruf einer Seite nicht mehr eingeloggt wäre und somit auch keine Aktionen mehr durchführen kann.

EDIT2: Ich habe nun auch den "Masterkey" ein Stück aufgebessert, in dem dieser nun keine feste Zeichenkette mehr, sondern die Session-Id selbst plus ein kleines "salt", welches in meinem php-code steckt, ist. Sollte es dazu noch Sicherheitsbedenken geben?

[onemorenerd]

Es ist ja löblich, dass du dich so um die Daten deiner User sorgst, dass du grundsätzlich alles verschlüsselt speicherst. Aber irgendwann beim Transport oder der Verarbeitung liegen sie auch mal in lesbarer Form im Speicher.
Vertrauensfrage: Wie hast du deinen Server und die Transportwege vom/zum Client abgesichert?

[asp2php]

Was passiert, wenn der User sein Passwort vergisst oder sein Passwort ändert? Im Prinzip mußt du alle seine Daten umändern/umkodieren, wenn er aber Gigabytes von Daten hat, und du hast nicht zu wenig User von der Sorte, die ganz Ernst mit der Datensicherheit nehmen und somit ihre Passwörter monatlich/wöchentlich ändern, wat nu?

Dein Vorhaben in aller Ehre, aber so geht es nun mal nicht. Das ist unrealistisch und unpraktikabel. Der vernünftigere Weg wäre z.B.:

- User hat PW und kann jeder Zeit sein PW nach Lust und Laune ändern
- User identifiziert sich in deinem System, wenn OK bekommt er seine Daten
- Die Daten von User legst du verschlüsselt ab, und zwar mit einem nur dir bekannten Schlüssel für alle Sorten von Userdaten und für alle User

Denn, wenn der User seine Daten auf deinem Server schaufelt, dann muss er dir schon vertrauen und du musst ihm schon gewisse Vertrauenswürdigkeit und Seriösität entgegen bringen, so dass die Sicherheitsfrage im Grunde genommen nicht in Frage kommt.

[klaba]

Hallo,

die Dinge, die ihr geschrieben habt, sind selbstverständlich absolut korrekt.

Aber erstmal @onemorenerd:

Natürlich, das ist mir bewusst. Ich möchte ja auch nur das von meiner Seite aus Mögliche (und hier schließe ich einfach auch Dinge wie die eigenen Skills und technischen Möglichkeiten mit ein, die begrenzt sind - ja, ich habe im Moment auch nur ein shared Hosting) tun. Zumindest was die Transportwege angeht, bliebe dem User die Wahl, dies per SSL zu tun. Beim Server muss ich wiederum meinem Hoster schon vertrauen.

@asp2php:

Das ist natürlich so ein Thema, das du da ansprichst. Und ich danke dir auch dafür, denn ich habe bislang witzigerweise an alles gedacht, außer dass ein User doch tatsächlich sein Passwort wirklich ändern WILL Natürlich müsste man alle Daten neu codieren, da der User mit geändertem Passwort nur ziemlichen Müll sehen würde, aber nicht seine Daten.

Nun habe ich das User-eigene Schlüsselsystem aber schon so schön integriert, das es fast schade wäre dies durch einen schnöden "Generalschlüssel" zu ersetzen. Ich gehe da auch immer ein Stückweit von mir selbst aus - das Projekt ist ursprünglich für die eigene Verwendung angefangen worden, aber es ist einfach schöner und spannender, so etwas gleich multi user fähig zu gestalten. Mir selbst würde es einfach ein besseres Gefühl geben, zu wissen dass der Admin eines Dienstes nicht mal eben nachschauen KANN, was ich mir da gerade für eine Notiz hinterlassen habe o.ä.. Lassen wir dabei mal völlig außen vor, dass der User das ohnehin in keinem der Fälle wirklich prüfen könnte. Aber ihr versteht sicher was ich meine.

Da es sich glücklicherweise nicht um Gigabytes von Daten handelt, grüble ich aber nun. Die Daten der User bestehen aus zwei Teilen, einmal reiner Text, der in der Datenbank gespeichert wird. Das *könnte* man noch ohne größere Umstände umcodieren, da sehe ich kein Problem. Bei hochzuladenden Dateien ist es so, dass gar nicht sehr viel Webspace bereitgestellt wird, denn es sollen nur ein paar wenige MB sein, für ein paar wenige wichtige Dinge, die man brauchen kann. Also eine Art online USB Stick in absoluter Light Version. Zudem kann der User wählen ob er die Dateien auf dem Server verschlüsseln lassen möchte oder nicht. Erstere Möglichkeit ist dabei aus Performancegründen aber auch nur auf 1 MB beschränkt. Es wären also auch nur diese Dateien, die um zu codieren wären - oder man zwingt den User bei einem Passwortwechsel, zumindest diese kleinen Dateien nochmal hochzuladen. Vielleicht nicht die feine Art, aber würde funktionieren.

Oder zu guter letzt: Den User im Vorfeld einfach selbst entscheiden lassen, ob er einen eigenen Key, verbunden mit etwas mehr Sicherheitsgefühl aber ein wenig Komforteinbußen, oder eben einen festen Key benutzen möchte. Auch das wäre kein Beinbruch zu implementieren...

[onemorenerd]

Der User kann wählen, ob er SSL benutzt? Wie denn das?
Entweder bietest du es an oder nicht. Wenn du es anbietest, solltest du mit deiner sicherheitsfixierten Einstellung eigentlich darauf bestehen. Hat doch keinen Sinn, wenn die Daten bei dir super sicher sind, aber schon auf dem Weg dorthin manipuliert werden können.

Was ist das eigentlich für ein Projekt? Da du alle Daten so verschlüsselst, dass jeder User nur seine eigenen lesen kann, gibt es wohl keine Suche, keine Userprofilseiten, kein Filesharing und für dich als Betreiber keine Möglichkeit, rechtswidrige Inhalte als solche zu erkennen. Das lässt nur noch einen Use Case zu: eine Online-Festplatte für Datensicherungen, auf die niemand außer dem Besitzer zugreifen kann. Wenn es das ist, dann ist dir hoffentlich klar, dass man das durch Weitergabe des Passworts als "abhörsichere" Tauschbörse verwenden kann und welche rechtlichen Implikationen das hat - Stichwort PirateBay.

[asp2php]

Das oberste Gebot der Sicherheit verlangt aber, dass man sein Passwort in gewissem Abstand ändern soll/muss. Bei uns in der Fa. 4 mal im Jahr und bereits verwendete PW erst nach 10 Zyklen wieder verwendbar ist. Von daher wenn du mit sicherheitsbewußten User zu tun hast, dann hat dein Server was zu tun.

Aber dein Konzept hat auch Lücken, denn das PW, mit dem die Daten verschlüsselt werden, muss irgendwo abgelegt werden, egal, ob in Hashform oder im Klartext; und somit kannst du, als Programmierer, immer an den Inhalt der Daten dran kommen. Daher ist dein Vorhaben in meinen Augen eine reine Illusion was du versuchst, deine User vorzugaukeln. Besser wäre, dass du an dir arbeiten soll, so dass man dir vertraut, genauso wie man dem Mail-Admin vertraut, dass er nicht in die Mailpostfächer fremde Leute reinguckt.

[klaba]

Zugegeben, für den Zweck für den es angedacht war, sind die Sicherheitsvorkehrungen Kanonen auf Spatzen. Ich war nur recht erfreut darüber, das diese Implementierung so gut funktioniert hat. Aber genau dafür holt man sich ja auch noch dritte Meinungen ein und denkt über diese nach. Ihr habt also völlig recht, das Ganze Konzept hat ein paar Lücken bzw. sind einige Dinge wohl noch inkonsequent.

Erstmal beschreibe ich das Projekt aber einfach mal etwas genauer, damit man ein besseres Bild davon hat: Mir ging es im Prinzip nur darum, dass ich bestimmte Daten, seien es Bookmarks, Notizen, evtl. sogar ein paar Passwörter, online hinterlassen bzw. verwalten kann, damit ich auf diese Daten auch mal von einem anderen Rechner zugreifen kann. Dazu noch ein paar beliebige Dateien und Bilder. Also nicht zwangsläufig die sensibelsten, aber doch mindestens persönliche, Daten. Es soll jetzt hier auch gar nicht die Idee oder deren "Originalität" thematisiert werden. Wie ich bereits erwähnt hatte, fing das Ganze damit an, dass ich eine eigene Lösung nach meinen persönlichen Vorstellungen wollte. Wichtig ist mir dabei die Einfachheit. Es ist eine recht abgespeckte Variante, die sich auf das nötigste konzentriert. Und dazu gehört auch, dass nicht sehr große, sondern nur wenige kleine Dateien hochgeladen werden können. Ich hatte gehofft, dass diese Tatsache selbst schon einen Mißbrauch als Tauschbörse verhindern würde. Wem bringt es etwas, wenn er auf diese recht umständliche Weise nur mal eben eine handvoll MP3s tauschen kann pro Account?

Edit: Wegen dem SSL: Ja sicher, auch hier, inkonsequent gedacht. Aber die Idee dahinter war diese: Da ich momentan bei meinem Hoster eben keine eigene IP habe, kann ich nur ein unsigniertes, shared SSL Zertifikat nutzen, das mir zwar die Verschlüsselung ermöglicht, aber zum einen nur über eine unschöne URL-Struktur über die Domain meines Hosters erreicht werden kann und zum anderen den User damit zum setzen einer Browserausnahme zwingt. Da dachte ich mir: Okay, wenn ich zuhause an meinem Rechner ein paar Daten einpflege, dann kann ich auch auf SSL verzichten, denn sonst müsste ich mir ja ganz allgemein Gedanken machen ob ich mit meinem eigenen PC noch ins Internet gehen sollte Unterwegs aber, evtl. an einem "public pc", betrete ich die Seite dann eben per SSL.

Ich danke euch auf jeden Fall schonmal sehr für eure kritischen Bemerkungen, sowas ist wirklich wichtig. Klar wäre es ein einfaches, selbst eine "Abhörfunktion" einzubauen, das stimmt. Insofern sollte man also die soziale Komponente wirklich nicht vergessen und versuchen, Vertrauen zu schaffen. Habe diese Dinge noch ein wenig außer acht gelassen, da ich nunmal im Moment nicht dazu gezwungen bin, mein "Produkt zu verkaufen", und mich daher aufs technische zu sehr fixiert. Es fing als reines Privatprojekt an, das aber mit der Zeit doch zu schade wurde, um es für mich zu behalten - immerhin freut man sich ja durchaus wenn die eigene Arbeit auch für andere nützlich sein kann. Ich möchte aber eben nur, dass diese anderen dann auch mehr Spaß als Frust daran haben