JAVA zu unsicher für MYSQL?

  • Themenstarter Themenstarter javaaa
  • Beginndatum Beginndatum
J

javaaa

Gast
Hallo,

für ein "gui spiel" mit login funktionion habe ich eine sql datenbank mit externen zugriff (gibt es auch eine andere möglichkeit?). Nun habe ich es in java geschrieben und es klappt alles.

Aber das problem ist das man die .jar datein sehr leicht dekompilieren lässt und das man beim connection string sehr leicht das passwort/username herauslesen kann. Wie kann ich es sicherer machen?
 
Das hat recht wenig mit Java zu tun. Oder meinst du, dass irgendwo in Diablo 3 der Zugang zur BattleNet-Datenbank hinterlegt ist?
Du könntest Serverseitig ein Dienst anbieten, der Login+PW entgegennimmt, und falls die korrekt sind eine SessionID zurückliefert
 
  • Sicherer ist möglich - da gibt es z.B. "obfuscation", dazu werden sicher gleich noch andere mehr schreiben.
  • Sicher ist nicht möglich, behaupte ich mal: irgendwann muss das Passwort irgendwie vom Client zum Server. Zumindest solang die Datenbank verbindung vom Client ausgeht. Aber auch wenn du das machst, was XHelp sagt, können andere dein Programm dekompilieren und so die Information gewinnen, wie sie von außerhalb deines Programms auf diesen Server-Dienst zugreifen und ihm falsche Informationen (z.B. Integer.MAX_VALUE als highscore 😉) übergeben.
    Vor so etwas kann man sich natürlich auch in gewissem Maß schützen, aber das hängt dann von dem ganz konkreten Problem ab.
 
Sicher ist nicht möglich, behaupte ich mal
wieso nur "behaupten"? ... es ist eine Tatsache das man ein Passwort immer dekompilieren kann ... selbst wenn ich das Passwort verschlüssele, das Passwort zum Entschlüsseln des Passwortes muss ich im Klartext ablegen (Dekompilierbar) ... dann kann ich das Passwort zum Verschlüsseln des Passwortes mit einem Passwort verschlüsseln ... gut es wird langsam Rekursiv ... sprich - es ist nicht möglich ein Passwort sicher im Programm zu hinterlegen

für ein "gui spiel" mit login funktionion habe ich eine sql datenbank mit externen zugriff (gibt es auch eine andere möglichkeit?).
klärt sich mit einem zusätzlichen (nötigem) Layer

Wie kann ich es sicherer machen?
ein zusätzlicher Layer der auf dem Server läuft ... dieser verwaltet die Benutzer(anmeldungen) und nur der Layer hat Zugriff auf die DB ... der Spielclient stellt die Anfrage an den Layer - der bastelt daraus die Anfrage für den SQL-Server und gibt die Antwort des Servers an den Client zurück ... damit kannst Du den SQL-Server vor dem Internet absichern, da der Layer nur über localhost zugreifen muss

Code:
[Client] <--> [Layer] <--> [SQL-Server]

hand, mogel

PS: der Client darf keine SQL-Anfragen stellen (also "SELECT *") ... sonst besteht die Gefahr das man den Layer so programmiert das die SQL-Anfragen direkt durchgereicht werden ... damit wird die DB (indirekt) wieder Öffentlich
 
Zuletzt bearbeitet von einem Moderator:
1. Serveranwendungen mit clientseitigem Datanbankzugriff? Herzlichen Glückwunsch, wie lange soll der Server denn laufen? Also das ist schon mal 'ne ganz schlechte Idee. Da muß serverseitig schon mal 'ne Anwendung her, die ihrerseits die Datenbankabfragen tätigt und die Kommunikation mit den Clienten herstellt. (siehe mogels Post)
2. Ein Passwort irgendwie im Programmcode aufbewahren ist nicht wirklich das klügste. Viel dümmer ist es, zu einem verschlüsselten PW auch noch den passenden Schlüssel mitzuliefern, damit dieses auch noch unverschlüsselt gesendet werden kann. :lol: Naja, mogel, ein Passwort lässt sich nicht immer entschlüsseln, aber zur Not sendet man halt doch die Sequenz, die der Server als Authentifizierung erwartet - irgendwie. Zur Passworteingabe sowie zum maximalen Erschweren von Decompile fällt mir dagegen schon eine prächtige Lösung ein und zwar ein öffentlicher Schlüssel, welcher durchaus auch im Programmcode vorhanden sein darf. Damit lassen sich Passwörter für den Server ver- und Klassen vom Server oder in der Anwendung entschlüsseln. Das private Gegenstück des Schlüsselpaares verbleibt dabei logischerweise stets ungesehen auf dem Server. Zu guter letzt, wenn man echt die Pfanne heiss und die Haare schön hat, kann man es renomierten PayTV-Sendern gleich tun und den öffentlichen Schlüssel meinetwegen alle 3 Sekunden austauschen und obendrein auch noch die Datenpakete zwischen Server und Client verschlüsseln.
3. Was man im übrigen nicht vergessen darf; Egal wo eine Anwendung eine SQL-Datenbank verwendet, sollte sie so aufgebaut sein, dass eine SQL-Injection weitgehend verhindert wird. Wer nun fragt, ob Java für MySQL zu unsicher ist, kennt z.B. PHP noch nicht richtig, denn im Gegensatz dazu, erlaubt Java von Haus aus keine Code-Injection mit welcher man in der Lage wär, eine SQL-Injection direkt im Programmcode des Servers zu platzieren. Wirklich üble Sache das 😉 Kurzum: Es gibt unsichereres.
 
Zuletzt bearbeitet von einem Moderator:

Zurück
Oben