MySQL Passwort vor Dritten schützen?
lima-city → Forum → Programmiersprachen → Programmieren mit .NET & Mono
abfangen
adresse
anfrage
angreifer
auslese
benutzer
code
datenbank
datum
frage
info
interface
minute
problem
programm
server
service
session
url
verbindung
-
Da ich derzeit an einer C# Anwendung programmiere, die unter anderem auch eine Verbindung zu einer MySQL Datenbank bereitstellt, stellt sich mir nun das Problem, dass ich nicht weiß, wie ich das Passwort für diese Verbindung am besten hinterlegen soll.
Es gibt ja genug Decryptoren, die den Bytecode in Quellcode zurück kompilieren und hier stoße ich halt bei jeder Methode, die mir so durch den Kopf geht, auf diverse Probleme.
Ich habe nun mehr oder minder sinnvolle Vorschläge in einigen Foren erhalten....also stelle ich die Frage auch nochmal hier.
Ich weiß natürlich, dass es keine vollkommen sichere Methode gibt, das Passwort vor geübten Reverse Engineerern zu schützen....ich suchen nur die kreativste Möglichkeit, es ihnen so schwer wie möglich zu machen.
Dabei reicht es mir schon, wenn sich nur der Aufwand nich lohnt.
Folgende Lösungsvorschläge wurden mir bereits gemacht:
- Hinterleg das Passwort in einer Textdatei.
Jupiiieeeee. \o/
- Hinterleg das Passwort im Quellcode, den bekommt nie einer entschlüsselt.
.... -.-
- Hinterleg das Passwort als MD5 Hash im Quellcode.
Toll, und was hindert einen daran, dann einfach den MD5 Hash als Passwort an den Server zu schicken?
Der nächste Vorschlag war dann, nicht den MD5 Hash zu schicken, sondern ihn vor dem schicken wieder zu entschlüsseln....das wurde dann so dementiert, dass man einen MD5 Hash nicht entschlüsseln kann und diese Methode daher absolut sicher ist....ihr erkennt die Ironie?
- Hinterleg das Passwort in der App.config Datei.
Dann schaut man eben im Quellcode nach, von wo das Programm das Passwort bezieht....und guckt dann eben in die App.config.
- Hinterleg das Passwort in der App.config verschlüsselt, und entschlüssle es erst im Programm.
Was hindert einen daran, die Methode, mit der entschlüsselt wird, aus dem Quellcode auszulesen und einfach auch auf das Passwort anzuwenden?
- Leite die Anfrage nicht direkt an den Server, sondern schreibe ein PHP Script, dass Dein Passwort mit einer dem Angreifer unbekannten Verschlüsselung an den Server weiterleitet.
Und was hindert einen Angreifer daran, einfach das selbe Script aufzurufen?
Er muss die Art der Verschlüsselung doch nicht kennen, wenn die Entschlüsselung eh das Script übernimmt.
- Ändere das Passwort und die Verschlüsselung am Server alle 60 Sekunden und schreib ein Script, dass dann dem Programm mitteilt, welche Verschlüsselung und welches Passwort gerade verwendet wird.
Selbes Problem....was hindert Jemanden daran, einfach das selbe Script auszuführen und sich vom Server das Passwort und die Verschlüsselungsart geben zu lassen?
Wie ihr seht, stecke ich da ziemlich in der Klemme.
Ich bin mit meinem Latein am Ende und es kommen auch keine Vorschläge, zu denen ich nicht sofort ein Dementi einzuwenden hätte.
Musste sich schon einer von Euch mit diesem Problem beschäftigen?
Irgendwelche "Best Case" Lösungen? -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
Frage das Passwort bei jedem Programmstart ab. Du darfst dann die Anwendung und das Passwort natürlich auch nur an vertrauenswürdige Personen geben.
Beitrag zuletzt geändert: 15.5.2012 8:55:59 von harrybotter -
Du darfst dann die Anwendung und das Passwort natürlich auch nur an vertrauenswürdige Personen geben.
Würde ich das Programm nur an vertrauenswürdige Personen weitergeben wollen, hätte ich jetzt dieses Problem nicht, oder? o.O
Das Programm wird veröffentlicht.
Beitrag zuletzt geändert: 15.5.2012 8:59:09 von adelwoehrer -
liegt die Datenbank online oder lokal?
wenn sie lokal liegt kannst du mal rein gar ncihts machen, um das sicher zu bekommen...
online baust du dir einfach deine schnittstelle...
und da wir nicht wissen, inwieweit Zugriff auf die datenbank erfolgen soll, wärs besser, die info noch nachzuliefern... sonst kommt hier in dem thread nix sinnvolles bei raus... -
Die Datenbank liegt online, ja.
Das Programm läuft lokal und soll Daten in diese Online-Datenbank eintragen.
Die Zugangsdaten, die das Programm dazu verwendet, sollen aber nicht auszulesen sein, darum gehts ganz grob. -
adelwoehrer schrieb:
- Leite die Anfrage nicht direkt an den Server, sondern schreibe ein PHP Script, dass Dein Passwort mit einer dem Angreifer unbekannten Verschlüsselung an den Server weiterleitet.
Und was hindert einen Angreifer daran, einfach das selbe Script aufzurufen?
Er muss die Art der Verschlüsselung doch nicht kennen, wenn die Entschlüsselung eh das Script übernimmt.
Das ist meiner Meinung nach der Weg den du gehen solltest. Wichtig ist dabei nur, dass du nicht die rohen SQL Anfragen an dein Script schickst, sondern das Script selbst sich abhängig von bestimmten Parametern mit denen es aufgerufen wird die SQL Anfragen selbst zusammenbaut. Damit kann zwar immernoch jeder dieses Script aufrufen und bekommt Ergebnisse, aber halt nur für vordefinierte, von dir bestimmte Anfragen. Ein DROP TABLES geht dann (wenn du sauber programmiert hast) nicht mehr. Damit solltest du doch auf der sicheren Seite sein und wenn jemand einen angepassten Client schreiben will, welcher für seine Zwecke besser geeignet ist als dein ursprüngliches Programm, so kann er es auch machen. -
Ein DROP TABLES geht dann (wenn du sauber programmiert hast) nicht mehr.
Ein DROP TABLES wäre hier eigentlich egal, da die Daten nur temporär für die Zeit ihrer Verarbeitung gespeichert und dann wieder gelöscht werden.
Ein Datensatz liegt also ca. 15 Minuten am Server.
Datenverlust würde ich besser verkraften, als das Auslesen dieser Daten von Dritten.
SELECT Anfragen dürfen daher nur an das Programm weitergeleitet werden und sind mein Hauptproblem.
Beitrag zuletzt geändert: 15.5.2012 9:34:01 von adelwoehrer -
Hey
Eigentlich muss man dein Programm nichtmal dekompilieren, denn Strings kann man meist auch aus dem Hex-Editor auslesen. So kann man auch mit sehr sehr sehr viel Glück ans Passwort kommen (find mal den richtigen String, des dauert ewig).
Am besten wäre, wie schon genannt, die Lösung eine Serverseitige Validierung von Anfragen zu übernehmen. Dies kannst du entweder in PHP machen, oder du schreibst einen Server, welcher über ein selbst definiertes Protokoll dann gewisse Dinge abfragen kann. Diese Lösung fände ich am besten und sichersten
Liebe Grüße -
adelwoehrer schrieb:
Ein DROP TABLES geht dann (wenn du sauber programmiert hast) nicht mehr.
Ein DROP TABLES wäre hier eigentlich egal, da die Daten nur temporär für die Zeit ihrer Verarbeitung gespeichert und dann wieder gelöscht werden.
Ein Datensatz liegt also ca. 15 Minuten am Server.
Datenverlust würde ich besser verkraften, als das Auslesen dieser Daten von Dritten.
SELECT Anfragen dürfen daher nur an das Programm weitergeleitet werden und sind mein Hauptproblem.
Aber es können sich ja auch dritte einfach dein Programm kopieren und beliebige Daten eintragen, einen funktionierenden Kopierschutz gibt es ja, wie wir wissen nicht. Und es ist doch auch egal ob die Daten ursprünglich aus deinem Programm kommen oder von einem anderen Client. Wenn es dir um so Sachen wie Input Validierung geht, ist dass dann halt auch Aufgabe deines Scripts und nicht der Client Anwendung.
Alternativ: Falls du Kontrolle über den MySQL Server hast (und nicht z.b. den von Lima verwendest) könntest du für jede Person die dein Programm benutzt einen eigenen SQL Account anlegen die Benutzer müssen sich beim starten des Programms authentifizieren. Allerdings hält es sie nicht davon ab dann immernoch direkt mit dem SQL Server zu sprechen, dafür kannst du Accounts von denen Müll kommt deaktivieren. -
ggamee schrieb:
Ist aber nicht sicher, da das Protokoll einfach benutzt werden kann um unerlaubt an die Daten ranzukommen... woher will der Server wissen, ob das jetzt vom Programm kommt oder von einem Angreifer?
Am besten wäre, wie schon genannt, die Lösung eine Serverseitige Validierung von Anfragen zu übernehmen. Dies kannst du entweder in PHP machen, oder du schreibst einen Server, welcher über ein selbst definiertes Protokoll dann gewisse Dinge abfragen kann. -
Benutzeraccounts sollen vermieden werden....eine Anmeldung soll zum Verwenden des Programmes nicht nötig sein.
Der Benutzer trägt durch das Programm keine Daten selbstständig auf dem Server ein.
Ich werde ihm diese Möglichkeit durch den Client auch gar nicht geben.
Das Programm sucht sich die Daten selbst vom PC und überträgt diese....es geht wirklich einzig und allein darum, zu verhindern, dass ein Dritter mithilfe der Zugangsdaten des MySQL Servers an diese Daten rankommt.
Ich bin root auf dem Server, ja.
Beitrag zuletzt geändert: 15.5.2012 9:45:39 von adelwoehrer -
Mhm..spontaner Einfall:
Speicher die IP mit.
Nur wenn die IP im Request Header stimmt gibt dein Script Informationen raus, ansonsten werden die Anfragen mit BAD_REQUEST quittiert. Die IP Faken bringt dann wenig, weil sonst der richtige Client die Rückmeldung kriegt, oder bin ich noch zu müde und verdenke mich da gerade? Wäre Möglich. Bin ja Student. :P
Ansonsten den Weg, den kochmarkus beschrieben hat. An seine eigenen Daten sollte man ja (notfalls) ran dürfen, oder? ^^
Beitrag zuletzt geändert: 15.5.2012 11:08:54 von adrians -
Ich verstehe jetzt nicht ganz, wieso ich die IP Adresse überprüfen soll.
Worauf denn?
Und welche?
Die sind doch dynamisch und nach einem Router-Neustart wieder geändert.
Wie entscheide ich, dass eine IP Adresse ungültig ist?
Das Programm darf doch von jedem Rechner prinzipiell gestartet werden.
Die IP Adresse sagt mir doch nur, dass die Anfrage von einem bestimmten Rechner kommt....nicht dass diese Anfrage auch von meinem Programm stammte.
EDIT:
Dein Vorschlag mit der IP Adresse hat mich auf eine Idee gebracht.
Ich wüsste aber gerne, ob ihr denkt, dass das funktioniert.
Vielleicht hab ich ja was übersehen.
Ich leite die Anfrage, die die Daten an den Server überträgt nicht direkt an den Server, sondern an ein PHP Script.
Das Script erstellt dann die Daten in der Datenbank mit einem Passwort, dass eben direkt am Server hinterlegt ist....das sollte das Problem mit dem Passwort auslesen beseitigen.
Als zusätzliches Identifikationsfeld für die Datensätze frage ich dann aber noch die MAC Adresse der Netzwerkkarte des PCs ab, von dem die Daten übermittelt wurden und speichere Ihren MD5 Hash zusätzlich zu jedem Datensatz ab.
Damit sind die Datensätze eindeutig einem PC zugeordnet.
Dieses PHP Script akzeptiert im nächsten Schritt nur dann SELECT Anfragen, wenn diese eine WHERE Klausel in der Abfrage aufweisen, womit es nicht möglich ist, alle Daten einer Tabelle zu erwischen, sondern nur gezielte Anfragen zu starten.
Als Parameter für diese WHERE Klausel, wird wiederum die in MD5 Hash umgewandelte MAC Adresse der Netzwerkkarte übergeben.
Startet man nun eine SELECT Anfragen, beschränke sich diese auf die Netzwerkkarte mit dem MD5 Hash der hinterlegten MAC Adresse, solange sich die Daten am Server befinden.
Theoretisch sollte es so unmöglich sein, von einem anderen PC aus diese Daten abzurufen, außer von dem, von dem sie auch erstellt wurden.
Um hier das PHP Script auszutricksen, wäre es schon nötig, den MD5 Hash der Netzwerkkarte zu kennen, die die Datensätze erstellt hat.
Wäre das eurer Meinung nach eine mögliche Lösung?
Beitrag zuletzt geändert: 15.5.2012 12:42:32 von adelwoehrer -
adelwoehrer schrieb:
....
Um hier das PHP Script auszutricksen, wäre es schon nötig, den MD5 Hash der Netzwerkkarte zu kennen, die die Datensätze erstellt hat.
Allerdings kennt der Angreifer seine Mac Adresse und kann die md5 verschlüsseln. Wenn er die an das Php sendet, hat er Zugriff.
Ansonsten hört sich das aufwendig aber Sicher an ! -
Ein Datensatz liegt also ca. 15 Minuten am Server.
Solange sollte eine IP Adresse dann doch erhalten bleiben.
Das System ist ganz einfach: Nur die IP, die den Datensatz angelegt hat, darf diesen auch auslesen oder ändern. -
Dieses PHP Script akzeptiert im nächsten Schritt nur dann SELECT Anfragen, wenn diese eine WHERE Klausel in der Abfrage aufweisen, womit es nicht möglich ist, alle Daten einer Tabelle zu erwischen, sondern nur gezielte Anfragen zu starten.
Als Parameter für diese WHERE Klausel, wird wiederum die in MD5 Hash umgewandelte MAC Adresse der Netzwerkkarte übergeben.
Startet man nun eine SELECT Anfragen, beschränke sich diese auf die Netzwerkkarte mit dem MD5 Hash der hinterlegten MAC Adresse, solange sich die Daten am Server befinden.
Theoretisch sollte es so unmöglich sein, von einem anderen PC aus diese Daten abzurufen, außer von dem, von dem sie auch erstellt wurden.
Um hier das PHP Script auszutricksen, wäre es schon nötig, den MD5 Hash der Netzwerkkarte zu kennen, die die Datensätze erstellt hat.
Wäre das eurer Meinung nach eine mögliche Lösung?
"WHERE 1=1" und du hast wieder das Problem mit dem unbeschränkten SELECT.
Gibt für dein Problem keine adequate Lösung bis auf Benutzeraccounts zu vergeben und damit Rechtemanagement zu betreiben. -
"WHERE 1=1" und du hast wieder das Problem mit dem unbeschränkten SELECT.
Die WHERE Klausel befindet sich bereits im Script.
Sie lautet "WHERE hash = "....übergeben wird nur der Wert hinter dem "=", und der wird auf die Länge geprüft.
Jeder MD5 Hash hat eine gewisse Zeichenzahl....damit sollte das funktionieren.
Solange sollte eine IP Adresse dann doch erhalten bleiben.
Jo, hab dann gesehen, dass Du im Prinzip genau das selbe meintest, nur eben mit der IP.
Trotzdem wäre die MAC Adresse etwas statischer....es ist noch immer warscheinlicher, dass sich die IP ändert, als das innerhalb von 15 Minuten eine neue Netzwerkkarte eingebaut wird.
Allerdings kennt der Angreifer seine Mac Adresse und kann die md5 verschlüsseln. Wenn er die an das Php sendet, hat er Zugriff.
Und was fängt ein Angreifer mit seiner eigenen MAC Adresse an?
Er kann dann ja nur auf seine eigenen Datensätze zugreifen.
Beitrag zuletzt geändert: 16.5.2012 23:56:03 von adelwoehrer -
adelwoehrer schrieb:
Solange du hier auch SQL-Injections verbietest (
"WHERE 1=1" und du hast wieder das Problem mit dem unbeschränkten SELECT.
Die WHERE Klausel befindet sich bereits im Script.
Sie lautet "WHERE hash = "....übergeben wird nur der Wert hinter dem "=", und der wird auf die Länge geprüft.
Jeder MD5 Hash hat eine gewisse Zeichenzahl....damit sollte das funktionieren.
) sollte das sogar wirklich sicher sein... ansonsten könnte man eifnach sowas wiemysql_real_escape_string()
machen, dabei wird im Kommentar die Stringlänge von 32 vorgetäuscht und ansonsten wieder perWHERE hash = 1 OR 1 = 1 /*-----------------*/
die Sicherheit umgangen...OR 1 = 1
Zu der Idee mit dem MD5(MAC) oder der IP-Adresse:
Warum nicht einfach eine einfache Session mit dem Client aufmachen und den Client anhand der Session identifizieren? Natürlich musst du dann auch festlegen, dass die Session mindestens deine 15 Minuten lang gültig bleibt.
Bei der Session-Variante müsste sich ein Angreifer die Session von jemandem anderen besorgen (innerhalb der Gültigkeitsdauer!) um die Daten von dem Oper auslesen zu können... und seine eigene Session interessiert ihn vermutlich sowieso nicht.
adelwoehrer schrieb:
Du brauchst dazu nicht einmal eine neue Netzwerkkarte einbauen... es reicht wenn du der Netzwerkkarte eine neue MAC-Adresse verpasst (was softwaremäßig funktioniert)... und das funktioniert in weit weniger als 15 Minuten
Trotzdem wäre die MAC Adresse etwas statischer....es ist noch immer warscheinlicher, dass sich die IP ändert, als das innerhalb von 15 Minuten eine neue Netzwerkkarte eingebaut wird.
-
Ich weiß nicht genau was dein Problem ist? Der Hacker kommt doch gar nicht mehr an die Zugangsdaten, wenn du ein Interface zwischen Database und Client (das Interface wird oft auch Server-Applikation genannt :P) baust. Er kann doch lediglich Requests an das Interface schicken und die Response verarbeiten, bzw. einfach deine Webservices nutzen.
Das einzige Problem wird die sichere Implementierung und der "Spam-Schutz" (also dass der Angreifer ein Skript tausende male aufruft) sein. Aber mal ehrlich, wie will man das letztere ohne Authentifizierung ordentlich hinbekommen? Nicht umsonst verlangen so gut wie alle Online Dienste (wie zB. das Forum Lima-City) ein Account.
PS: So viel zu deiner Mac-Adressen-Lösung: http://www.windows7-tuning.de/tuning-tipps-anleitungen/netzwerk/mac-adresse-andern-unter-windows-mac-spoofing/ -
spuglisi schrieb:
Das Problem ist jetzt aber, dass der TE nicht möchte, dass jeder die gesamte Tabelle auslesen kann; es soll nur möglich sein die eigenen Einträge auszulesen.
Ich weiß nicht genau was dein Problem ist? Der Hacker kommt doch gar nicht mehr an die Zugangsdaten, wenn du ein Interface zwischen Database und Client (das Interface wird oft auch Server-Applikation genannt :P) baust. Er kann doch lediglich Requests an das Interface schicken und die Response verarbeiten, bzw. einfach deine Webservices nutzen.
Diese Einträge leben für 15 Minuten...
Natürlich bekommt der Angreifer das MySQL-Passwort nicht, dafür kann er SQL-Befehle direkt und ohne Passwort ausführen... das ist das Problem. -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
