Ich habe hier und an anderen Stellen viel über die Verwendung eines Cookies für eine "Remember me" -Option gelesen, aber was ich suche ist ein Weg zu Entwerfen Sie einen Cookie, um den Erfolg einer Zwei-Faktor-Authentifizierung aufzuzeichnen. Dies ist beispielsweise bei Google der Fall: Wenn der zweite Schritt erfolgreich ist (z. B. Sie den Code eingegeben haben, den Sie per SMS erhalten haben), wird ein Cookie für einen bestimmten Zeitraum (z. B. 30 Tage) eingerichtet Der zweite Schritt kann umgangen werden. Nennen Sie das "Bestätigungs-Cookie". Mein Verständnis ist, dass wenn Sie sich in dieser Zeit ausloggen und dann wieder einsteigen, wird es nicht den zweiten Schritt machen, sondern nur den ersten Schritt. (Ich habe das getestet und das schien der Fall zu sein.)Cookie benötigt, um sich an Zwei-Faktor-Authentifizierungserfolg zu erinnern (nicht persistente Anmeldung)
Meine Frage ist, wie man diesen Cookie gestaltet. Eine Idee besteht darin, die Benutzer-ID und eine 128-Bit-Zufallszahl in den Cookie zu schreiben und diese Nummer zusammen mit der Benutzer-ID in der Datenbank zu speichern. Dies empfiehlt Charles Miller (http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice/) für Cookies mit persistentem Login.
Allerdings ist das nicht gut genug, denke ich. Das Problem ist, dass, da der Benutzer eine Zwei-Faktor-Autorisierung verwendet, jeder Cookie, der verwendet wird, um aufzuzeichnen, dass der zweite Schritt erfolgreich war, sicherer sein sollte, als dies bei einer Ein-Faktor-Autorisierung der Fall wäre.
Was ich vermeiden möchte, ist dies: Der Cracker hat die Hash/gesalzen Passwörter aus der Datenbank und hat irgendwie das Passwort bekommen. Wenn er/sie so viel hat, nehme ich an, dass die 128-Bit-Zufallszahl, die im Bestätigungs-Cookie war, ebenfalls verfügbar ist. (Wenn der Cracker das Passwort auf andere Weise erhalten hat und die Datenbank nicht besitzt, ist das Bestätigungs-Cookie sicher, es sei denn, er/sie hat physischen Zugriff auf den Computer. Ich mache mir nur Sorgen über den kompromittierten Datenbankfall.)
Vielleicht ist eine Idee, die 128-Bit-Zufallszahl zu verschlüsseln? (Muss 2-Wege-sein - kein Hash.) Der Verschlüsselungsschlüssel wäre für die Anwendung zugänglich, könnte jedoch gespeichert werden, wie auch die Datenbank-Anmeldeinformationen sind.
Hat jemand implementiert, was ich einen Verifizierungscookie (nicht ein persistenter Login-Cookie) genannt und kann mir sagen (uns), wie es gemacht wurde?
UPDATE: darüber nachgedacht, was würde ich sicher genug sein, denken wäre dies: Plätzchen besteht aus Benutzer-ID und 128-Bit-Zufallszahl - es
R. nennenDatenbank enthält Passwort und R, jeweils gehackt und gesalzen (zB mit PhPass). R gilt dann als zweites Passwort. Vorteil: Selbst wenn das erste Passwort falsch ist (z. B. "password1"), ist R ein sehr gutes Passwort. Datenbank kann wirklich nicht geknackt werden, also sollte es keine Sorge sein. (Ich war unnötig besorgt darüber, denke ich.)
ich einen Weg gegeben, um das Cookie an den Browser zu sperren: Vor dem Hashing verkette ich das, was ich R nenne, mit dem Benutzeragenten und einigen Bildschirmeigenschaften (DPI, Breite, Höhe, usw.). Natürlich ist keine der verketteten Eigenschaften im Cookie gespeichert, nur R ist. Wenn also der Cracker R bekommt, müsste er/sie auf einem Computer mit den gleichen Eigenschaften vom Browser aus laufen. Nicht perfekt, aber macht es viel schwieriger, die Daten des Cookies zu fälschen. Ich denke, mein Ansatz ist besser als das, was viele Leute tun, mit Hash mit der IP. IPs ändern sich viel häufiger als Browserversionen oder Computermonitore. –