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.
