DB-Zugangsdaten verschlüsseln

[Zacherl]

Zitat von mkinzler:

Ein Ablage verschlüsselt wäre deutlich besser/sicherer. Dies abzulehnen, da knackbar finde ich paradox!

Es ist eben NICHT sicherer, das ist doch grade das Problem. Diese "Sicherheit" ist ein Trugschluss. Als Analogie kannst du dir einmal deine offene Tür vorstellen und einmal eine verschlossene Tür, bei der der Schlüssel in einem offenen Safe davorliegt. Die Datei zu verschlüsseln, aber den Key in der Anwendung zu hinterlegen ist das klassische "security through obscurity" (Verschleierungs-)Prinzip, was nicht umsonst in der IT-Security eins der verpöntesten Prinzipien überhaupt ist

Zitat von ernschd:

Natürlich, aber mit der Schlüssel-Authentifizierung wird zumindest das Passwort nicht mehr benötigt.

Hier hast du doch das gleiche Problem. Ob nun jemand die Zugangsdaten unberechtigterweise klaut/anwendet, oder eben den Schlüssel ... Resultat ist das selbe: Unberechtigter Datenbankzugriff.

Zitat von Ykcim:

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

Das müssen wir wohl akzeptieren. Dann hoffe ich mal für dich, dass dir das nicht irgendwann auf den Kopf fällt.

[FrankR]

Zitat von 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

Ich schließe mich mal an:

Wenn du unbedarfte Benutzer, bzw. Möchtegern-Hacker abhalten willst die Zugangsdaten sofort zu sehen: Verschlüssele die Txt-Datei und lege den Schlüssel in den Quelltext
Cracker oder zumindest Leute, die wissen wie man mit einem Debugger/Decompiler umgeht, werden das Spiel aber schnell durchschauen und können die Zugangsdaten mit ein bisschen Erfahrung auslesen.

Es liegt an dir zu entscheiden, auf was du mit Kanonen schießen willst. Aber bei Programmen im Netzwerk reicht es völlig aus, die Zugangsdaten im Quelltext zu lassen. Stell dir einfach die Frage, was die Leute mit den Zugangsdaten anstellen könnten/wollen. Begrenze halt die Rechte der Zugangsdaten auf bestimmte Tabellen/Views/Procedures und gut ist. Wenn du hypervorsichtig sein willst, protokollierst du jede Aktivität und schreibst einen WatchDog.

Aber wie gesagt:
Gerade letzteres lohnt sich in der Regel nicht...bleib dann lieber beim geringeren Übel: Verschlüsseln der Txt-Datei und das Ablegen des Schlüssels in der Anwendung.


*edit*
Ich sehe garade: Aber dann ist es auch egal ob du die Zugangsdaten oder den Schlüssel für die Txt-Datei in der Anwendung hast. Beides gleich unsicher...hält aber halt die erstgenannte Kategorie an Benutzern ab.

[Luckie]

Bitte mach für ein neues Problem auch einen neuen Thread mitbeinem aussagekräftigen Titel auf.

[KodeZwerg]

Zu meinem Beispiel noch ein PS:
Wenn Du Probleme mit dem Output haben solltest, bei XOR und Typ String bietet es sich immer an mit Base64-Enc/Dec zu arbeiten.
Also Original String kodieren -> Base64Enc(String) -> Das ist Dein Result zum speichern.
Andersrum, Datei Laden -> Base64Dec(String) -> String dekodieren -> nun hast Du wieder das Original.

Alternativ (so gehe ich meist vor) den Typ auf Binär umstellen (TBytes zum Beispiel) und das speichern/laden auch Binär zu erledigen.
Als Ersatz zum .ini Vorschlag den jemand genannt hatte.
Binär kann man auch Records speichern/laden um auf ein ähnliches Resultat wie .ini zu kommen.

[Schokohase]

Zitat von KodeZwerg:

Als Ersatz zum .ini Vorschlag den jemand genannt hatte.

ini braucht keinen Ersatz für binäre Daten
System.IniFiles.TCustomIniFile.ReadBinaryStream
System.IniFiles.TCustomIniFile.WriteBinaryStream
(da ist der Base64-Kram schon eingebaut)

[KodeZwerg]

Ja, und jeder der Notepad hat kann sehen wie man was benennt um es noch einfacher zu haben beim rekonstruieren.

Am besten noch so:

Code:

[Security Option]
DataBasePassWord=

So etwas kann einem im reinen binär Modus nicht passieren, darauf wollte ich hinaus, nicht das ein ablegen solcher Daten nicht Möglich sei.

edit
Und um der Binär Datei noch ein wenig mehr Sicherheit zu geben, erstellt man sich ein paar Fake Records mit was auch immer für Daten, man selbst weiß ja wie die Binär Datei aufgebaut ist, Änfänger im Bereich Reversing eben nicht.

[generic]

Ykcim du möchstest doch verhindern, dass ein Benutzer die Datenbankverbindung nicht raus bekommt - also Server, Benutzer und Passwort - Richtig?

Es ist völlig egal, wie du die Zugangsdaten schützt. Wenn Sie lokal gespeichert sind, kann drauf zugegriffen werden. Wenn du sie verschlüsselst, können sie trotzdem lokal entschlüsselt werden. Sonst könnte dein Programm ja niemals eine Verbindung aufbauen können.

D.h. mit der Verschlüsselung schließt du nur ein DAU aus. Findige Benutzer, werden trotzdem die Verbindung finden und könnten diese direkt mit Heidi oder ähnlichen nutzen.

Wenn du keinen Schutz auf Serverebene/Tabellen hast, dann hat auch der Benutzer keine Einschränkung.

Sicher wäre, wenn die Prüfung/Login nur auf einen geschützten System erfolgt, z.B. der Datenbankserver im verschlossenen Rack.

Besser wäre doch:
Der Benutzer ist dem Server bekannt und gibt z.B. die Windowsanmeldung durch.

[Uwe Raabe]

Zitat von Ykcim:

Das ist die XOR-Verschlüsslungsfunktion.

Aber bei manchen Werten baut sie Mist.

Das liegt daran, daß man Unicode-Strings nicht einfach per XOR ver- und entschlüsseln kann. Das mag in früheren Delphi Versionen noch funktioniert haben, als ein Char noch ein Byte groß war und der OEM-Zeichensatz zu jedem Byte ein Zeichen kannte. Mit Unicode gilt das aber nicht mehr und man sollte dann auf Byte-Sequenzen für das Crypting ausweichen. Um weiterhin mit Strings arbeiten zu können, weil die Datentypen nun mal nicht so einfach im gesamten Programm umgestellt werden können, kann man die Byte-Sequenzen z.B. per Base64 encoden. Der String wird dabei aber etwas länger.

Delphi-Quellcode:

uses
  System.SysUtils, System.NetEncoding;

function Decrypt(const Source, Password: string): string;
var
  bPassword: TBytes;
  bSource: TBytes;
  I: Integer;
begin
  Result := '';
  bSource := TNetEncoding.Base64.DecodeStringToBytes(Source);
  bPassword := TEncoding.UTF8.GetBytes(Password);
  for I := 0 to Length(bSource) - 1 do begin
    bSource[I] := bSource[I] xor bPassword[I mod Length(bPassword)];
  end;
  result := TEncoding.UTF8.GetString(bSource);
end;

function Encrypt(const Source, Password: string): string;
var
  bPassword: TBytes;
  bSource: TBytes;
  I: Integer;
begin
  Result := '';
  bSource := TEncoding.UTF8.GetBytes(Source);
  bPassword := TEncoding.UTF8.GetBytes(Password);
  for I := 0 to Length(bSource) - 1 do begin
    bSource[I] := bSource[I] xor bPassword[I mod Length(bPassword)];
  end;
  result := TNetEncoding.Base64.EncodeBytesToString(bSource);
end;

[KodeZwerg]

Ich habe gerade mal mein Demo mit Unicode gefüttert, funktioniert bei mir Problemlos, bei Euch auch? (wegen Hinweis von Uwe mit älteren Delphis, was meines definitiv ist [D2009])

[Uwe Raabe]

Zitat von KodeZwerg:

Ich habe gerade mal mein Demo mit Unicode gefüttert, funktioniert bei mir Problemlos, bei Euch auch? (wegen Hinweis von Uwe mit älteren Delphis, was meines definitiv ist [D2009])

Das Nicht-Auftreten eines Fehlers ist allerdings kein Garant für Fehlerfreiheit. Probier mal als Password -134775814 und als Orginal String Hurz

Edit: Der Trick hierbei ist, ein #0 zu provozieren. Das wird dann beim Schreiben in das Edit als Stringbegrenzer betrachtet. Würde man nur mit Delphi-Strings arbeiten, dann tritt zumindest dieser Fehler nicht auf. Es könnte aber immer noch Probleme im Unicode-Bereich der Surrogates geben.