Ich verwende die jBCrypt-Bibliothek , um Benutzerpasswörter zu hashen, wenn sie sich mit meiner App registrieren.
Ich benutze die grundlegende Hash-Funktion, mit einem Salz, wie folgt:
%Vor%Ich bemerkte ein ein bis zwei Minuten hängen bei der Registrierung und überprüfte den Debugger, bestätigt BCrypt war verantwortlich.
Hat das Salzen des Passworts wirklich diese Verarbeitungsleistung? Wenn ja, wäre es eine gute Alternative, das Klartext-Passwort zum Server zu senden, um es zu hashen? Mein ursprünglicher Gedanke zu diesem Thema war, es zu hacken, bevor es irgendwohin geschickt wurde. Irgendwelche Ideen?
Hier ist ein Artikel , in dem die Zeiten auf einem Mac-Laptop mit einem Core 2 Duo-Prozessor. Also, ja, Bcrypt ist wahrscheinlich sehr langsam auf einem mobilen Gerät.
Ein weiteres häufiges Problem ist die Initialisierung von SecureRandom , die sehr langsam sein kann und auch hängen kann, weil genügend Zufallsdaten fehlen. Dies kann zwischen verschiedenen Maschinen und Betriebssystemen variieren. Sie werden dies an anderer Stelle oft diskutieren, aber es ist vielleicht etwas, das Sie testen möchten, indem Sie new SecureRandom() selbst initialisieren oder indem Sie gensalt separat aufrufen, um die zufällige Datengenerierung zu isolieren und dann den Aufruf von hashpw zu starten. .
Eine andere Frage ist, warum Sie es eigentlich auf dem Client hashen wollen? Wenn Sie es auf dem Client speichern und sich lokal anmelden, ist das zwar sinnvoll, aber wenn es an einen Server gesendet wird und eine normale Anmeldung ein Klartext-Passwort an den Server sendet, gewinnen Sie nichts. Ein häufiges Missverständnis ist auch, dass das Hazeln eines Passworts vor dem Senden an den Server (wenn man sich anmeldet) einen gewissen Schutz bietet, während es in Wirklichkeit dem Senden des Klartext-Passworts entspricht. Ein Angreifer hat nur den Hash erhalten, um Zugriff zu erhalten.
Durch das Verhindern von Passwörtern wird verhindert, dass ein Angreifer Zugriff erhält (oder zumindest verlangsamt), falls das Passwort selbst kompromittiert wird.
Wenn also das Passwort auf dem Server gespeichert wird, sollte es im Klartext gesendet werden (über einen sicheren Kanal) und der Server sollte entscheiden, wie es gehackt wird.