Hashing und Verschlüsseln von DB-Daten: best practice gesucht

  • Allgemein

Es gibt 57 Antworten in diesem Thema. Der letzte Beitrag () ist von Haudruferzappeltnoch.

    @mrMo Das kann man aber leider nicht pauschal sagen, es kommt immer auf den Anwendungszweck an.

    Zu deinem Beispiel:
    Warum möchtest du den Wert verschlüsseln/Was möchtest du damit bezwecken?
    Wer darf den Klartext sehen? Alle, nur bestimmte Personen, nur eine andere Person, nur du?
    Wie soll der Zugang zu dem Klartext geregelt werden (also wer Ihn sehen darf)?
    Möchtest du symmetrische oder asymmetrische Verschlüsselung einsetzten?

    @VaporiZed Warum muss die App das ver-/entschlüsseln? Möchtest du die Daten einfach verschlüsseln damit die nicht im Klartext in der DB vorliegen?
    Wie möchtest du sicherstellen das nur berechtigte Clients auf deine Datenbank zugreifen?

    Ich würde da wahrscheinlich zum Client-Server-Modell greifen und die DB nur vom Server aus erreichbar machen.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „slice“ ()

    @slice
    Warum möchtest du den Wert verschlüsseln/Was möchtest du damit bezwecken?
    -> gesetzliche Vorschrift, Datenschutz, Paranoia

    Wer darf den Klartext sehen? Alle, nur bestimmte Personen, nur eine andere Person, nur du?
    -> alle Benutzer meiner Software, die entsprechende, über meine Software erhaltene, Rechte besitzen.

    Wie soll der Zugang zu dem Klartext geregelt werden (also wer Ihn sehen darf)?
    -> Über Programmoberfläche meiner Software und Benutzerrechte geregelt

    Möchtest du symmetrische oder asymmetrische Verschlüsselung einsetzten?
    -> Mir egal, das was „besser/sicherer“ ist.
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen

    slice schrieb:

    Warum muss die App das ver-/entschlüsseln? Möchtest du die Daten einfach verschlüsseln damit die nicht im Klartext in der DB vorliegen?
    Wie möchtest du sicherstellen das nur berechtigte Clients auf deine Datenbank zugreifen?
    Nein, ich möchte nix verschlüsseln. Das mit dem Content verschlüsseln war auf das Beispiel von @mrMo bezogen. Ich will auf die passwortgesicherte DB zugreifen, er will Content verschlüsseln.

    Aha: Damit wäre also die (oder nur eine mögliche?) Antwort auf mein Beispiel: Auf dem Server liegt die DB, nur eine dort laufende App kann darauf zugreifen, diese kennt das Passwort, Clients können nur mit der App, aber nicht mit der DB kommunizieren. OK.
    Unberechtigte Clients: gute Frage. Hab ich bei mir nicht. Von daher hab ich mir die Frage nie gestellt. Sollte aber aus Sicherheitsgründen beantwortet werden. Ich müsste da erstmal überlegen, ob die DB überhaupt außerhalb unseres 8-PC-Netzwerks erreichbar ist.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    VaporiZed schrieb:

    Auf dem Server liegt die DB, nur eine dort laufende App kann darauf zugreifen, diese kennt das Passwort
    Ok, nun die Frage, woher kennt die App wiederum das Passwort und wie ist selbiges dort gesichert?
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen
    Gute Frage. Nicht, dass das PW in der App ist, am Server jemand die Exe kopiert, die App dekompiliert und dann ham wa wieder den Salat. Der Server steht bei uns nämlich nicht in nem Tresorraum. Wir sind nur ein kleiner 10-Mann-Fachhandel.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.
    @mrMo Der einfachste Weg wäre die Festplatte verschlüsseln + Logindaten + ACL.
    Für alles andere bräuchte man wesentlich mehr Zeit und Details.

    @VaporiZed Ich würde generell jeden Client erst mal als unberechtigt ansehen, ansonsten kann jeder an deine API gehen und die Daten aus der DB lesen/bearbeiten/löschen.
    Heißt die Clients müssen sich gegenüber deiner API authentifizieren (ist das das richtige deutsche Wort? Ich mein damit "authenticate"), im idealfall mit Logindaten für die Benutzer deiner Anwendung.
    Wenn du im Unternehmensumfeld bist und ein AD zur Verfügung hast könntest du das darüber regeln, wenn du/ihr AzureAD benutzt könnte man über OAuth/SAML2 reden.

    Bezüglich #24 und #25:
    Abhängig von der DB, wenn ihr MSSQL benutzt könntet ihr integrated security benutzten (bei anderen DBs kenne ich mich nicht aus), ansonsten müssen leider irgendwo die Zugangsdaten im Klartext vorliegen (aber lieber auf dem Server als auf dem Client), da führt kein Weg dran vorbei.

    Edit: Man könnte bei der Installation der API ein Wert generieren und den benutzen um die Zugangsdaten zu verschlüsseln, das würde verhindern das die Zugangsdaten im Klartext auf der Festplatte liegen, aber ein wirklicher Schutz ist das nicht.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „slice“ ()

    slice schrieb:

    @mrMo Der einfachste Weg wäre die Festplatte verschlüsseln + Logindaten + ACL
    Ok, sorry aber das halte ich für absolut praxisfern… die ganze Festplatte verschlüsseln wegen einem einzigen Wert in der DB?

    integrated security bedeutet das der Server Admin (der ggf. mein Kunde ist) sich selbst Zugang verschaffen kann. Dies ist aber ggf. von mir nicht gewünscht.
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen
    Sorry, mir war nicht klar das du nur von einem Wert sprichst, gerade weil du Multi-User erwähnt hast, dachte ich es ging um die gesamten Nutzdaten in deiner Datenbank.

    Edit: Wenn der Kunde Zugriff auf die Machine hat auf der die DB läuft kann er sich immer irgendwie Zugriff verschaffen.
    Und selbst wenn, es sind doch seine Daten? Warum sollte der Kunde nicht zugriff auf seine Daten haben dürfen? Wenn er was kaputt macht ist es nicht deine Schuld.

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von „slice“ ()

    slice schrieb:

    Warum sollte der Kunde nicht zugriff auf seine Daten haben dürfen? Wenn er was kaputt macht ist es nicht deine Schuld.
    Weil er selbige nicht unkontrolliert, außerhalb meiner Software, verändern darf. Es ist eine gesetzliche Vorschrift und der Kunde hat viel Geld bezahlt damit diese bestmöglich erfüllt wird. Zumindest in diesem fiktiven Beispiel.

    Im Grunde ist es auch egal warum. Es ist die Aufgabenstellung. Der Sinn oder Unsinn darin ist nicht Bestandteil der Aufgabenstellung.

    Bin gespannt was hier sonst noch für Lösungsansätze kommen, weil bisher habe ich noch keine wirkliche Alternative zum „key im quellcode“ gesehen.
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen
    @mrMo da wäre halt wieder die Frage nach dem Datenbank System und ob dieses nicht selbst die ganze DB verschlüsseln kann.

    Zu Thema Änderungen nur durch das Programm: Bei sensiblen Daten würde ich immer eine Änderungshistorie schreiben. Zusätzlich kann über einen Hash der Daten geprüft werden ob diese außerhalb des Programms geändert worden sind.

    Wenn es eine Server-App gibt die unter einem Funktionsuser läuft, dann könnten Passwörter im Kontext des Funktionsuser gespeichert werden. Zum Beispiel Verschlüsselt mit dem FU-Passwort, bzw. Eine Ableitung daraus.
    Die deutsche Sprache ist Freeware, du kannst sie benutzen, ohne dafür zu bezahlen. Sie ist aber nicht Open Source, also darfst du sie nicht verändern, wie es dir gerade passt.
    @MrTrebron Ich arbeite z.b. mit dem MS SQL Server. Wie performant ist solch eine Verschlüsselte Datenbank? Wie funktioniert das durchsuchen von Tabellen wenn man z.B. nach einem Ortsnamen in der Tabelle Orte (whatever) sucht?

    Edit: Wo/Wie sind in deinem Lösungsansatz die Zugangsdaten zur Datenbank gespeichert?
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen
    Zur Performance kann ich leider nichts sagen. Unsere DBs sind alle im eigenen Netzwerk.

    docs.microsoft.com/de-de/sql/r…ion/sql-server-encryption
    Wäre der Einstiegspunkt.

    Always Encrypted könnte was für dich sein
    Die deutsche Sprache ist Freeware, du kannst sie benutzen, ohne dafür zu bezahlen. Sie ist aber nicht Open Source, also darfst du sie nicht verändern, wie es dir gerade passt.
    Interessant, hast du damit schon gearbeitet/Erfahrungen? Woher kommt der Schlüssel welcher zur Verschlüsselung verwendet wird?

    Auf den ersten Blick leider schon Einschränkungen gefunden
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen
    Nein, leider keine Erfahrungen. Habe DB-Verschlüsselung bisher noch nicht gebraucht.

    Ich hatte in den Docs Mal irgendwo gesehen, dass Schrittweise Anleitungen dabei sind.
    Die deutsche Sprache ist Freeware, du kannst sie benutzen, ohne dafür zu bezahlen. Sie ist aber nicht Open Source, also darfst du sie nicht verändern, wie es dir gerade passt.
    Schade, ich dachte das sich hier mehr Leute an dieser Grundsatzdiskussion beteiligen. Offensichtlich weiß jeder was man nicht tun soll, aber wenn es konkret wird Eiern alle rum…

    Ich für meinen Teil habe noch keine „praxistaugliche Lösung“ gefunden um einen Key, welcher zur Verschlüsselung von Daten verwendet wird, sicher zu verwahren.

    Aktuelles Resümee:
    Wenn jemand meine .exe dekompilieren kann und in der Lage ist dort im Quellcode ein Passwort zu finden, der wird in der Lage sein andere „Schutzmechanismen“ auszuhebeln. Von daher verbleibe ich dabei den Key im Quellcode zu „verstecken“ (z.B. eigene Methode die einen Key erzeugt damit dieser zumindest nicht direkt im Klartext auffindbar ist).

    Edit: Lösungsansatz von @MrTrebron war bisher das vielversprechendste, scheint allerdings Einschränkungen zu haben und bzgl. Performance zumindest mal ungewiss. Zudem nur mit einer DB möglich. Was wenn man Daten verschlüsselt lokal in einer TXT speichert…
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „mrMo“ ()

    Dann braucht es aber wieder eine Entschlüsselungsmethode. Und die ist im Code und somit auffindbar …
    Ich find's auch komisch. Es gibt ja unzählige DB-Systeme und noch mehr Leute, die damit auch admintechnisch arbeiten. Es muss ja also ein paar Patentlösungen geben, sonst wär ja alles immer unsicher.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.
    Ich habe einen Artikel gefunden der das Problem behandelt, leider ist mein Englisch nicht das beste so dass ich nicht alles wirklich verstehe.
    Vielleicht mag sich ja auch jemand den Artikel durchlesen. Hier der Link https://medium.com/dealeron-dev/storing-passwords-in-net-core-3de29a3da4d2

    Wenn ich den Code richtig verstehe wird der Salt aus dem zuvor generierten Hash ermittelt. Liege ich da richtig?
    Rechtschreibfehler betonen den künstlerischen Charakter des Autors.
    Ich verstehe es so: Das Passwort selber wird wiederum nicht gespeichert, sondern nur ein rekursiv ermittelter Hashwert, der bei jedem Durchgang neu gesalzt wird.
    Allerdings ist das Beispielregebnis da insofern für mich als Sicherheitslaie (ja, ich geb's zu) insofern wieder komisch, weil ja am Ende eine Funktion verwendet wird: public (bool Verified, bool NeedsUpgrade) Check(string hash, string password). Irgendjemand schrieb im Forum mal: Dann wird die App eben dekompiliert, überall, wo nach dem Verified gefragt wird, setzt man true, rekompiliert es und der Salat ist wieder da.
    Der ganze Artikel beschreibt wohl somit, wie man prüfen kann, ob das vom User eingegebene Passwort mit dem übereinstimmt, was er z.B. bei der Registrierung angegeben hat, ohne Gefahr zu laufen, dass ein Angreifer beim Hacken (oder doch eher Cracken?) der DB an die Passwörter an sich kommt. Ist aus meiner Sicht interessant, aber m.E. für @mrMos wiederum nicht, da es ja u.a. darum geht: Wiederherstellung einer verschlüsselten Sache, die in der DB steckt. Daher wird mir jetzt klar: der verlinkte Artikel beschäftigt sich mit Hashing, nicht mit Verschlüsselung (welche man ja auch codetechnisch rückgängig machen muss, worum es ja beim Hashing eben nicht geht.)
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.
    @mrMo Weil es keinen Weg gibt, solange irgendwer Zugriff auf deine Anwendung oder das System selbst hat, kommt er auch immer an die Daten.
    Du kannst es Ihm nur erschweren, mehr aber nicht. Schau dir einfach nur mal gängige Software an, die zum Beispiel auf Servern läuft, irgendwo stehen immer die Daten für die Datenbank/Mailserver/was auch immer.

    Wenn dein Kunde keinen Zugriff auf die DB haben soll bzw. nur über deine Anwendung, müsste die DB bei dir laufen und du erstellst eine API über die der Kunde zugriff hat.
    Dementsprechend ist also anscheinend der sicher(st)e Weg: direkten Zugriff auf die DB + Entschlüsselung verschlüsselter Daten nur am Server zu ermöglichen und den Server quasi wegzusperren bzw. für den Otto-Normal-User unzugänglich zu machen?
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.