Geben Sie niemals Passwörter fest in Ihren Code ein. Dies wurde kürzlich in den Top 25 der gefährlichsten Programmierfehler erwähnt :
Das Hardcodieren eines geheimen Kontos und eines Passworts in Ihre Software ist äußerst praktisch - für erfahrene Reverse Engineers. Wenn das Passwort für Ihre gesamte Software gleich ist, wird jeder Kunde verwundbar, wenn dieses Passwort unweigerlich bekannt wird. Und weil es fest codiert ist, ist es ein großer Schmerz, den man beheben muss.
Sie sollten Konfigurationsinformationen, einschließlich Kennwörter, in einer separaten Datei speichern, die die Anwendung beim Start liest. Dies ist der einzige wirkliche Weg, um zu verhindern, dass das Passwort infolge der Dekompilierung verloren geht (kompilieren Sie es zunächst nie in die Binärdatei).
Weitere Informationen zu diesem häufigen Fehler finden Sie im Artikel CWE-259 . Der Artikel enthält eine gründlichere Definition, Beispiele und viele andere Informationen zum Problem.
In Java ist die Verwendung der Preferences-Klasse eine der einfachsten Möglichkeiten, dies zu tun. Es dient zum Speichern aller Arten von Programmeinstellungen, von denen einige einen Benutzernamen und ein Passwort enthalten können.
import java.util.prefs.Preferences;
public class DemoApplication {
Preferences preferences =
Preferences.userNodeForPackage(DemoApplication.class);
public void setCredentials(String username, String password) {
preferences.put("db_username", username);
preferences.put("db_password", password);
}
public String getUsername() {
return preferences.get("db_username", null);
}
public String getPassword() {
return preferences.get("db_password", null);
}
// your code here
}
Im obigen Code können Sie die setCredentialsMethode aufrufen , nachdem Sie in einem Dialogfeld nach dem Benutzernamen und dem Kennwort gefragt haben. Wenn Sie eine Verbindung zur Datenbank herstellen müssen, können Sie einfach die Methoden getUsernameund getPasswordverwenden, um die gespeicherten Werte abzurufen. Die Anmeldeinformationen werden nicht fest in Ihre Binärdateien codiert, sodass die Dekompilierung kein Sicherheitsrisiko darstellt.
Wichtiger Hinweis: Die Voreinstellungsdateien sind nur XML-Dateien im Nur-Text-Format. Stellen Sie sicher, dass Sie geeignete Maßnahmen ergreifen, um zu verhindern, dass nicht autorisierte Benutzer die Rohdateien anzeigen (UNIX-Berechtigungen, Windows-Berechtigungen usw.). Zumindest unter Linux ist dies kein Problem, da beim Aufruf Preferences.userNodeForPackagedie XML-Datei im Home-Verzeichnis des aktuellen Benutzers erstellt wird, die von anderen Benutzern ohnehin nicht gelesen werden kann. In Windows kann die Situation anders sein.
Wichtigere Hinweise: In den Kommentaren dieser und anderer Antworten wurde viel darüber diskutiert, welche Architektur für diese Situation richtig ist. In der ursprünglichen Frage wird der Kontext, in dem die Anwendung verwendet wird, nicht wirklich erwähnt, daher werde ich über die beiden Situationen sprechen, die mir einfallen. Der erste Fall ist der Fall, in dem die Person, die das Programm verwendet, die Datenbankanmeldeinformationen bereits kennt (und dazu berechtigt ist). Der zweite Fall ist der Fall, in dem Sie als Entwickler versuchen, die Datenbankanmeldeinformationen vor der Person, die das Programm verwendet, geheim zu halten.
Erster Fall: Der Benutzer ist berechtigt, die Anmeldeinformationen der Datenbank zu kennen
In diesem Fall funktioniert die oben erwähnte Lösung. Die Java- PreferenceKlasse speichert den Benutzernamen und das Kennwort im Klartext, die Einstellungsdatei kann jedoch nur vom autorisierten Benutzer gelesen werden. Der Benutzer kann einfach die XML-Datei mit den Einstellungen öffnen und die Anmeldeinformationen lesen. Dies ist jedoch kein Sicherheitsrisiko, da der Benutzer die Anmeldeinformationen zunächst kannte.
Zweiter Fall: Versuch, Anmeldeinformationen vor dem Benutzer zu verbergen
Dies ist der kompliziertere Fall: Der Benutzer sollte die Anmeldeinformationen nicht kennen, benötigt jedoch weiterhin Zugriff auf die Datenbank. In diesem Fall hat der Benutzer, der die Anwendung ausführt, direkten Zugriff auf die Datenbank. Dies bedeutet, dass das Programm die Anmeldeinformationen im Voraus kennen muss. Die oben erwähnte Lösung ist für diesen Fall nicht geeignet. Sie können die Anmeldeinformationen der Datenbank in einer Voreinstellungsdatei speichern, der Benutzer kann diese Datei jedoch lesen, da er der Eigentümer ist. Tatsächlich gibt es keine gute Möglichkeit, diesen Fall sicher zu verwenden.
Richtiger Fall: Verwenden einer mehrschichtigen Architektur
Der richtige Weg, dies zu tun, besteht darin, zwischen Ihrem Datenbankserver und Ihrer Clientanwendung eine mittlere Schicht zu haben, die einzelne Benutzer authentifiziert und die Ausführung einer begrenzten Anzahl von Vorgängen ermöglicht. Jeder Benutzer hätte seine eigenen Anmeldeinformationen, jedoch nicht für den Datenbankserver. Die Anmeldeinformationen würden den Zugriff auf die mittlere Schicht (die Geschäftslogikschicht) ermöglichen und wären für jeden Benutzer unterschiedlich.
Jeder Benutzer hätte seinen eigenen Benutzernamen und sein eigenes Passwort, die ohne Sicherheitsrisiko lokal in einer Einstellungsdatei gespeichert werden könnten. Dies wird als dreistufige Architektur bezeichnet (die Ebenen sind Ihr Datenbankserver, Ihr Geschäftslogikserver und Ihre Clientanwendung). Es ist komplexer, aber es ist wirklich der sicherste Weg, so etwas zu tun.
Die grundlegende Reihenfolge der Operationen lautet:
- Der Client authentifiziert sich mit der Geschäftslogikschicht unter Verwendung des persönlichen Benutzernamens / Passworts des Benutzers. Der Benutzername und das Kennwort sind dem Benutzer bekannt und stehen in keiner Beziehung zu den Anmeldeinformationen der Datenbank.
- Wenn die Authentifizierung erfolgreich ist, fordert der Client die Geschäftslogikschicht an und fordert einige Informationen aus der Datenbank an. Zum Beispiel ein Inventar von Produkten. Beachten Sie, dass die Clientanforderung keine SQL-Abfrage ist. Es ist ein Remote-Prozeduraufruf wie
getInventoryList.
- Die Geschäftslogikschicht stellt eine Verbindung zur Datenbank her und ruft die angeforderten Informationen ab. Die Geschäftslogikschicht ist für die Erstellung einer sicheren SQL-Abfrage auf der Grundlage der Benutzeranforderung verantwortlich. Alle Parameter der SQL-Abfrage sollten bereinigt werden, um SQL-Injection-Angriffe zu verhindern.
- Die Geschäftslogikschicht sendet die Inventarliste zurück an die Clientanwendung.
- Der Client zeigt dem Benutzer die Inventarliste an.
Beachten Sie, dass die Clientanwendung während des gesamten Prozesses niemals eine direkte Verbindung zur Datenbank herstellt . Die Geschäftslogikschicht empfängt eine Anforderung von einem authentifizierten Benutzer, verarbeitet die Anforderung des Clients für eine Inventarliste und führt erst dann eine SQL-Abfrage aus.