DB-Zugangsdaten verschlüsseln

[Ykcim]

Hallo Zusammen,

es ist kein neues Thema, aber ich habe nichts gefunden, was mir weiterhilft. Vielleicht fehlen mir auch die Vorkenntnisse und ich kann deshalb nichts mit den Ergebnissen der SuFu anfangen...

Ich habe eine Anwendung, die auf eine MySQL-Datenbank im Netzwerk zugreift. Ich weiß aber nicht, wie ich die Zugriffsdaten verschlüsseln kann. Heute habe ich eine einfache TXT-Datei in der die Informationen wie IP-Adresse, Username, Passwort, Port und Schema als Klartext hinterlegt sind. Meine Anwendung ließt diese Informationen aus, bestückt die Connection damit und stellt so die Verbindung zur DB her.
Wenn ein Unbefugter die TXT-Datei öffnet, kann er mit einem entsprechenden Programm auf die DB zugreifen und wer weiß was damit machen.

Gibt es eine einfache Möglichkeit, wie ich meine Datenbank vor unbefugten Zugriffen aus dem Netzwerk schützen kann?

Vielen Dank
Patrick

[mkinzler]

Verschlüssele die Einträge in der Text/Ini-Datei.

[Ykcim]

Wie geht das denn? Ich hatte gehofft, dass das ich das so machen kann, aber ich weiß leider nicht, wie man das umsetzen kann...

Hast Du eine Starthilfe für mich?

Vielen Dank
Patrick

[mkinzler]

Statt

Delphi-Quellcode:

  wert := i.ReadString('Section', 'String', 'Default');

Delphi-Quellcode:

  wert := Trim(LbRijndael.DecryptString(ini.ReadString('Section', 'String', LbRijndael.EncryptString('Default'))));

Beispiel ist mit TurboPower Toolbox. Es gibt aber andere Bibliotheken für die Verschlüsselung.

[Delphi.Narium]

Suchmaschine meiner Wahl: [GOOGLE]verschlüsseln delphi source[/GOOGLE]

Oder oben rechts "Verschlüsseln" eingeben und Suche starten, auf den Reiter Code-Library wechseln und eine Lösung auswählen.

[Ykcim]

Vielen Dank - ich werde mich morgen mal dransetzen. und mich dann melden.

Schönen Feierabend

[KodeZwerg]

*war müll* Hinweis zur CodeLib plus Google war ja gegeben.

[Zacherl]

Verstehe ich das richtig, dass das Programm auch von anderen (ggfls. unbefugten) Leuten verwendet wird? Falls ja, kannst du dir die Verschlüsselung nämlich sparen. Lokale Daten können IMMER ausgelesen werden, da du ja auch das Passwort zum Entschlüsseln wieder in deiner Anwendung hinterlegen musst. Sicher wird es erst dann, wenn das Passwort von Hand eingegeben werden muss (z.b. beim Start der Anwendung).

[KodeZwerg]

Dann sollte PW aber nicht als PW gespeichert sein sondern nur als Hash.

[Zacherl]

Zitat:

Zitat von KodeZwerg (Beitrag 1411236)

Dann sollte PW aber nicht als PW gespeichert sein sondern nur als Hash.

Das funktioniert nicht, da die Datenbank das Passwort ja in Klartext erwartet. Ist aber auch komplett egal ob Plain oder Hash, wenn die gesamten Verbindungsinformationen (inklusive Password) mit einem anderen Passwort verschlüsselt werden, das beim Start der Anwendung manuell vom Benutzer eingegeben werden muss.

[p80286]

Man könnte ja auch einen base64(Hash(Password)) in der DB als Passwort hinterlegen.
Macht es etwas schwerer aber sicher?

Gruß
K-H

[Zacherl]

Zitat:

Zitat von p80286 (Beitrag 1411242)

Man könnte ja auch einen base64(Hash(Password)) in der DB als Passwort hinterlegen.

Nene, es geht ja um das Passwort um die DB-Connection erstmal aufzubauen.

[KodeZwerg]

Mit Hash meinte ich bestimmt was anderes als wie Du gerade.
Ich meinte, Hash in Datei speichern, im Programm, bei PW Abfrage, Hash auslesen, neuen Hash generieren, stimmt der Hash = DB damit füttern. Total simpel, angreifbar ist eh alles.

[Schokohase]

@Kodezwerg

Der TE will die Anwendung starten OHNE das DB-Kennwort vom Benutzer zu erfragen. Im Idealfall soll dem Benutzer das DB-Kennwort gar nicht bekannt sein.

Ein Hash ist in diesem Szenario völlig unsinnig, denn das Kennwort selber wird für die Anmeldung benötigt.

Einen anderen Hash als Hash gibt es nicht - da gibt es also keine Verwechselungsgefahr

@Ykcim

Wenn du das vernünftig bzgl. der Sicherheit umsetzen willst dann brauchst du z.B. eine REST-API. Dann hast du diese ganzen Probleme nicht

[KodeZwerg]

Zitat:

Zitat von Schokohase (Beitrag 1411247)

@Kodezwerg
Der TE will die Anwendung starten OHNE das DB-Kennwort vom Benutzer zu erfragen. Im Idealfall soll dem Benutzer das DB-Kennwort gar nicht bekannt sein.

Korrekt, deswegen schrieb ich ja etwas was keine externen Komponenten benötigt. XOR.

Zitat:

Zitat von Schokohase (Beitrag 1411247)

da gibt es also keine Verwechselungsgefahr

Wenn man Aussagen wahllos miteinander verknüpft schon. Meine Aussage mit Hash galt dem Vorschlag (weder vom TE noch mir) mit der PW Eingabe.

[Ykcim]

Hallo Zusammen,

komme erst jetzt dazu, die Sache wieder aufzunehmen...

Kurz noch ein paar Info's, denn aus den Antworten konnte ich erkennen, dass ich mich nicht klar genug ausgedrückt habe.

Ich habe in der Anwendung eine eigene Benutzerverwaltung mit Rechten, in der der User selber sein Kennwort vergibt. Dieses Kennwort hat nichts mit der DB zu tun, sondern nur mit der Anwendung.
Die Userverwaltungsdaten werden ebenfalls in der DB gespeichert.

Das Kennwort für die DB ist dem User unbekannt und soll auch so bleiben. Ich habe es aber in einer TXT-Datei gespeichert, aus der meine Anwendung es ausliest und die Verbindung zu DB aufbaut.

Mein Programm wird nur von Usern verwendet, die auch einen Zugang haben. Aber wenn ein Unbefugter die TXT-Datei mit den DB-Zugriffsdaten findet, könnte er an meinem Programm vorbei direkt auf die DB zugreifen... Und das möchte ich gerne verhindern

Ich werde Euren Ideen folgen und versuchen, eine gute Lösung zu entwickeln. Bei Fragen / Erfolg melde ich mich wieder.

Vielen Dank
Patrick

[rokli]

Hallo,

das kannst Du dann ja recht einfach mit einem MD5 machen ...

Der User gibt sein PWD ein und Du speicherst den MD5Hash in der INI (oder in der DB Userverwaltung) ...

Delphi-Quellcode:

function f_MD5Hash(sVal : String) : String;
{-------------------------------------------------------------------------------
   f_Md5Hash

      Erzeugt einen MD5 Hash Wert, der nicht zurück gewandelt werden,
      kann aber verglichen.
      Benötigt wird mindestens in der uses: IdHashMessageDigest.
      die Rückgabe ist immer 32 Zeichen lang

      Input:   STRING
      Output:   STRING

-------------------------------------------------------------------------------}
var
   idmd5 : TIdHashMessageDigest5;
begin
   idmd5      := TIdHashMessageDigest5.Create;
   result   := idmd5.HashStringAsHex(sVal);
   idmd5.Free;
end;

Und wenn der User sich wieder anmeldet prüfst Du die Eingabe, in dem Du den INI-Wert gegen den berechneten Wert prüfst. Dadurch bist Du sogar raus, wenn der Benutzer sein PWD vergessen hast, weil auch Du es nicht wiederherstellen kannst. Und wenn der User sich nicht erinnern kann, löscht Du den Hash in der INI (oder DB Userverwaltung) und lässt ihn ein neues eingeben.

Gruß

[Schokohase]

@rokli

Es geht um die Zugangsdaten zur Datenbank, diese sollen dem Benutzer nicht bekannt sein.

Es geht nicht um die Zugangsdaten der Anwendung, die dem Benutzer sehr wohl bekannt sind, weil er diese selber festlegt (und diese sollten in der Datenbank nur als Hash gespeichert werden).

Um die Zugangsdaten der Anwendung aber überprüfen zu können muss es eine Verbindung zur Datenbank geben und dafür eben auch Zugangsdaten und diese sollen aber geheim sein (damit z.B. nicht jeder in der Datenbank herumpfuschen kann).

Dafür (und nur dafür) such der TE eine Lösung.

[Zacherl]

Ich sehe leider keine Möglichkeit, wie man diesen Anwendungsfall unter den gegebenen Bedingungen absichern kann. Ob du die .txt nun verschlüsselst oder nicht, macht im Grunde keinen großen Unterschied. Du "schützt" dich vielleicht gegen Leute, die ausversehen mal einen Blick riskieren, aber wenn jemand wirklich an die Zugangsdaten gelangen will, bringt dir das komplett gar nichts. Wie gesagt, muss deine Anwendung ja auch den Schlüssel kennen, um die .txt vor dem Auslesen wieder entschlüsseln zu können. Dieser Schlüssel landet unweigerlich im Kompilat, weshalb man ihn daraus auch mit ein wenig Aufwand wieder extrahieren kann. Und schon ist der ganze "Schutz" futsch ...

Eine REST-API, wie sie von Schokohase schon vorgeschlagen wurde, hätte dieses Problem nicht. Direkter Zugriff auf die Datenbank ist IMMER unsicher, wenn du dem lokalen Client (Benutzer) nicht vertraust bzw. davon ausgehen kannst, dass deine Anwendung in falsche Hände gelangen könnte.

Selbst wenn du als schnellen Workaround nur die Authentifizierung über ein per SSL gesichertes Web-Interface realisierst und deine Anwendung nach erfolgreichem Login die Datenbank-Zugangsdaten gesendet bekommt, könnte der Nutzer sich immer noch mit einem Debugger dazwischenhängen und die unverschlüsselten Daten abgreifen, bevor deine Anwendung sie an die Datenbank überträgt :?

[Ykcim]

Ja, das stimmt.

Ich habe das hier gefunden.

Delphi-Quellcode:

function XORCrypt(Data, Key: string): string;
var
  KeyLen: INTEGER;
  i: INTEGER;
begin
  KeyLen := Length(Key);
  for i := 1 to Length(Data) do
    Data[i] := Chr(Ord(Data[i]) xor Ord(Key[(i mod KeyLen) + 1]));
  Result := Data;
end;

procedure TForm1.Button1Click(Sender: TObject);
var Res:String;
begin
 Res:=XORCrypt(Edit1.Text,'Kennwort');
 Label1.Caption:=Res;
 Label2.Caption:=XORCrypt(Res,'Kennwort')
end;

Ich glaube verstanden zu haben, dass wenn man längere Texte damit "verschlüsselt", dass die Wiederholungen sichtbar werden. Aber wenn es sich nur um kurze Daten wir IP-Adresse, User, Passwort, Port und Schema handelt, sollte es klappen.

Den Key würde ich zwar fix im QuellCode hinterlegen. Aber wenn jemand sich soviel Mühe macht und den herausfindet, dann wird es eh schwer werden. Neugierige, fortgeschritten User würde ich so wohl fernhalten, ambitionierte Hacker ehe nicht.

Was meint ihr?

Gruß Patrick

[mkinzler]

Zitat:

Ob du die .txt nun verschlüsselst oder nicht, macht im Grunde keinen großen Unterschied.

Auch die meisten (Haus-)Türen sind nicht sicher, trotzdem sollte man diese Abschliessen.
Aus meiner Sicht macht es deshalb schon einen Unterschied ob die Zugangsdaten verschlüsselt oder im Klartext in der Textdatei/Ini/XML/Registry stehen.

[Schokohase]

Es ist ganz einfach:

Ohne eine weitere Schicht (z.B. REST-API) die auf einem anderen System läuft hast du nur Pseudo-Sicherheit. Egal wie die aussieht, egal was du machst.

Das war schon immer so und wird sich auch so schnell nicht ändern.

[KodeZwerg]

Zitat:

Zitat von Ykcim (Beitrag 1411327)

Was meint ihr?

Wie bereits erwähnt, alles ist besser als nichts. Von daher, mach es.
100 Prozent kann man mW eh nicht erreichen. Ob über REST, Datei/Registry oder über Timbuktu per Snailmail, Daten kann man überall irgendwie abgreifen.
XOR Gewährt Dir zumindest minimal Schutz vs unversierte Blicke.

[Schokohase]

100% Schutz gibt es nicht auch nicht bei REST-API.

Allerdings liegt ohne diese physische Zwischenschicht die Sicherheit bei 0%-20% und mit der physischen Zwischenschicht bei 90%-99% (z.B. physischer Einbruch in das Rechenzentrum oder Ausnutzen einer Zero-Day-Lücke und ähnliche Kaliber).

Man muss selbst entscheiden, was ausreichend ist.

[Jumpy]

Und man muss auch überlegen, vor wem man sich schützen will. Ist es z.B. vor der IT-Abteilung des Kunden nützt dir REST usw. auch nix, wenn die Server beim Kunden stehen. Geht es nur um das Fernhalten normaler Mitarbeiter eines Kunden reicht wohl das verschlüsselte Passwort irgendwo und sei es im Quelltext. Geht es darum komplett fremde Leute fern zu halten, muss man hoffen, das der Kunde eine gute Alarmanlage hat...

[KodeZwerg]

Im Kompilat kann das benutzte Passwort für die XOR Methode natürlich auch verschlüsselt ablegt werden, aber egal wie viel Layers man raufpackt, ist es ausführbar ist es angreifbar. Wobei es interessante Schutzproduke gibt die sich auf so was spezialisiert haben Themida zum Beispiel.
Schokohase hat mit REST schon Recht, ein Dongle geht übrigens auch.

[Zacherl]

Zitat:

Zitat von Schokohase (Beitrag 1411330)

Ohne eine weitere Schicht (z.B. REST-API) die auf einem anderen System läuft hast du nur Pseudo-Sicherheit. Egal wie die aussieht, egal was du machst.

Eben dieses.

Zitat:

Zitat von mkinzler (Beitrag 1411329)

Zitat:

Ob du die .txt nun verschlüsselst oder nicht, macht im Grunde keinen großen Unterschied.

Auch die meisten (Haus-)Türen sind nicht sicher, trotzdem sollte man diese Abschliessen.
Aus meiner Sicht macht es deshalb schon einen Unterschied ob die Zugangsdaten verschlüsselt oder im Klartext in der Textdatei/Ini/XML/Registry stehen.

Dein Vergleich hinkt. Passend währe vielleicht die Unterscheidung zwischen nicht-abschließen und abschließen, aber den Schlüssel unter der Fußmatte zu deponieren. Diese Denkweise "besser etwas (was trotzdem effektiv nicht hilft), als gar nichts" ist verdammt gefährlich in der IT. Das schlechte Gewissen ist beruhigt, aber irgendwann kracht es unweigerlich und man hat den Salat.

Zitat:

Zitat von KodeZwerg (Beitrag 1411337)

Wobei es interessante Schutzproduke gibt die sich auf so was spezialisiert haben Themida zum Beispiel.

Hierdurch erschwert man das Reverse Engineering - richtig angewendet - zwar tatsächlich signifikant, aber sicher ist es wie du schon sagst trotzdem nicht (siehe gecrackte Spiele). Never trust the client.

[rokli]

@Schokohase

Zitat:

Zitat von Schokohase (Beitrag 1411324)

@rokli

Es geht um die Zugangsdaten zur Datenbank, diese sollen dem Benutzer nicht bekannt sein.

Es geht nicht um die Zugangsdaten der Anwendung, die dem Benutzer sehr wohl bekannt sind, weil er diese selber festlegt (und diese sollten in der Datenbank nur als Hash gespeichert werden).

Um die Zugangsdaten der Anwendung aber überprüfen zu können muss es eine Verbindung zur Datenbank geben und dafür eben auch Zugangsdaten und diese sollen aber geheim sein (damit z.B. nicht jeder in der Datenbank herumpfuschen kann).

Dafür (und nur dafür) such der TE eine Lösung.

Ich traue dem TE zu, dass er das Verfahren da einsetzt, wo er es verwenden möchte; darum habe ich glaub ich immer INI/DB gleichzeitig genannt.

Zitat:

Zitat von mkinzler (Beitrag 1411329)

... in der Textdatei/Ini/XML/Registry stehen.

Danke @mkinzler

[generic]

Zitat:

Zitat von Schokohase (Beitrag 1411324)

@rokli

Es geht um die Zugangsdaten zur Datenbank, diese sollen dem Benutzer nicht bekannt sein.

Es geht nicht um die Zugangsdaten der Anwendung, die dem Benutzer sehr wohl bekannt sind, weil er diese selber festlegt (und diese sollten in der Datenbank nur als Hash gespeichert werden).

Um die Zugangsdaten der Anwendung aber überprüfen zu können muss es eine Verbindung zur Datenbank geben und dafür eben auch Zugangsdaten und diese sollen aber geheim sein (damit z.B. nicht jeder in der Datenbank herumpfuschen kann).

Ich glaube, ihr habt hier ein Konzept Problem.

Ihr baut euch eine eigene Benutzerverwaltung! Das ist nicht notwendig.

Der Datenbankserver hat bereits eine eingebaut, nutzt die. Damit habt ihr auch nicht das Problem, dass es eine weitere technische Verbindung/Benutzer gibt, die das gesamte Rechtssystem untergräbt.

Bevor jetzt die Diskussion los geht, mit "ich habe aber Köpfe zum Löschen und Bearbeiten in der Oberfläche die sollen aus sein, wenn der Benutzer keine Rechte hat" kann ich nur sagen:
Genau die Datensätze in Tabellen lassen sich auch Rechte abfragen. Wenn ein Benutzer kein "DELETE" auf der Tabelle hat, dann kann man auch den Knopf ausmachen.

Ja, manchmal sind die Datenbankrechte nicht fein genug, dann batch Funktionen welche die BI abbilden und die Tabellen verstecken. Schließlich braucht ein Benutzer nicht zwingend ein "SELECT" Recht auf einer Tabelle, wenn er die Daten auch durch einen View oder Funktion bekommen kann.

[Schokohase]

Zitat:

Zitat von generic (Beitrag 1411513)

Zitat:

Zitat von Schokohase (Beitrag 1411324)

...

Ich glaube, ihr habt hier ein Konzept Problem.

Das Konzept-Problem ist der direkte Zugriff vom Client auf die Datenbank und das in jeder Hinsicht. Zugriffs-Komponenten, Treiber, Zugangsdaten, etc.

Aber wieso wir? Ich habe das Problem nicht ...

[ernschd]

Wie wäre es mit einem Zugriff auf die Datenbank per SSH-Tunnel? Dann könnte die Authentifizierung mittels Schlüsselpaar (Private-/Public-Key) erfolgen.
Wir verwenden beispielsweise für so ein System UniDac mit SecureBridge.

[mkinzler]

Es geht um die Zugangsdaten zur Datenbank. Da hilft ein Tunnel eher nicht. Zudem ist vermutlich/möglicherweise auch die Datenbank jeweils lokal. Auch bei einem ssh-Tunnel benötigt man zudem Zugangsdaten.

Zitat:

Ihr baut euch eine eigene Benutzerverwaltung! Das ist nicht notwendig.

Könnte man natürlich machen.Man macht sich hierbei aber abhängig vom entsprechenden DBMS. U.U. ist hierfür aber wieder ein Benutzer mit (teilw.) Adminrechten notwendig, dessen Zugangsdaten man u.U. in der Exe oder in Datei ablegen muss.

Zitat:

Das Konzept-Problem ist der direkte Zugriff vom Client auf die Datenbank und das in jeder Hinsicht. Zugriffs-Komponenten, Treiber, Zugangsdaten, etc.

Lokale Installationen mit lokaler Datenhaltung nun per sé schlecht? Cloud verpflichtend?

Bisher hatte er die Zuganngsdaten im Klartext(!) in einer Datei hinterlegt. Ein Ablage verschlüsselt wäre deutlich besser/sicherer. Dies abzulehnen, da knackbar finde ich paradox!

[Ykcim]

Hallo Zusammen,

ich muss das Thema noch einmal aufgreifen.

Delphi-Quellcode:

function XORCrypt(Text,Passwort:string):string;
var
   x,y,lg : integer;
begin
   if length(Text)>0 then begin
      y:=1;
      lg:=length(Passwort);
      for x:=1 to length(Text) do begin
         Text[x]:=chr(ord(Text[x]) xor ord(Passwort[y]));
         if y=lg then begin
            y:=1
         end
         else begin
            inc(y);
         end;
      end;
   end;
   Result:=Text;
end;

Das ist die XOR-Verschlüsslungsfunktion.

Aber bei manchen Werten baut sie Mist. Z.B. wenn ich eine IP-Adresse mit 172. klappt das Entschlüsseln nicht mehr.
"17"=1
"1756789456"=1
"2756789456"=2
aber
"22756789456"=22756789456
Die 7 an der zweiten Stelle macht Schwierigkeiten. Ich weiß, aber sicherlich gibt es noch weitere Problemfälle.

Ist das bekannt und wie kann ich damit umgehen?


Vielen Dank
Patrick

[KodeZwerg]

Bist Du nur an einer Reparatur Deiner Methode interessiert oder magst Du auch andere Verfahren per Code demonstriert bekommen?

[Ykcim]

Ich bin auch für andere Verfahren offen.
Allerdings sollten die angemessen sein und einfach implementierbar. Ich benötige für diese Anwendung keine Hochsicherheit und habe auch zu wenig Ahnung davon, als das ich jetzt mal eben auf die Schnelle umgesetzt bekomme... Bislang kam ich ganz ohne aus, aber langsam muss ich mir meine Gedanken machen.

Hoffe, dass ich nachvollziehbar
Patrick

[Schokohase]

Zitat:

Zitat von mkinzler (Beitrag 1411534)

Zitat:

Das Konzept-Problem ist der direkte Zugriff vom Client auf die Datenbank und das in jeder Hinsicht. Zugriffs-Komponenten, Treiber, Zugangsdaten, etc.

Lokale Installationen mit lokaler Datenhaltung nun per sé schlecht? Cloud verpflichtend?

Geht es hier um eine lokale Installation mit lokaler Datenhaltung?

Ich bin davon ausgegangen, dass es mehrere Clients gibt und ein separaten DB-Server. Darauf beziehen sich meine Antworten und darum diese bitte auch in diesem Kontext und keinem anderen Kontext interpretieren.

Und was ist denn jetzt schon wieder mit Cloud? Nur weil REST-API? Die kann man nur in der Cloud haben?

Ja, das kann man Unwissenden evtl. so verkaufen, aber bitte lasst mich dann da raus.

[jobo]

Zitat:

Zitat von Schokohase (Beitrag 1411514)

Das Konzept-Problem ist der direkte Zugriff vom Client auf die Datenbank und das in jeder Hinsicht. Zugriffs-Komponenten, Treiber, Zugangsdaten, etc.

Ich würde da widersprechen und sagen, das ist ganz normal und kein Problem. Es gibt verschiedene Architekturkonzepte, die je nach Anwendungsfall ihre Berechtigung haben und ihre Stärken ausspielen (können).

[ernschd]

Zitat:

Zitat von mkinzler (Beitrag 1411534)

Es geht um die Zugangsdaten zur Datenbank. Da hilft ein Tunnel eher nicht. Zudem ist vermutlich/möglicherweise auch die Datenbank jeweils lokal. Auch bei einem ssh-Tunnel benötigt man zudem Zugangsdaten.

Natürlich, aber mit der Schlüssel-Authentifizierung wird zumindest das Passwort nicht mehr benötigt.
Die übrigen Zugangsdaten könnten dann mit einer XOR-Verschlüsselung hinterlegt werden.

[Ykcim]

Also die Daten liegen auf einem MySQL DB Server, der nur innerhalb des Unternehmen erreichbar ist.
Innerhalb des Unternehmens greifen mehrere User auf das Programm und damit auch auf die Daten zu.

Heute ist es noch so, dass ich das Programm ebenfalls auf einen Server lege und die User eine Verknüpfung auf ihren Rechnern zu diesem Programm haben...

Ich möchte die Zugriffsdaten einfach nicht mehr im Klartext da stehen haben...

Vielen Dank für die rege Diskussion und Hilfestellung!
Patrick

[KodeZwerg]

Anhang 49820
Schau mal ob dir dieses Projekt weiterhelfen kann.