Hi,
ich arbeite nun mit sensiblen Daten. Der User hat über ein Form die Möglichkeit, ein Credential (also Username und Passwort) anzugeben und sich somit eine Authentifizierung zu verschaffen.
Das Hashing des Passworts soll auf Serverseite passieren und der gehashte Wert wird mit dem Usernamen in der Datenbank gespeichert.
Wie kriege ich das Passwort am besten Richtung Datenbank, so, dass es nicht im Klartext vorliegt?
Eine eventuelle Anforderung könnte später sein, dass man ein typisches "Augensymbol" hat, wo der User das Passwort lesbar machen könnte.
Ich hatte überlegt, das Passwort auf der Clientseite mit AES 256 zu verschlüssen, dieses auf der Serverseite zu entschlüssen und dann zu hashen. Anschließend den Hash in die Datenbank schieben.
Wenn ich das so mache, stellt sich die Frage: Wie versorge ich den Client mit dem Public Key?
Ein Problem, was ich hierin sehe, ist die Integrität. Daher fände ich es ganz gut, das Passwort auch schon bereits auf Clientseite zu hashen, um die Integrität auf Serverseite zu prüfen.
Bei meinen ganzen Überlegung allerdings, kam mir die entgültige Überlegung, dass ich zu viel überlege... und daher mal etwas bewanderte Leute fragen wollte, wie die solche Geschichten lösen.
Wie löst ihr solche Probleme? Wie sollte ich mein Problem lösen?
Ich würde mich über Ratschläge freuen.
LG und Danke im Voraus.
Hi,
ich speichere Passwörter niemals so ab, dass ich sie in irgendeiner Art und Weise rekonstruieren kann.
Wenn mal jemand sein Passwort nicht mehr weiß, so kann derjenige es über die typische "Passwort vergessen"-Funktion, bei der man eine E-Mail mit einem nur für eine begrenzte Zeit gültigen Link erhält und über diesen Link dann sein Passwort neu setzen kann.
Hi,
den Sinn hinter einer solchen Verschlüsselung sehe ich persönlich nicht. Wenn du es clientseitig machst - liegen sowohl der Schlüssel als auch die Verschlüsselungsmethode auf dem Client vor, womit dieser Schritt im Prinzip für die Katz ist. Der Server sollte dafür lieber schlicht über ein Zertifikat verfügen und ausschließlich HTTPS anbieten.
Passwörter speichert man generell irreversibel mit einem Hash (inkl. Salt), der es nicht erlaubt das ehemalige Passwort zu rekonstruieren. (Wenn deine DB geknackt wird haben die User sonst nämlich schnell mal ein Problem...) Mir ist in den letzten Jahren nur eine Firma begegnet, bei der ich gemerkt habe, dass mein Passwort im Klartext gespeichert wurde - habe mich sofort an den Datenschutzbeauftragten gewendet und mich dort löschen lassen.
Für das Wiederherstellen eines Passworts verwendet man normalerweise die vom User hinterlegte Email für einen speziellen codegeschützten Link, mit dessen Hilfe man schlicht ein neues Passwort setzt.
LG
Speichern als salted hash, Sicherheit beim Übertragen durch passende Wahl eines sicheren Kommunikationskanals, anstatt selbst zu verschlüsseln. TLS macht das, was du möchtest.
LaTino
"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)
Ich würde auch LaTinos Ansatz folgen.
Benutzer und PW sollte der Client über https an den Server senden.
Der Server nutzt dann salted Hashes für die Passwörter.
Mit genug Iterationen und dem richtigen Hashverfahren hast du dann eine gute Basis.
Eine gute Anleitung zu dem Thema:
https://crackstation.net/hashing-security.htm
Sollte soweit alles abdecken.
T-Virus
Developer, Developer, Developer, Developer....
99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
Danke für die Hinweise.
Ich weiß bereits einiges über Verschlüsselungsverfahren und Hashing.
Aber braucht man nicht ein Zertifikat für Benutzung eines SSLs?
Hi,
ja - dafür braucht man ein Zertifikat - das gibt's allerdings z.B. via LetsEncrypt kostenlos.
LG