Geheime Daten einbinden

[Jelly]

Hi,
ich hätt da mal gern ein Problem

Ich muss irgendwo, in einer ini-Datei am liebsten, einen Wert hinterlegen. Es handelt sich dabei um ein Passwort auf einen MySQL Server. Diesen Wert will ich natürlich nicht im Klartext hinterlegen. Also verschlüssel ich ihn, im Moment benutze ich Blowfish... Nur hab ich dabei so meine Bedenken. Um den Wert zu verschlüsseln mittels Blowfish oder einem anderem symetrischen Verschlüsselungsverfahren, brauch ich selbst ja auch ein Passphrase. Diesen Passphrase hab ich im Moment fest im Quellcode intergriert, also so leicht zu knacken wie das Türschloss von meinem alten Kadett

Ich hab so das Gefühl, daß das so ein grundsetzliches Problem der Datenverschlüsselung ist, oder ich sitz einfach nur auf dem berühmten Schlauch. Vielleicht weiss ja einer von Euch Rat.

Danke,
Tom

[Luckie]

Nimm eine Einweg-Verschlüsselung MD5 oder so was. Und zum Verglöeichen verschlüsselst du die Eingabe und vergleichst sie mit dem hinterlegten Passwort.

[Jelly]

Hi Luckie,

das Problem bei deinem Vorschlag ist aber, daß der Benutzer das MySQL Passwort jedoch nicht weiss, und solls auch nicht kennen. Daher wird die Datenbankanbindung auch im Hintergrund stattfinden. Und deshalb brauch ich schon ne Möglichkeit aus dem verschlüsselten Text den Klartext wieder zu finden und diesen dann an die Datenbank zu setzen.

Gruss,
Tom

[akira1983]

md5 oder ein vergleichbarer hash ist dafür bestens geeignet besonders für wichtige daten wie mysql-passwörter...


andernfalls empfehle ich folgendes:
erstelle doch eine sinnlose datei sagen wir mal namens daten.muell in der in etwa folgendes drin ist

ghuahuh4er7vfgaerfgc4ahtnca74zfv7ah4bnfuahfudhbnfu 4haf67vr7gh4uia
vahuh4u5ithfasy7z4hgcthui3ahnfjdnv7sv87rezt74hyfue vhydsjthnj43nwk
4h5hu4hrz66hrt4najknm,sdnsduvhjyudvzdsy7zv7z43uvzi4zfgu4iu4
f3z7z47zvzzuvhjw34tngjkngkjanygkjldahtjk4h5jkh43jl hqjkdhjkfsauigf
tbh3wltfghuaysgfhk5h4wlthzuas3hwtilusaht4uh5jk4h35 jkw3h5jtgnah7e6
6hzu3whtiurheg7a8etz3uawh4ra743zthruawihfdhgalshdf gnj4nfajk4nwr06


die beiden fettmarkieten stellen sind die einzigsten nutzdaten in dieser datei
06 ist dabei die länge des passwortes
z66hrt das passwort ansich, welches du natürlich auch in den ganzen string splitten kannst.
zusammenfügen würde ich das pwd dann über copy...


gw3zaewerirhguefrhguihuihi4hasfjkanwirdhrthdennfguaihfgiuh43uithfiu4hagfiuhiinhi34
fzso4geinemfuzdurcheinanderbthjbwiebewrbfjewbfehier4rzageeinewazpasswortfjgw4r4jzg
fgzqgzuagehsjgrerwartenagzfgdjshagfsjgdsdhrjghjqgrhjg3wqrhjgsdfvzusagzvad zuagdszvg
faerst43fgzj4gfz43trechtst6vvd76va786fv37wennuiz3uirzqui23zruiq32oesz32wie23iuzrqiu
vhiervuhfuhcgueyscp6ly8x6c7qi24ivzciatt7i4aw7rirvherazshtzehgvjk4h35ist43jkrhkjhfj

[Jelly]

Danke Akira,

das ist zwar kein Fort Knox, aber reicht für meinen Fall vollkommen aus. Irgendsowas in der Art hab ich gesucht.
Werds noch bischen anpassen, und dann wirds schon klappen.

Vielen Dank also
Tom

[negaH]

Zitat:

Ich hab so das Gefühl, daß das so ein grundsetzliches Problem der Datenverschlüsselung ist, oder ich sitz einfach nur auf dem berühmten Schlauch. Vielleicht weiss ja einer von Euch Rat.

Dein Gefühl ist absolut richtig, es kann in einem solchen Falle keine Sicherheit geben.
Alles was du machen kannst ist es diesen Wert zu verstecken !
Alternativ wäre nur eine Serverbasiertes Login. D.h. dein Software hat ja die Datenbank auf einem Server installiert. Parallel dazu benötigst du einen Software die auf diesem Server läuft. Der Server selber ist einbruchssicher. Nun kann die Clientsoftware eine sicherers Protokoll benutzen damit sie sich auf dem Server einloggen kann. Der Server wiederum connected den Clienten zur SQL Datenbank. D.h. das SQL Passwort steht nur noch auf dem Server, und dieser ist einbruchssicher. Als Login Protokoll kämen dann zB. SRP=Secure Remote Password oder PK's = Public Keys zu Anwendung.

Mal abgesehen davon, wäre auch das Hash-basierte Login nicht wesentlich sicherer. Der User ersetzt einfach den Fingerabdruck in der INI Datei durch einen selber produzierten von seinem eigenen Passwort. Sofort danach hat er Zugriff mit seinem eigenen Passwort.

Gruß Hagen

[akira1983]

sicherheit ist, wenn man selber meint, es sei sicher...

die meisten alten programme auf win 3.x basis haben danach gearbeitet...

und diese methode ist bist heute noch ganz passabel...
am besten ist es sogar, wenn das programm bei jedem .terminate
die datei immer wieder verändert...

[Christian S.]

Zitat:

am besten ist es sogar, wenn das programm bei jedem .terminate
die datei immer wieder verändert...

Könnte man dann nicht die einzelnen Dateien vergleichen und schauen, was gleich bleibt? Dann hätte man doch das Passwort. Wäre es da nicht sinnvoller, die Datei nicht zu ändern?

[Jelly]

Zitat von negaH:

Dein Gefühl ist absolut richtig

Dann bin ich zumindest was mein Verständnis angeht beruhigt... Dann werd ich das Passwort halt irgendwo verstecken... Im Normalfall, würd das Ganze nur auf meinem lokalem MySQL Server laufen, würd ich einfach jedem User einen Account vergeben, damit hätts sich. Da die Datenbank aber bei meinem Provider liegt, hab ich selbst nur ein Account und kann mir keine eigenen erstellen
Wenn ich dann also mein Programm als Shareware rausgeben will, dann muss halt jeder selbst kucken, wo er seine MySQL Datenbank hinlegt. Wird dann nur ein Problem werden, da die meisten Provider den Zugriff auf ihre MySQL Datenbanken von aussen her total abschotten.

Danke für die vielen Antworten,
Tom

[negaH]

@Jelly, wenn dies so ist dann hast du schon einen guten Ansatzpunkt. Denn die Datenbank IST als sicher einzustufen. Dies ist gut denn nun kannst du auf Grund dieser Annahme darauf deine Sicherheit aufbauen.

Also: auf dem Server liegen zwei SQL Datenbanken mit unterschiedlichem Passwort geschützt. Die eine DB nennen wir mal User-DB und die andere Daten-DB.

In der User-DB stehen alle registrierten Benutzer U, deren gehashtes Password Ph = H(P), und das mit diesem gehashten Ph verschlüsselte Passwort für Daten-DB -> Pd = C(D, Ph) !

Beim Login muß der User seinen Name und Password P eingeben. Deine Anwendung greift mit Passwort User-DB auf die User-DB zu. Dieses Passwort steht hardcoded in deiner Anwendung und muß irgendwie schwer zu finden sein. Nun berechnet deine Anwendung Ph = H(P) und vergleicht es mit dem in der User-DB gespeicherten Werten zum User U. Falls es korrekt ist wird Ph als Schlüssel benutzt um D = E(Pd, Ph) zu berechnen. D ist das Passwort zum Zugriff auf die Daten-DB. H() ist eine Hashfunktion, C() eine Verschlüsselungsfunktion und E() die passende Entschlüsselungsfunktion. Nur mit richtigem Passwort P kann also der Schlüssel D berechnet werden. Die User-DB sollte mit unterschiedlichen Zugriffsrechten versehen werden, d.h. nur der Administrator kann Datensätze ändern, anlegen und löschen. Der Administrator selber kann in dieser user-DB gespeichert werden. Aber statt Passwort D wie die anderen User hat er ein eigenes Passwort A das diese Zugriffsrechte in der SQL bekommen hat. Somit ist selbst wenn ein Angreifer auf die User-DB zugreifen kann sichergestellt das er
1.) nicht auf die Daten-DB zugreifen kann
2.) nicht die User-DB ändern kann

Solltest du Kontrolle über die auf dem Server lauffähige Software haben dann könntest du natürlich auch viel sicherer Protokolle verwenden, z.B. SRP. Dies würde es absolut sicher machen, da SRP z.B. auf die Abwehr aller heutigen Angriffe konstruiert wurde. Allerdings SRP benötigt math. Funktionen wie in Public Key Verfahren üblich.

Aber eines dürfte klar sein, jeder Benutzer der Datenbank muß sich per Login mit seinem registrierten Passwort anmelden. Dieses Passwort des Benutzers MUSS in dessen Kopf gespeichert werden. Es sein denn am Clientrechner existiert zusätzliche Hardware wie SmartCards oder USB-Crypto-Tokens. Dann würde der Firmeneigner diese Schlüsselhardware an seine Mitarbeiter verteilen.

Gruß Hagen