spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Du benutzt keine Verschlüsselungsfunktion, sondern eine Hashfunktion mit Salt. Diese ist nicht umkehrbar. Aber wenn du vorne das selbe hineinschmeißt, kommt hinten das selbe wieder hinten raus. Das kannst du vergleichen.

Zitat von »Daedra22«

die MySQL Datenbank ist extern erreichbar also ich komme an die Datensätze mit den richtigen Berechtigungen ran

Um Gottes Willen! Wieso das denn?

Ich hab mir vor kurzem dieses Buch ausgeliehen:
http://www.amazon.de/Professionell-entwi…isual+c%23+2012

Da geht es auch in einigen Kapitel um die richtige Softwarearchitektur und in welchen Schichten man solche Serveranwendungen aufbauen sollte, etc. Das würde dir bestimmt weiterhelfen.

Edit: Sehe gerade hier geht es um Php, aber einige Kapitel sind sehr allgemein gehalten, ansonsten vielleicht würde es bei deiner Cliententwicklung helfen.

Es wurde bereits in einem anderen Thread beschrieben, dass und warum du keinen externen Zugriff auf die Datenbank einbauen solltest. Es ist ein leichtes, die Netzwerkkommunikation mitzulesen oder den Java-Code zu dekompilieren. Darüber weiß man, auf welchen Server zugegriffen wird und mit welchen Logindaten der Benutzer zugreift. Nun kann man sich ein beliebiges Programm nehmen, mit dem man SQL-Datenbanken verwqaltten kann, um auf alle Daten der Datenbank zuzugreifen. Selbst wenn du alles verschlüsseln würdest, wäre es nur eine Frage der Zeit, bis jemand die richtigen Logindaten findet und Zugriff auf die Datenbank bekommt.
Würde jeder Benutzer Datenbankseitig seinen eigenen Benutzer haben, dessen Rechte entsprechend eingeschränkt sind, sähe das ein wenig anders aus, aber wirklich nur ein wenig. Die Tabellen, die nur von ihm genutzt bzw. nur von anderen genutzt werden könnten, wären kein Problem. Tabellen, auf die jeder Benutzer zugreifen kann oder können soll, könnten immernoch gänzlich bearbeitet werden, sodass der Benutzer bspw. immernoch die Benutzerinformationen aller anderen Benutzer sehen und bearbeiten kann. Weiterhin müsste für jeden Benutzer, der sich bei deinem Dienst anmeldet, ein Datenbankbenutzer angelegt werden. Nutzt man einen kostenlosen Anbieter, hat man i. d. R. eine Begrenzung der Datanbank-Benutzer.

Was du eher machen solltest, ist, wie schon oft genug beschrieben, den Client nur mit dem Server kommunizieren zu lassen, der wiederum Informationen persistent hinterlegen kann. Dem Client muss dabei egal sein, wie die Daten genau gespeichert werden, da er nur die Schnittstelle zum Server kennt. So kann der Server auf Änderungen der Datenstrukturen in der Datenbank eingehen, ohne dass der Client gänzlich zusammenbricht. Mal ganz abgesehen davon, dass jede Anfrage an den Server authentifiziert werden kann.

Wenn du schrittweise vorgehen willst, dann solltest du dich entweder erst um den Server kümmern, der die Daten richtig speichern und laden kann, oder erst um den Client, der Zufallsdaten, Mockupdaten o. ä. vom Server erhält. Solltest du mit dem Server anfangen (was ich wahrscheinlich machen würde), dann könntest du als Client den Webbrowser verwenden und vorerst alles als HTML zurückgeben.

Ein SALT ist dabei etwas, was nur du bzw. deine internen Vorgänge kennen, z.B. "FooBar". Dieser string wird an dein Passwort dran gehängt und mit verschlüsselt (oder verschlüsselt angehängt und nochmal verschlüsselt, wie man es mag).
Falls nun ein Brute-Force Angriff kommt und der Angreifer dank Wortbuch oder sonstwas eigentlich dein Passwort erraten würde (sagen wir es ist "Quatz"), dann stimmt der Hash den der Angreifer für "Quatz" errechnet aber nicht mit dem tatsächlichen Hash deines Passworts in der Datenbank überein, denn dank deines SALT's sieht der Hash völlig anders aus. Idealerweise besteht der SALT natürlich aus Alphanumerischen Zeichen.