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

  • Allgemein

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

    Meiner Meinung nach sollte eine Endanwender Anwendung eh nie direkten Zugriff auf die Datenbank haben (ja es gibt Ausnahmen).
    DB Server so gut es geht absichern, nur wirklich notwendige Benutzeraccounts mit den niedrigsten Berechtigungen die möglich sind. Zugriff aufs OS soweit es geht einschränken.
    API davor stellen die die benötigten Funktionen exposed, DB Zugangsdaten verschlüsselt ablegen, bei der Konfiguration ein zufälligen Wert als Schlüssel generieren. Dient nicht zum Schutz der Zugangsdaten, sondern einfach nur damit die nicht im Klartext auf der Platte irgendwo liegen. Ebenfalls zugriff aufs OS soweit es geht einschränken.
    Client zu API kommunikation über TLS (ggf. mit cert pinning).

    slice schrieb:

    DB Zugangsdaten verschlüsselt ablegen
    Dann sind wir m.E. wieder beim Anfang: Wie werden die dann entschlüsselt und dann zur Verfügung gestellt? Wird das dann so gemacht, dass die DB-Zugangs-App das DB-Zugangspasswort beim Start abfragt, schaut, ob es passt? Wenn es nicht passt (weil der mehrfach versalzte und verhashte Hashwert (?) des korrekten Passworts nicht mit dem übereinstimmt, was das eingegebene Passwort erzeugt, wenn es den gleichen Hashalgo durchläuft), wird der Zugriff eben verweigert und die DB-Zugangs-App beendet sich oder schickt eine Warnmail an den Superadmin (?). Aber wenn das Passwort passt, stellt die DB-Zugangsapp den Zugang zur DB her und ermöglicht es Client-Apps mittels Umweg über die Zugangs-App den Zugriff auf die DB? Oder hau ich da schon wieder Verschlüsselung und Hashing durcheinander?

    slice schrieb:

    bei der Konfiguration ein zufälligen Wert als Schlüssel generieren
    ist gemeint mit: Zufallszugangspasswort zur DB erstellen und dies dem Einrichter mitteilen, damit er sich es merkt und bei Bedarf eben die DB-Zugang-App starten kann?
    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.
    Zumindest bei im Windows Umfeld mir MS SQL Server kann man integrated Security nutzen.
    Also der Dienst läuft unter einem Nutzeraccount und dieser Account hat Rechte auf der Datenbank. Somit muss kein Passwort für die Datenbank lokal gespeichert werden.

    Die Funktions- oder ServiceUser könnte in seinem Kontext auch verschlüsseln und entschlüsseln.

    Ohne die App von @mrMo zu kennen, aber bei einem meiner ehemaligen Arbeitgeber hatten wir einen Password Storage für das Team. Dort wurden also auch vom Serverdienst die Passwörter in der DB verschlüsselt und wieder entschlüsselt ans Web Frontend übergeben.

    Volle Sicherheit kann und wird es wohl nicht geben.
    Ich bin auch für Serverdienste/APIs und unter keinen Umständen direkter DB Zugriff eines Clients.
    Und dann den Dienst/API auf einem Server installieren zu dem wirklich nur Zugriff hat wer unbedingt nötig ist. Gleiches gilt tdie Datenbank.
    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.
    @VaporiZed es geht dabei nicht darum das die Zugangsdaten etc. sicher abgelegt werden, sondern einfach nur damit die nicht im Klartext vorliegen. Wir benutzten das bei System wo integrated Security keine Option ist.
    1. Service/API wird installiert, zufälliger Schlüssel wird generiert und in der Registry abgelegt
    2. Service/API wird konfiguriert
    2.1 Die Zugangsdaten für die DB etc. werden mit dem Schlüssel aus 1. verschlüsselt auf die Platte gelegt.

    Service/API startet, liest den Schlüssel aus der Registry, entschlüsselt die Daten aus der Konfigurationsdatei und benutzt diese.
    Bin durch ein anderes Thema hier gelandet.
    Nachdem ich mir alles durchgelesen hab, wollte ich eine Überlegung einstreuen, da ich allerdings das, was ich gleich vorschlage, noch nicht verstehe, mag das auch unsinnig sein.
    Also den DB Kram lass ich mal außen vor. An sich kann man ja alles abschließen und wenns nur das Fahrrad ist.
    Dann war das Problem: Wie kommen nur die Guten an den Schlüssel ohne dass die sich den halt merken müssen?

    Ich versuche gerade Web-APIs zu nutzen/verstehen usw... Auf jeden Fall hab ich da eine Web-API, da sendet man einen Abfragestring hin und bekommt von weiß ich wo eine Antwort.
    Bevor ich da freigeschaltet war (keine Ahnung wie das läuft), konnte ich eine Abfrage schicken und zurück kam nur ein nett gemeinter Stinkefinger.

    Das heißt irgendwie gibt es da eine Information wer die Abfrage schickt ohne dass es in der Abfrage selbst steht, und der "Antworter" kann diesen berechtigen oder auch nicht.
    Also so könnte eine Anwendung eine Passwortabfrage funken und wenn der Funk vom richtigen Standort kommt, der da explizit mal berechtigt wurde, dann gibts auch nen Passwort zurück.
    Die Passwörter selbst liegen dann nur bei dem, der sie verteilt (also nicht mehr beim Kunden) und der kann scheinbar bestimmen wer die bekommt und wer nicht.

    Die Web-Schnittstelle ist quasi das Passwortgedächtnis für den Kunden, aber das kann man bestimmt auch Hacken.
    Ähnlich hatte sich mal @SpaceyX in seinem Thread geäußert. Geht, ist aber auch nicht 100%ig. Jetzt wird's Spekulatius, z.B. mit: Man in the middle? Umleitung auf einen anderen Server?
    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.
    Da brauch man gar nicht soweit zu schauen, was passiert wenn der Server offline ist/die Datenträger kaputt gehen und das Backup unbrauchbar ist?
    Oder die Anwendung in einem Netz läuft, das keine Internetverbindung hat?

    Kurz: Es gibt keine Lösung, denn es geht einfach nicht - ohne das jemand jedes mal das Passwort eingibt.
    Ja, aber dass der Entwickler kein brauchbares Backup hat ist deutlich unwahrscheinlicher als dass der Kunde kein brauchbares Backup hat.

    Gut wenn man kein Internet möchte dann kann man aber auch eh viel schlechter attackiert werden.

    @VaporiZed Ja so wie Spacey das macht hab ich es mir vorgestellt nur, dass es für den Web-Zugang gar keine Zugangsdaten gibt.
    Auf der anderen Seite, jetzt wo ich das mit dem Hashwert verstanden hab, ist mein Vorschlag vielleicht doch etwas redundant.
    In meinem Fall hätte man das Passwort widerum als Klartext genauso gut hinterlegen können, weil reingucken schon gar nicht geht.

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

    "Security due to Obscurity" klingt für mich nach "Security through obscurity" und davon halte ich gar nichts, es macht den Code nur unnötig kompliziert und weniger wartbar.
    "Sicherheit durch Verschleierung" oder "Sicherheit durch Unklarheit" oder "Security due to Obscurity" oder "Security through obscurity" oder "Security by obscurity" meint alles ein und das selbe.
    Sicherheit schafft man damit dummerweise nicht, dafür aber, wie @slice schon sagte, komplizierten und wenig bis kaum wartbaren Code.

    Dksksm schrieb:

    "Sicherheit durch Verschleierung" oder "Sicherheit durch Unklarheit" oder "Security due to Obscurity" oder "Security through obscurity" oder "Security by obscurity" meint alles ein und das selbe.

    Da haben wir es in Deutschland einfacher mit unserer deutschen Sprache. Wir sprechen klar und verständlich. ;)

    mumpel schrieb:

    Da haben wir es in Deutschland einfacher mit unserer deutschen Sprache. Wir sprechen klar und verständlich.


    Des mechade a so ned song. gibt scho a boa gegenden, wost übahaupt nix mehr vohstehst.

    Passwörter speichern ist nie eine gute Idee. Vor Allem nicht im Code. Der Benutzer muss das Passwort eingeben, das ist die einzige Möglichkeit. Wie der Nutzer das handhabt, ist seine Sache. Gibt ja zig Anwendungen, die all Deine Passwörter mit einem Master-Passwort verschlüsseln. So muss sich der Anwender meist nur ein Passwort merken. Ist halt blöd, wenn man das vergisst oder ein Angreifer dieses abgreift. Ist aber dann nicht das Problem vom Entwickler.

    User-Zugangsdaten werden nicht verschlüsselt, sondern gehasht in einer Datenbank abgelegt. So gut wie jede Programmiersprache bringt in ihren Standard-Bibliotheken entsprechende Funktionen mit. Diese sollte man zwingen nutzen und niemals etwas selbst gebasteltes. Das Hashen sollte unbedingt mit Salt und in zufällig gewählten Runden ablaufen. Weiter noch sollte man den resultierenden Hash getrennt vom Salt und den Runden speichern. Sei es in verschiedenen Datenbanken (auf verschiedenen Rechern) oder in verschiedenen Dateien (auf verschiedenen Rechnern). Der User muss sein Passwort eingeben, es führt kein Weg daran vorbei.

    Ich hab hier ein Beispiel-Video (in 1440p anschauen).

    Die Unendlichkeit ist weit. Vor allem gegen Ende. ?(
    Manche Menschen sind gar nicht dumm. Sie haben nur Pech beim Denken. 8o

    mumpel schrieb:


    Aber auch da gibt es nicht mehrere Begriffe für eine Sache. ;)

    Das stimmt so nur weil "Begriff" und "Sache" verschiedene Wörter für denselben Begriff sind.

    Und sowas gibt es hingegen zuhauf im Deutschen und auch anderen Sprachen: Verschiedene Wörter für denselben Begriff.
    Männliche Ente und Erpel, Kakao und Schokomilch

    Wobei ich nicht sicher bin ob man mit "Security through obscurity" oder "Security by obscurity" oder "Security with obscurity" im Englischen alles grammatisch korrekt macht.
    "durch" kann im Deutschen auch die Bedeutung "aufgrund von" haben, aber ists im Englischen auch so?
    Gibt sogar noch mehr Umschreibungen für "durch" oder "aufgrund" im Englischen, je nachdem wie es am besten in den Satz passt eben. Zum Beispiel "due to", "based on", "caused by" oder "causing" (sozusagen für einen Folgeaufbau), "because of", "on basis of", "over", "therefore", "hence", "via", "thereby", "by virtue of", ggf. sogar "from" ...

    In deinem speziellen Satz ist "by" am ehesten korrekt, zumindest wenn es als "durch" gemeint ist. "With" passt nicht so gut, das stellt nur eine Relation her auf der beide Begriffe gleichwertig sind, aber eben miteinander (im Gegensatz zu "and", dann wäre der Fokus auf den beiden Wörtern aber ohne Korrelation bzw Abhängigkeit). "Through" passt auch nicht, das würde ich eher für Sätze verwenden, in denen es um das Durchdringen geht, "tunneln" oder "Schichten durchdringen" wäre die Assoziation die mir da als erstes einfällt, oder auch "Durchlass", "Durchlaufen" (loop through <-> iterate over) oder "Durchsatz" (e.g. "throughput"). Through, Via und Over sind in manchen Fällen nicht ganz leicht auseinander zu halten, zB "Power over Ethernet" > "Connecting via Putty" > "Sending packages through the Firewall".
    Hello World