@Akanel
Verschlüsseln und Hashen bzw. umgekehrt mache ich wenn ich solch Daten speichern muss.. aber ganz furchtbares Thema, weil wohin mit dem Passwort für die Verschlüsselung(?). Im Code kann man es auslesen indem man die .exe dekompiliert…

Hier erst einmal eine Definition von Hash-Funktionen:
de.wikipedia.org/wiki/Hashfunktion
Für kryptographische Hash-Funktionen gilt, das sie nur in eine Richtung funktionieren, d.h. gleiche Eingabe gibt immer das gleiche Ergebnis aber aus dem Ergebnis kann man nicht die Eingabe ableiten (zumindest nicht in endlicher Zeit).

Passworte so sollten nicht nur gehasht sondern als salted hash gespeichert werden. Dies bedeutet, das noch ein 2ter Faktor mit in Hashfunktion gegeben wird. Zum Beispiel der Nutzername. Falls der Hash nicht geslted wird, kann man wenn man den Hash eines Passworts kennt alle Konten mit dem gleichen Hash öffnen (Rainbow tables).

Bei der Passwortüberprüfung wird dann der salted hash neu gebildet und mit dem gespeicherten Password-Hash verglichen. (In Lotus Notes kann man sogar den Hash des Kennwortes sehen. Hilft aber nichts)

Von den kryptographische Hash-Funktionen gelten alle Funktionen aus der Gruppe der md-Funktionen als unsicher, da sie leicht gebrochen werden können. Für den Einsatz, ob die Integrität von Daten gegeben ist sind sie durchaus ausreichend.

Von den sha-Funktion gelten nur noch die der Familie sha2 und sha3 als sicher. Scha-1 ist im Februar 2017 gebrochen worden.

In der Krypthographie sollte das Kerckhoff‘sche Prinzip berücksichtigt werden: Nicht das Verfahren sondern der Schlüssel ist geheim zu halten.

Am besten lustigsten finde ich immer die Ansätze Security by Obscurity.

Eines fällt mir auf Anhieb ein, was aber in der Praxis an eben der Praxistauglichkeit meist scheitert: Speicherung im Kopf und Eingabe bei jedem Programmstart.
Aber ich hab deshalb nix Besseres zu bieten, weil das Thema bei meinen Projekten nicht relevant ist. Ich drück mich also effektiv davor.

@Akanel Gar nicht speichern! Passwörter sollten niemals im Klartext gespeichert werden.

@slice wo soll das Passwort denn her kommen, welches ich zum verschlüsseln von Daten (welche in einer DB gespeichert werden) verwende? Bis dato habe ich noch keine Praxistaugliche Lösung hierfür gefunden.

Vom User? Und dem bietet man die Option, die Daten zum Beispiel im Credential Manager zu speichern.
Wenn die hops gehen ist es seine Schuld, nicht die deiner Anwendung.

Was soll verschlüsselt werden?
Die gesamte Datenbank oder nur die Passwortspalte.
Die Datenbank wird mit einem Kennwort verschlüsselt. Da muss man bei der Datenbank nachschauen wie das geht. Das Kennwort wird außerhalb der Anwendung in einer Ini-Datei gespeichert und beim Start der Anwendung von dort eingelesen und verarbeitet.
Wie macht ihr das denn sonst bei Datenbank-Anwendungen mit dem Zugriff auf die Datenbank? Ich hoffe, es gibt dort doch mindestens einen Datenbanknutzer mit Kennwort.

Passworte werden als salted hash gespeichert. Als Salt könnte man Nutzer bezogene Werte nutzen, die man sowie so schon in der Datenbank hat. Es sollte mindesten eine Hashfunktion aus den SHA-2 oder SHA-3 Familien sein.

Was ihr bisher so vorschlagt habt, klingt stark nach Security by Obscurity.

slice schrieb:

Vom User? Und dem bietet man die Option, die Daten zum Beispiel im Credential Manager zu speichern.
Wenn die hops gehen ist es seine Schuld, nicht die deiner Anwendung.

ne “allgemeine“ Daten wie z.b. eine Lizenznummer oder oderes von denen ich nicht will das sie jemand in der DB direkt einsehen kann. Keine Daten aus Benutzereingaben.

Wenn man Passwörter verschlüsselt in die DB speichert. Muss ich ja einen Schlüssel zum ver-/entschlüsseln haben. Wo steht dieser Schlüssel wenn nicht im Quellcode? Kann mir das jemand verraten?

Hallo zusammen.

ich eröffne hiermit mal eine Grundlage zur Diskussion zu folgender Grundsätzlichen Frage.

Wenn man Daten (z.B. Benutzerdaten, Lizenzkeys, Zugangsdaten ,…) verschlüsselt in eine DB (oder sonst wo hin) speichert. Muss man ja einen Schlüssel zum ver-/entschlüsseln haben. Wo steht dieser Schlüssel wenn nicht im Quellcode?

Gibt es hierzu praxistaugliche Lösungsansätze? Weil das wird oft diskutiert und bisher sagen alle nur was man nicht darf, aber keiner hat eine „richtige“ Lösung… Feuer frei

Edit: Um ein allgemeines Beispiel zu nennen:

Angenommen, ich erzeuge zur Laufzeit einen Wert (sagen wir „foo123“), der Verschlüsselt in die DB geschrieben wird und später entschlüsselt (von einem anderen User, an einem anderen PC) weiter verarbeitet wird. Wohin mit dem Schlüssel der zur Verschlüsselung genutzt wurde?

*Topics zusammengeführt*

Zugangsdaten werden im Regelfall gehasht und nicht verschlüsselt. Das ist viel sicherer.

Falls eine Verschlüsselung notwendig ist, so könnte man Daten mit dem Passwort ver- und entschlüsseln, was der User eingibt. Aber das kommt wohl auf den konkreten Fall an.

Marcus Gräfe schrieb:

Daten mit dem Passwort ver- und entschlüsseln, was der User eingibt

Ok, schon mal ein Lösungsansatz.

Wenn der User aber nichts direkt eingibt sondern z.B. ein Datensatz durch das Programm erzeugt und verschlüsselt gespeichert wird? Was ist mit den anderen Usern die auch an diesen Datensatz gelangen müssen?

Interessant wird's, wenn der User aus Bequemlichkeit keine Userdaten eingeben will. Wir haben ein Warenwirtschaftssystem, bei dem man zwar Userdaten zu Beginn eingeben muss. Aber dies hat nur Auswirkungen auf die Bedienmöglichkeiten. Die Datenbank selber ist davon unberührt. Jeder Benutzer hat über's GUI quasi vollen Zugang zum Datenbankinhalt. Wie steht's wohl da mit Verschlüsselung? Ist da der DB-Inhalt überhaupt verschlüsselt? Denn dann müssten ja die Datenbankzugangsdaten im Code versteckt sein.

Da kommt es jetzt auch auf die DB an und auf die Applikationsstruktur.

MS-SQL Server kann serverseitig Verschlüssen. Anpassungen an der Anwendung sind, meines Wissens nach, nicht nötig.

Greift der Benutzer nicht direkt auf die Datenbank zu, sondern es ist eine Client-Server-Architektur, so kann der Serverdienst Verschlüssen und es haben nur die Serveradmins / Applikations Manager einsicht auf den Schlüssel. Dieser kann dann in der Registry oder eine INI liegen.

Greifen die Clients direkt auf die DB, ist das meiner Meinung nach eine Fehlkonstruktion. Aber sei es drum.
Die Frage wäre dann, ob man nicht eine native C++ DLL wählt, in der die Funktionen sind, um etwas zu haben was nicht einfach dekompiliert werden kann.

in welcher Form liegt der Schlüssel denn dann in der Registry/ini?

Ich könnte doch die .Net exe Dekompilieren und dort sehen wie Daten mit dieser DLL ausgetauscht werden und damit wiederum die verschlüsselten Daten entschlüsseln, oder?

Ich versteh nicht was und warum du da etwas verschlüsseln möchtest und selbst wenn, was spricht dagegen das Kennwort vom Benutzer zu erfragen?
Benutzerdaten? Die brauchst du nicht zu verschlüsseln, das sind ganz normale Nutzdaten.
Lizenzkeys? Warum willst du den verschlüsseln? Das bringt dir gar nichts außer Mehrarbeit.
Zugangsdaten? Nope, die gehören nicht gespeichert!

Nenn konkrete Beispiele und wir können alle zusammen dafür Konzepte ausarbeiten, die nicht nur "security through obscurity" bieten.

@slice es geht hier um Grundsätzliche Lösungsansätze und nicht darum ein konkretes Problem zu lösen. Weil bisher habe ich (und vermutlich auch andere) nur sehr wenig konkrete Lösungen gesehen.

Aber wenn du was konkretes zum ausarbeiten möchtest. Wie wäre deine Lösung für z.B. folgendes Szenario:

mrMo schrieb:

Angenommen, ich erzeuge zur Laufzeit einen Wert (sagen wir „foo123“), der Verschlüsselt in die DB geschrieben wird und später entschlüsselt (von einem anderen User, an einem anderen PC) weiter verarbeitet wird. Wohin mit dem Schlüssel der zur Verschlüsselung genutzt wurde?

Was das für ein Wert ist und warum dieser verschlüsselt sein muss ist eigentlich irrelevant, nennen wir es mal „Kundenanforderung“.

Beispiel: Eine MySQL-Datenbank (z.B. MariaDB) liegt im Netzwerk bereit. .NET-Apps wollen auf den Inhalt via Entity Framework zugreifen. Der Datenbankzugriff erfordert das Zugangspasswort. Vom User ist nicht zu erwarten, dass er dieses kennt. Die App muss es also leisten, die Verbindung herzustellen. Dazu muss es das Passwort kennen. Dieses wäre im dümmsten Fall in der App. Wie macht man es richtig?

Damit zwei komplett (?) unterschiedliche Beispiele: Verbindung/DB-Zugang mit Passwort gesichert und Content verschlüsselt.