Zeitbegrenzte oder einmalige Verwendung von Tokens zum Zurücksetzen des Kennworts?

Ihr Schema funktioniert tatsächlich, aber es gibt einige Punkte, die verbessert werden könnten. Aber zuerst zu Ihrer ursprünglichen Frage nach dem Zeitlimit:

Lassen Sie uns die umgekehrte Frage stellen: Warum sollte ein Token infinit gültig bleiben?

Es hat keinen Vorteil, wenn der Reset-Link zwei Jahre später geklickt werden kann, klickt der Nutzer den Link in etwa einer Stunde an oder hat er den Link wahrscheinlich vergessen (und kann ggf. einen neuen anfordern). Auf der anderen Seite bedeutet das Lesen der E-Mails nicht zwangsläufig, dass ein Angreifer das E-Mail-Konto hacken muss, da ist beispielsweise der offene E-Mail-Client im Büro, ein verlorenes Handy, ein Backup auf dem (verlorenen) USB-Laufwerk ...

Die wichtigste Verbesserung ist, dass Sie nur einen Hash des Tokens in Ihrer Datenbank speichern sollten. Jemand mit Zugriff auf die Datenbank (SQL-Injection), könnte ansonsten für jede E-Mail-Adresse, die er mag, ein Passwort zurücksetzen, und weil er das neue Token sehen kann, könnte er damit sein eigenes Passwort setzen.

Dann würde ich diese Reset-Informationen in einer separaten Tabelle speichern. Dort können Sie die Benutzer-ID, das Hash-Token, ein Ablaufdatum und die Information, ob der Link bereits verwendet wurde, speichern. Der Benutzer befindet sich dann nicht in einem speziellen Status.

Vielleicht habe ich diesen Punkt missverstanden, aber der Reset-Link sollte auf eine spezielle Seite für das Zurücksetzen des Passworts zeigen. Wenn der Benutzer die Anmeldeseite aufruft, sollte keine besondere Behandlung erfolgen. Die Anmeldeseite sollte nicht wissen, dass ein Zurücksetzen des Kennworts aussteht.

Das Reset-Token sollte unvorhersehbar sein, dies kann am besten mit einem wirklich zufälligen Code erreicht werden, der aus der zufälligen Quelle des Betriebssystems liest.

Benutzer vergessen auch, Passwörter zurückzusetzen (Dinge passieren). Da ich über Passwörter paranoid bin, würde ich vorschlagen, die Lebensdauer der Verbindung auf 24 Stunden zu begrenzen. Das sollte mehr als genug sein. Es löst nicht das Problem des böswilligen Abfangens, aber es ist besser als nichts.

Es gibt also ein paar Probleme mit diesem Ansatz, denen ich mich in meinem Kommentar entziehen wollte. Wenn Sie das "Bestätigungs-Token" im Benutzer-Passwort speichern, haben Sie im Grunde nur das Passwort gelöscht.

Ich, eine böswillige Person, kann dann eine große riesige Liste von E-Mail-Adressen und ein Bot-Netz nehmen und Ihren Server mit Passwortzurücksetzungsanfragen überfluten und Ihre Benutzer von ihrem Konto ausschließen. Sicher, Ihre Benutzer erhalten eine E-Mail für das Zurücksetzen, aber wenn ich Passwörter schnell genug zurücksetzen kann, gibt es möglicherweise einen Rückstau von E-Mails (oder, wenn Sie es synchron tun, kann ich wahrscheinlich die gesamte Anwendung tun).

Ich, ein normaler Benutzer Ihres Systems, kann versuchen, mein Passwort zurückzusetzen, und kann nicht herausfinden, warum ich die Reset-E-Mail nicht bekomme, weil ich nicht einmal über einen Spam-Ordner weiß (oder nie angekommen ist) ). Glücklicherweise habe ich mich nur daran erinnert, was das Passwort war, aber es funktioniert nicht mehr, da das Passwort jetzt eine undurchsichtige GUID ist, und ich bin im Grunde tot im Wasser, bis ich die Reset-Email finden kann.

Hier ist der Prozess, den Sie verwenden sollten .

1. Erstellen Sie eine Anforderung zum Zurücksetzen des Kennworts, die Sie mithilfe einer GUID ermitteln, und Sie können dies wahrscheinlich auch sicherstellen, indem Sie diesen Wert mit einigen privaten Daten hashen und diesen auch in der URL übergeben, um einen schnellen Angriff zu vermeiden. Sie können diese Anfrage auch sperren, indem Sie sie nur für eine bestimmte Zeit gültig machen.
2. Sobald jemand diesem Link mit einem gültigen Token und anderen Parametern folgt, die Sie angeben, können Sie das Passwort ändern. Sie können jetzt das Benutzerpasswort sicher ändern .
3. Kennzeichnen Sie die Kennwortanforderung als abgeschlossen, oder löschen Sie sie. Sie können auch Informationen wie die IP-Adresse oder Ähnliches verfolgen, wenn Sie sich wirklich Sorgen darüber machen, wer das Passwort geändert hat, wenn Sie sich wirklich darum sorgen.
4. Schicke dem Nutzer eine E-Mail, in der bestätigt wird, dass er sein Passwort geändert hat.

Auch, falls dies nicht bereits passiert, vergewissern Sie sich, dass Sie Hashing und Salting das Benutzerkennwort verwenden. Es klingt nicht so, als ob Sie das getan hätten, als Sie gerade das Passwort durch eine GUID ersetzt haben, also überprüfen Sie es einfach.

Ich würde folgende Vorschläge machen:

1. Erfordert einige Informationen, bevor der Benutzer auf die Schaltfläche "Passwort vergessen" klicken darf. Zum Beispiel benötigen Sie eine E-Mail-Adresse und ein Geburtsdatum.

   Idealerweise sollte Ihre Benutzerschnittstelle keine Rückmeldung geben, die es einem Hacker ermöglicht, festzustellen, ob seine Rücksetzanforderung erfolgreich war. Sie möchten nicht, dass Ihre Seite für E-Mail-Adressen oder DOBs bearbeitet wird. Dies ist jedoch ein Kompromiss bei der Benutzerfreundlichkeit. Ob Sie dies tun, hängt davon ab, wie viel Sicherheit Sie wirklich benötigen.

   Sie könnten auch in Betracht ziehen, ein Captcha zu benötigen, das Brute-Force- und DoS-Attacken erheblich erschwert.

2. Löse das einmalige Token so schnell wie möglich ab. Ein paar Stunden sind meiner Meinung nach genug. Sie sollten E-Mails niemals als privat betrachten - das ist es nicht, es sei denn, Sie verwenden eine sichere E-Mail-Technologie (z. B. PGP) zusätzlich zum Basisprotokoll (die meisten Leute nicht). Das Letzte, was Sie wollen, ist, dass sich ein Schwarzmarkt dort öffnet, wo Ihre GUIDs gekauft und verkauft werden. Genau das könnte passieren, wenn sie eine unendliche Lebensdauer haben.

3. Verwenden Sie keine GUIDs. Sie sind nicht kryptographisch zufällig und sind ratenswert. Ich schlage vor, Sie verwenden einen kryptografischen Zufallszahlengenerator und übersetzen ihn in base64.