Logik hinter Passwort-Verschlüsselung
Felix Riesterer
0 0 dedlfix
Logik hinter Passwort-Verschlüsselung
Felix Riesterer
Matthias ApselLiebe Mitlesende,
meine Logik versagt gerade. Daher bitte ich um Hilfe.
Auf einer Website sollen Passwörter zu Benutzernamen gespeichert werden. Das tut man nicht im Klartext, das gehört sich nämlich nicht, sondern erzeugt unumkehrbare Hashes (in meinem Fall mit der PHP-Funktion password_hash()). Soweit noch klar.
Nun möchte ich einen String so verschlüsseln, dass ihn der User mit seinem Klartext-Passwort wieder entschlüsseln kann. Wie mache ich das, wenn ich das Klartext-Passwort nicht habe, sondern nur einen unumkehrbaren Hash? Ist das überhaupt möglich, oder muss ich einen anderen Weg finden?
Zum Hintergrund: Ich experimentiere mit Möglichkeiten des "sicheren Datenaustauschs" über ungesicherte Verbindungen.
Liebe Grüße,
Felix Riesterer.
-
Liebe Mitlesende,
meine Logik versagt gerade. Daher bitte ich um Hilfe.
Auf einer Website sollen Passwörter zu Benutzernamen gespeichert werden. Das tut man nicht im Klartext, das gehört sich nämlich nicht, sondern erzeugt unumkehrbare Hashes (in meinem Fall mit der PHP-Funktion password_hash()). Soweit noch klar.
BULLSHIT !!! Passwörter gehören im Klartext in der Datenbank gespeichert. Begründung Seite 317 bis 318 im Kapitel Passwörter sicher speichern und übertragen im Postfix Buch von Peer Heinlein.
Nun möchte ich einen String so verschlüsseln, dass ihn der User mit seinem Klartext-Passwort wieder entschlüsseln kann. Wie mache ich das, wenn ich das Klartext-Passwort nicht habe, sondern nur einen unumkehrbaren Hash? Ist das überhaupt möglich, oder muss ich einen anderen Weg finden?
Zum Hintergrund: Ich experimentiere mit Möglichkeiten des "sicheren Datenaustauschs" über ungesicherte Verbindungen.
Sieh dir CRAM-Verfahren (Challenge Response Authentication Method) an.
-
Hallo Kay,
BULLSHIT !!! Passwörter gehören im Klartext in der Datenbank gespeichert.
Satzzeichen sind keine Rudeltiere ;-)
Begründung Seite 317 bis 318 im Kapitel Passwörter sicher speichern und übertragen im Postfix Buch von Peer Heinlein.
Kannst du die Begründung hier kurz zusammenfassen?
Bis demnächst
Matthias--
Signaturen sind bloed (Steel) und Markdown ist mächtig.-
Lieber Matthias,
Kannst du die Begründung hier kurz zusammenfassen?
also bei mir hat da gerade der Ironie-Detektor voll ausgeschlagen... Bei Dir nicht?
Liebe Grüße,
Felix Riesterer.
-
Hallo Felix Riesterer,
also bei mir hat da gerade der Ironie-Detektor voll ausgeschlagen... Bei Dir nicht?
Zunächst auch, aber ich mal geschaut, ob es das Buch tatsächlich gibt und was das Internet über den Autor verrät …
Bis demnächst
Matthias--
Signaturen sind bloed (Steel) und Markdown ist mächtig.
-
-
-
Lieber Kay,
Postfix Buch von Peer Heinlein.
hättest Du da 'ne ISBN zu? ;-)
Sieh dir CRAM-Verfahren (Challenge Response Authentication Method) an.
- Der Server sendet eine Zeichenkette (Zahlen, Zeitstempel und voll qualifizierter Hostname des Servers) zum Client (Challenge).
- Der Client antwortet mit einer Zeichenkette aus Nutzernamen, Leerzeichen und einem „Digest“. Dieses Digest ist der Base64 kodierte MD5-Hash eines Wertes berechnet aus Challenge und Passwort (Response).
- Der Server kann das erhaltene Digest überprüfen, indem er dieselbe Berechnung durchführt und das Ergebnis mit dem vom Client erhaltenen vergleicht. Dazu benötigt er Hashwerte (ipad/opad) des Passwortes (oder bei falscher Implementierung das Passwort im Klartext).
Soweit so unklar. :-( Mal sehen, ob ich da schon etwas fertiges finde, so mit PHP-Klasse serverseitig und Java-Klasse clientseitig... oder kennst Du da schon etwas?
Liebe Grüße,
Felix Riesterer.
-
Lieber Kay,
Postfix Buch von Peer Heinlein.
hättest Du da 'ne ISBN zu? ;-)
Ja! ;-) Das Buch gibt es nur noch als Restposten, Neuauflage in 2016 Stimmt die gmx Adresse auf der Homepage noch?
-
Lieber Kay,
Das Buch gibt es nur noch als Restposten, Neuauflage in 2016
habe ich gesehen. Werde es mir aber nicht kaufen.
Stimmt die gmx Adresse auf der Homepage noch?
Nö, deswegen ist sie ja durchgestrichen. Ich entferne das deswegen (noch) nicht, da diese Mailadresse im Quellcode meines GB-Scripts steht.
Liebe Grüße,
Felix Riesterer.
-
-
Lieber Kay,
BULLSHIT !!! Passwörter gehören im Klartext in der Datenbank gespeichert.
nur nochmal zur Sicherheit: Habe ich Dich da richtig verstanden?
Liebe Grüße,
Felix Riesterer.
-
Lieber Kay,
BULLSHIT !!! Passwörter gehören im Klartext in der Datenbank gespeichert.
nur nochmal zur Sicherheit: Habe ich Dich da richtig verstanden?
Liebe Grüße,
Felix Riesterer.
Wenn man CRAM-Verfahren wie CRAM-MD5, CRAM-SHA1, CRAM-SHA256 oder APOP einsetzt, dann gehören die Passworte im Klartext gespeichert. Nur dann kann der Server abhörsichere Verfahren anbieten. Der Schutz besteht ja darin, das nicht die Passwörter übertragen werden, vereinfacht gesagt.
PLAIN und LOGIN sollten nicht ohne SSL/TLS verwendet werden.
Das schließt ja nicht aus, das man für andere Anwendungsbereiche die Passwörter verschlüsselt speichert. Hab ich jetzt die Klarheit beseitigt?
-
Lieber Kay,
Wenn man CRAM-Verfahren wie CRAM-MD5, CRAM-SHA1, CRAM-SHA256 oder APOP einsetzt, dann gehören die Passworte im Klartext gespeichert.
warum aber schreibt Wikipedia hierzu "oder bei falscher Implementierung das Passwort im Klartext"? Mir ist noch nicht klar wie ich einen Hashwert mit "ipad/opad" erstelle, um dann damit ein Digest zu verifizieren, aber dass ich das Passwort jeweils im Klartext benötige, scheint laut Wikipedia keinesfalls die einzig richtige Lösung zu sein.
PLAIN und LOGIN sollten nicht ohne SSL/TLS verwendet werden.
Es gibt keinen Login-Prozess. Es gibt einen HTTP-Request, der als Response einen verschlüsselten String erzeugt. Dieser String ist mit einer Passphrase veschlüsselt, die der Client kennt, um damit den Datenstrom wieder zu entschlüsseln.
Hab ich jetzt die Klarheit beseitigt?
Nö, leider nicht.
Liebe Grüße,
Felix Riesterer.
-
Lieber Kay,
Wenn man CRAM-Verfahren wie CRAM-MD5, CRAM-SHA1, CRAM-SHA256 oder APOP einsetzt, dann gehören die Passworte im Klartext gespeichert.
warum aber schreibt Wikipedia hierzu "oder bei falscher Implementierung das Passwort im Klartext"? Mir ist noch nicht klar wie ich einen Hashwert mit "ipad/opad" erstelle, um dann damit ein Digest zu verifizieren, aber dass ich das Passwort jeweils im Klartext benötige, scheint laut Wikipedia keinesfalls die einzig richtige Lösung zu sein.
Ich bin gerade sehr eingespannt, ob es Programme oder Implementierungen gibt, die Passwörter als Hash speichern und CRAM-Verfahren anbieten, keine Ahnung.
Hier Zwei Links, die dir vielleicht weiter helfen.
-
Lieber Kay,
im Endergebnis macht das die Entschlüsselung auf Client-Seite wesentlich aufwendiger. Ob das die Sache allerdings wert ist, scheint für meinen Anwendungsfall zweifelhaft.
Herzlichen Dank für die ganzen hilfreichen Infos!
Liebe Grüße,
Felix Riesterer.
-
-
-
-
-
-
Tach!
Nun möchte ich einen String so verschlüsseln, dass ihn der User mit seinem Klartext-Passwort wieder entschlüsseln kann.
Wer soll denn den String wieder entschlüsseln dürfen? Nur der User? Oder alle mit Zugriff auf die Datenbank?
Wie mache ich das, wenn ich das Klartext-Passwort nicht habe, sondern nur einen unumkehrbaren Hash? Ist das überhaupt möglich, oder muss ich einen anderen Weg finden?
Wenn du den unumkehrbaren Hash als Passwort für die Verschlüsslung nimmst, kannst du mit Datenbankzugriff beliebig auf die Klartextdaten zugreifen. Möchtest du das nicht, musst du das Klartext-Passwort vom User nehmen und es dir sowohl zum Ver- als auch zum Entschlüsseln geben lassen.
Zum Hintergrund: Ich experimentiere mit Möglichkeiten des "sicheren Datenaustauschs" über ungesicherte Verbindungen.
Na da musst du wohl eher was mit Public/Private-Schlüsseln à la SSH machen.
dedlfix.
-
Lieber dedlfix,
Wer soll denn den String wieder entschlüsseln dürfen? Nur der User? Oder alle mit Zugriff auf die Datenbank?
alle mit Zugriff auf das Klartext-Passwort. Dieses soll eine Benutzereingabe sein. Und nur da soll es im Klartext vorkommen. Zum Entschlüsseln.
Möchtest du das nicht, musst du das Klartext-Passwort vom User nehmen und es dir sowohl zum Ver- als auch zum Entschlüsseln geben lassen.
Du bestätigst gerade meine Befürchtung, dass ich einen unmöglichen Lösungsansatz gewählt habe. Da ist wohl eine CRAM-Vorgehensweise sinnvoller, so wie Kay sie vorschlug.
Liebe Grüße,
Felix Riesterer.
-