Ankündigung

Einklappen
Keine Ankündigung bisher.

Passwort-Handling bei verschlüsselten DB-Daten

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Passwort-Handling bei verschlüsselten DB-Daten

    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/

  • #2
    Zitat von McSodbrenner Beitrag anzeigen
    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.
    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.

    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.
    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.
    [SIZE="1"]RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?[/SIZE]

    Kommentar


    • #3
      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.

      Kommentar


      • #4
        Zitat von ChrisB Beitrag anzeigen
        Über das, was auf deinem Server passiert, hast du die Kontrolle.
        Über das, was auf dem Client vor sich geht, eher nicht.
        Ja schon, aber WENN der Server ausgelesen wird, ist zumindest nur der eine User betroffen.

        Zitat von ChrisB Beitrag anzeigen
        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.
        Stimmt, gute Idee. Löst leider nicht das Problem, dass ich seinen Schlüssel mit herumtragen muss.

        Zitat von lstegelitz Beitrag anzeigen
        Was ist, wenn der Benutzer sein Paßwort vergisst (kommt relativ häufig vor)?
        Sollte mit ChrisBs Lösung zu erledigen sein.

        Zitat von lstegelitz Beitrag anzeigen
        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.
        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/

        Kommentar


        • #5
          Zitat von McSodbrenner Beitrag anzeigen
          Und da ich on-the-fly dekodieren muss, liegt das Passwort auf dem Webserver. Wahrscheinlich nicht der Ort, den du als sichere Stelle einstufst
          Wenn dir der Client der sicherere Ort zu sein scheint - dann übertrage die verschlüsselten Daten, und dekodiere sie clientseitig
          [SIZE="1"]RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?[/SIZE]

          Kommentar


          • #6
            Zitat von McSodbrenner Beitrag anzeigen
            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
            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.

            Kommentar


            • #7
              Zitat von ChrisB Beitrag anzeigen
              Wenn dir der Client der sicherere Ort zu sein scheint - dann übertrage die verschlüsselten Daten, und dekodiere sie clientseitig
              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.

              Zitat von lstegelitz Beitrag anzeigen
              Warum dann überhaupt verschlüsseln oder Sicherheit einsetzen?
              Ganz einfach, damit beim Diebstahl der Datenbank nicht alle User-Daten offenliegen.

              Zitat von lstegelitz Beitrag anzeigen
              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.
              Klar, kann immer passieren, betrifft dann aber nur diesen User.

              Zitat von lstegelitz Beitrag anzeigen
              Der Serverraum sollte abgeschlossen sein. Nur authorisiertes Personal sollte Zugang haben - kein Ort, an dem Besucher, Kunden oder die Putzkolonne durchkommt.
              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/

              Kommentar


              • #8
                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.
                "[URL="http://www.youtube.com/watch?v=yMAa_t9k2VA&feature=youtu.be&t=25s"]Mein Name ist Lohse, ich kaufe hier ein.[/URL]"

                Kommentar


                • #9
                  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
                  [URL="http://www.robo47.net"]robo47.net[/URL] - Blog, Codeschnipsel und mehr
                  | :arrow: [URL="http://www.robo47.net/blog/192-Caching-Libraries-and-Opcode-Caches-in-php-An-Overview"]Caching-Klassen und Opcode Caches in php[/URL] | :arrow: [URL="http://www.robo47.net/components"]Robo47 Components - PHP Library extending Zend Framework[/URL]

                  Kommentar


                  • #10
                    Zitat von Chriz Beitrag anzeigen
                    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...

                    Klar, jeder findet seine Daten, die er zu verwalten hat wichtig, aber sind sie es auch objektiv?
                    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.

                    Zitat von robo47 Beitrag anzeigen
                    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
                    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/

                    Kommentar


                    • #11
                      Wenn du Angst vor einem Servercrash und damit offenen Daten hast und auch dem Cookie nicht vertrauen willst, dann lager das Vertrauen doch auf alle dir zur Verfügung stehenden Komponenten aus:

                      Daten in der Datenbank werden mit einem möglichst echt zufälligen Schlüssel verschlüsselt. Dieser Schlüssel wird mit einem vom Passwort abgeleiteten Schlüssel verschlüsselt und in der Datenbank abgelegt.
                      Nach dem Einloggen des Benutzers wird der erste Schlüssel entschlüsselt und in der Session verschlüsselt abgelegt. Der Schlüssel (SessionKey) für diese Verschlüsselung wird aus mehreren Werten abgeleitet, welche unterschiedlich abgelegt werden können: Hardcoded in einer PHP Config, in der Session, in einem Cookie, ... Mit den einzelnen Teilen für den SessionKey kann niemand etwas anfangen!

                      Ich hoffe und gehe mal stark davon aus, dass du eine sichere Ende-zu-Ende-Verbindung hast (TLS)?!

                      Kommentar


                      • #12
                        Danke, hört sich gut an. So hat man die Sicherheit zumindest schön auf alle Komponenten verteilt. Wirklich sicher geht wohl bei einer Web-Applikation nicht.
                        Wie machen das eigentlich diese ganzen Passwort-Kepper-Apps? Die haben doch ansatzweise das gleiche Problem?!

                        Zitat von Sirke Beitrag anzeigen
                        Ich hoffe und gehe mal stark davon aus, dass du eine sichere Ende-zu-Ende-Verbindung hast (TLS)?!
                        Na, aber sicher.
                        http://mcsodbrenner.blogspot.com/
                        Serpent PHP Template Engine: http://code.google.com/p/serpent-php-template-engine/

                        Kommentar

                        Lädt...
                        X