![]() |
Geheime Daten einbinden
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 |
Re: Geheime Daten einbinden
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.
|
Re: Geheime Daten einbinden
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 |
Re: Geheime Daten einbinden
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 |
Re: Geheime Daten einbinden
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 |
Re: Geheime Daten einbinden
Zitat:
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 |
Re: Geheime Daten einbinden
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... |
Re: Geheime Daten einbinden
Zitat:
|
Re: Geheime Daten einbinden
Zitat:
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 |
Re: Geheime Daten einbinden
@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 |
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:52 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz