MySQL Problem mit SELECT bzw encoding

[Sich]

Moin alle zusammen.

Ich habe eine mySQL-Tabelle mit 3 Feldern (id: INT(11), name:VARCHAR(45), password:VARCHAR(40)), COLLATION ist auf "utf8 - utf-8_unicode_ci" gestellt.
In der Tabelle befinden sich Benutzer mit ihren Passwörtern. Eingetragen sind sie per Hand und nicht via der JAVA-Anwendung. Soll auch möglichst später so sein, da sie Daten eigentlich von einer anderen Instanz kommen. Jedoch sind die Passwörter mittels selbstgeschreibenen Cryptertools AES-codiert, eingetragen.

Ein Eintrag sieht dann in etwa so aus: 1, test, Bv^#�CnM^#�

Nun zu meinem Problem:

Ich verbinde mich mit name und password auf einem Server, der wiederum in der DB nachschaut ob diese kombie vrohanden ist und liefert dann die Anzahl zurück:

ResultSet rs = stmt.executeQuery("SELECT count(*) FROM users WHERE nickname = \"" + user.getName() + "\" and password = \"" + user.getPassword() + "\"");

if (rs.getInt(1) == 1) {
// logIn ausführen
}

rs.getInt() liefert jedoch 0

wenn ich das ganze etwas ändere Funktioniert der logIn:

ResultSet rs = stmt.executeQuery("SELECT * FROM users WHERE nickname = \"" + user.getName()  "\"");

if (rs.getString("password").equals(user.getPassword())) {
// logIn ausführen
}

Dazu ist zusagen, dass user.getPassword() ebenfalls einen verschlüsselten String hält.

Liegt es evtl am Encoding, dass die erste Anfrage kein Ergebnis liefert? Denn wenn das Passwort ja an die Java-Anwendung "übermittelt" wird, entspricht es ja dem user.getPassword(), soll heißen: eigentlich sind sie "gleich".
Hat jemand vielleicht na Ahnung?!

Schonmal vielen Dank für die Hilfe.

Gruß
Sich

 

[Gast2]

1) Gibt es einen Grund warum du das Passwort in der Tabelle ablegst? Das macht man eigentlich nicht, auch nicht verschlüsselt. Normalerweise legt man in der DB einen Hashwert des eigentlichen Passworts ab.

2) Wenn du die Passwörter in AES verschlüsselt ablegst würde ich zumindest noch ein Base64 drüber laufen lassen um einen reinen ASCII Datensatz zu bekommen. Das macht dir das debuggen viel leichter.

3) Benutze Prepared Statements.

 

[Sich]

Moin,

erstmal Danke für deine schnelle Hilfe.

1) Ja den gibt es: Wenn es ohne Hashen nicht geht, dann auch nicht mit.

2) Das hat zum Erfolg geführt.

3) Habe ich jetzt mal eingebaut.. Für meine eine SQL-Abfrage sehe ich darin jedoch keine Vorteile.

Nochmals vielen Dank und noch einen schönen Abend

Gruß
Sich

 

[Gast2]

Moin,

erstmal Danke für deine schnelle Hilfe.

1) Ja den gibt es: Wenn es ohne Hashen nicht geht, dann auch nicht mit.

Hmmm, das versteh ich nicht... Was ich meinte:

Normalerweise wird ein Passwort nicht gespeichert sondern nur der Hash des Passworts.

Z.B gibt der User das Passwort test123 ein. Darauf wird dann z.B. SHA1 angewendet und in der Datenbank wird 7288edd0fc3ffcbe93a0cf06e3568e28521687bc gespeichert

Um jetzt zu überprüfen ob der User das richtige Passwort angegeben hat wird auf seine Eingabe wieder SHA1 angewendet und in der Datenbank gesucht:

WHERE password_hash = '7288edd0fc3ffcbe93a0cf06e3568e28521687bc'

So kann niemand (auch nicht ein Administrator) wenn er die Passwort Tabelle ausließt Rückschlüsse auf das eigentliche Passwort machen. (Solange der Hash gut ist...)

2) Das hat zum Erfolg geführt.

Gut, Problem gelöst.

3) Habe ich jetzt mal eingebaut.. Für meine eine SQL-Abfrage sehe ich darin jedoch keine Vorteile.

PreparedStatements sind meiner Meinung nach IMMER vorzuziehen. Klar hat man nicht den riesen Performance Vorteile bei einmaligen einfchen Queries aber dafür keine Probleme mit SQLInjections, falschen Quoting usw.

 

[Sich]

Hmmm, das versteh ich nicht... Was ich meinte:

Normalerweise wird ein Passwort nicht gespeichert sondern nur der Hash des Passworts.

Z.B gibt der User das Passwort test123 ein. Darauf wird dann z.B. SHA1 angewendet und in der Datenbank wird 7288edd0fc3ffcbe93a0cf06e3568e28521687bc gespeichert

Um jetzt zu überprüfen ob der User das richtige Passwort angegeben hat wird auf seine Eingabe wieder SHA1 angewendet und in der Datenbank gesucht:

WHERE password_hash = '7288edd0fc3ffcbe93a0cf06e3568e28521687bc'

So kann niemand (auch nicht ein Administrator) wenn er die Passwort Tabelle ausließt Rückschlüsse auf das eigentliche Passwort machen. (Solange der Hash gut ist...)

Da hast du mit allem natürlich total Recht, wollte damit nur sagen, dass es aber ja nichts an der Tatsache nichts geändert hatte, dass die verschlüsselten Strings trotz Java-Gleichheit nicht mit denen in der DB übereinstimmten.
Trotzdem natürlich nochmals vielen Dank für deine Hilfe und auch deiner Erläuterung bezüglich der Passwortspeicherung.

Viele Grüße
Sich