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 :-D

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 :thuimb:
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:

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

[negaH]

Sorry ich sehe gerade das da ein Fehler drinnen ist.

Zitat:

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) !

Dies ist natürlich schwachsinnig, da ja Ph = H(p) und Pd = C(D, Ph) beide in der User-DB gespeichert sind wird es nun einfach für den Angreifer das D zu berechnen. Denn das Passwort Ph zur Entschlüsselung D = E(Pd, Ph) wird dem Angreifer der die User-DB lesen kann gleich frei Haus geliefert. Man muß dies absolut vermeiden und es sollte so aussehen:

In User-DB stehen U,Pv=H(P),s,Pd=C(D, H(s + P))
wobei
U = Username
Pv = H(P) = Passwordverifier zur Überprüfung des Passwortes
s = ein Zufallssalt, sprich z.b. 20 Bytes Zufallszahlen
Pd = C(D, H(s + P)), das verschlüsselte Data-DB Passwort D das mit H(Salt + Password) verschlüsselt wurde.

Diese sehr einfache Verfahren ermöglicht aber trotzdem bestimmte Angriffe. Um diese zu elimieren muß man dann schon echte mathematische "Public Key" Verfahren benutzen.

Gruß hagen

[czapie]

@Peter Lustig

Ist absolut richtig, gerade bei einer so "bekannten" Variante, wo ich weiß, dass dort irgendwo das password steckt, ist eine Veränderung tödlich
Mit Veränderung mache ich dan aben ein paar Hundert durchläufe und gucke was immer gleich geblieben, ist dann dauerts nicht mehr lange bis ich das PW habe.

Czapie.

[Jelly]

Hi,

aus all dem was ich bis jetzt gelesen hab, werd ich, um einen sichere Lösung zu finden, nicht um ein asymetrisches Verfahren kommen. Das ist aber sicherlich überdimensioniert für mein Problem.

Mir ist die Lösung von Hagen zwar ganz klar, und ist auch umsetzbar. Aber sie hat die gleich Sicherheitslücke, die eben nicht zu umgehen ist, nämlich irgendwo im Quelltext oder sonstwo muss ein unverschlüsseltes Passwort verankert sein. Bei Hagens Lösung ist dies das Passwort für die DB_User Datenbank.

Aber vielen Dank für die Anregung,

Gruss,
Tom

[negaH]

Zitat:

Mir ist die Lösung von Hagen zwar ganz klar, und ist auch umsetzbar. Aber sie hat die gleich Sicherheitslücke, die eben nicht zu umgehen ist, nämlich irgendwo im Quelltext oder sonstwo muss ein unverschlüsseltes Passwort verankert sein. Bei Hagens Lösung ist dies das Passwort für die DB_User Datenbank

Dies ist aber nur die leichter knackbare Hürde und bestimmt nicht die Sicherheit meines Vorschlages. Rein theoretisch könnte man die User_DB auch ungeschützt lassen, sie darf eben für normale User nur ReadOnly sein.

Wichtig an meinem Vorschlag ist es das der gültige Benutzer über seinen Benutzernamen und Passwort Zugriff auf die geschützte Daten_DB erlangt. Nur berechtigte Benutzer können diese DB öffenen.
Somit ist die Daten_DB sicher, und kann nur für berechtigte Benutzer mit korrektem Passwort geöffnet werden.

Gruß Hagen

[nailor]

um ein passwort zu verstecken: sehr sicher ist z.b. hardcoden mit nachträglicher bearbeitung. mach ne funktion, die als result das korrekt passwort liefert. dort speicherst du die ascii-codes des passwortes ab (eventuell noch ascii * 3, beim entschlüsseln dann durch 3), der dann in den string umgewandelt wird. strings werden "offensichtlich" in der exe hinterlegt, irgendwelche byte-variablen-arrays nicht... pass auf, dass die codeoptimierung die funktion nicht optimiert! so kommt man ohne abartigen disassembler-gebrauch nicht an das passwort.

Michael

PS: wenn jemand den traffic mitprotokolliert, könnte man das pw dort abfangen ?!?!

[Jelly]

Wegen des Traffic mach ich mir keine Sorgen. Die Mühe lohnt sich nicht denk ich.

Gruss,
Tom

[ExZtEd]

Entschuldigung das ich den Thread wieder ausgrabe, aber ich stehe genau vor demselben Problem der Datenverschlüsslung für den Zugriff auf eine DB.
In meinem Fall muss der Zugriff auf die DB sicher sein, da eine große Menge an User darauf zugreifen sollen.

Die Vorschläge hier sind auch von der Sicherheit auf "Datei-Ebene" passabel, aber wie schaut es zur Laufzeit aus?
Während die Anwenung läuft wird ständig das DB-Passowort benötigt und liegt demzufole in einer VAR.
Bei einem Speicherabbild würde dieses dann doch wider UNVERSCHLÜSSELT sein!?

Der Delphi-Komponente die für die Datenbankverbindung benötigt wird, muss ja das Passwort unverschlüsselt übermittelt werden zur Laufzeit.
Wie kann gewährleistet werden das jenes Passwort auch zur Laufzeit noch sicher ist?

Oder sehe ich vor lauter Paranoidität, die vogeschlagene Sicherheit nicht?

[nailor]

wie negah schon gesagt hat: entweder du baust eine weitere ebene (den login-server ein), oder du musst mit der tatsache leben, dass das passwort irgendwann mal lokal verfügbar sein muss. (wenn auch nur zur laufzeit im speicher).

[supermuckl]

ich will ja nix sagen.. aber vor lauter password verschlüsselung.. ist euch schonmal in den sinn gekommen das man das password im klartext über einen packetsniffer lesen kann ?

wenn dann müsste man halt das ganze ding in eine sichere kapselung packen die dann so sicher ist das auch z.b. public key verfahren eingesetzt werden

oder einfach nur IPsec/VPN ^^

wobei das dann nur für "hacker" abschreckend wirkt und die user die mit der db arbeiten immernoch sniffen können....

[nailor]

ja, wurde schon erwähnt, dass das geht

[Florian H]

Also ich löse das immmer über ein simples PHP-Script auf dem Server, was dann wie ne Art Filter ist, da da ja nur ganz bestimmte Befehle möglich sind.
Das heißt niemand kann viel kaputtmachen (löschen oder so) und ans PW kommt auch keiner.
Zusätzlich kann ich bestimmte Sachen/user nachträglich sperren...

[Jelly]

Zitat:

Zitat von ExZtEd

Entschuldigung das ich den Thread wieder ausgrabe, aber ich stehe genau vor demselben Problem der Datenverschlüsslung für den Zugriff auf eine DB.
In meinem Fall muss der Zugriff auf die DB sicher sein, da eine große Menge an User darauf zugreifen sollen.

Hallo,

was für eine Datenbank nutzt du denn. By MySQL kannst du z.B. den Zugriff auf bestimmte IP Adresse limitieren. Bei MSSQL besteht meines Wissens gleich ne Möglichkeit, die ganze Datenbankberbindung zu verschlüsseln.

Gruß,
Tom

[Meflin]

könnte man vermutlich (z.b. mit etheral)
[edit]da war ich ja mal wieder ganz schnell :roll: [/edit]

[ExZtEd]

@ Jelly:
Es ist eine MySql-Datenbank.
Der Zugriff ist von allen Hosts und IPs möglich, da es eine Anwendung (Online-Spiel) werden soll, die allen den Zugriff auf eine zentrale MySql-Datenbank gewährleisten muss.

@ Florian H.:
Verstehe nicht ganz, wie die Delphi-Anwendung über PHP mit der Datenbank kommunizieren soll !?
PHP und Datenbank ist klar, wäre dann ja ein Browsergame in meinem Fall (soll aber ein Client-Game sein).

@ nailor:
Könnte mir vieleicht wer das SRP näher erklären?
Mir erschließt sich nämlich nicht, inwiefern Delphi über dieses Protokoll auf die Datenbank zugreifen soll, da die Delphi-Komponenten (ZEOS-Libs) ja niemals das Passwort zu gesicht bekommen um eine Verbindung zur Datenbank aufbauen zu können.

Insgesamt fällt mir nur die Möglichkeit ein zusätzlich zum Client noch eine Server-Anwendung zu schreiben mit der der Client verbindung aufnimmt und darüber die Kommunikation abwickelt.
Nur scheitert es dort an der Möglichkeit, dass die Server-Anwendung zur gleichen Zeit mehrere Verbindungen bearbeiten können muss.

Im voraus schonmal:
Über alle Arten von Tips und Hilfen bin ich euch allen sehr dankbar.