Zeitlich begrenzte oder einmalige Nutzung, Passwort-reset-Token?

Benutzer Ihre Kennwörter vergessen, und (fast) alle Mitglieder-Seiten benötigen einen Weg, um Benutzern zu helfen, wieder in.

Ich würde gerne für die Umsetzung der gemeinsamen Szenario:

  1. Nutzer die Website versucht, sich in, können nicht, und erkennt, dass Sie Passwort vergessen - Mist!
  2. Benutzer E-Mail-Adresse und klickt auf "Passwort vergessen"
  3. Benutzer erhält E-Mail mit einem link zum zurücksetzen des Kennworts

Hier ist, wie ich bin Planung um dies zu implementieren (C#/ASP.NET MVC):

  1. Wenn der Benutzer E-Mail-und trifft auf "Passwort vergessen" meine Website " wird eine GUID generiert, speichern Sie Sie auf das Element Person in der DB (member.ResetToken), und per E-Mail einen link mit dieser GUID in der url (die E-Mail gesendet wird, informieren Sie Sie über diesen link können nur ein mal)
  2. Benutzer auf den link klickt und meine Seite sieht bis Ihr Konto auf der Basis, dass member.ResetToken aus der url. Wenn Ihr Konto gefunden wird, zeigen Sie ein Passwort-reset-Formular, und wenn Sie die reset-löscht es den member.ResetToken von Ihrem Konto.

Hier ist meine Frage: halten Sie es wie diese (in dem er sein Kennwort zurücksetzen kann mit diesem link jederzeit, jetzt oder in Zukunft) oder einen Zeitstempel hinzufügen zu begrenzen, wie lange Sie haben, um Ihr Kennwort zurückzusetzen?

Aus UX-Perspektive die Möglichkeit, Ihr Kennwort zurückzusetzen, wenn Sie bereit sind, groß ist, aber ich möchte sicherstellen, dass ich bin nicht Blick auf einige Sicherheits-Probleme, die diese aufwerfen könnte.

  • Generieren eines reset-Anfrage und E-Mail es heraus und machen Sie in der Zeit beschränkt, aber nicht das Passwort ändern. Durch ändern von Passwort und senden von out-reset, es ' s einfach zu blow out someones Passwort 🙂
  • Das ist nicht das, was ich beschrieben habe. 😉 Das Kennwort wird vom Benutzer geändert. Eine url mit Passwort-reset-token per post zu Ihnen, wenn Sie klicken Sie auf die "Passwort vergessen" - button. Die GUID ist die Passwort-reset-token (obwohl ich wahrscheinlich nicht verwenden eine GUID, aber etwas mehr random). Ich bin gefragt, ob eine einmalige Nutzung token ist ausreichend sicher im Vergleich eine zeitlich begrenzte token. Trotzdem danke.
  • Ja, ich habe verstanden, was Sie gesagt haben, schauen Sie sich meine Antwort.
InformationsquelleAutor Chaddeus | 2013-10-09
  1. 9

    Ihrem System tatsächlich funktioniert, aber es gibt einige Punkte, die verbessert werden könnten. Aber zuerst zu deiner ursprünglichen Frage über die Frist:

    Lassen Sie uns Fragen, die entgegengesetzte Frage: Warum sollte ein token bleibt gültig, infinit?

    Gibt es keinen Vorteil, wenn der reset-link kann angeklickt werden, zwei Jahre später, entweder der Benutzer auf den link klickt, in etwa einer Stunde oder er hat es wohl vergessen, über den link (und kann ein neues anfordern, falls erforderlich). Auf der anderen Seite, ist in der Lage, um die e-Mail Lesen, bedeutet nicht notwendigerweise, dass ein Angreifer muss hack der e-mail-Konto, gibt es zum Beispiel das öffnen von e-mail-client im Büro, ein verlorenes Handy, ein backup auf der (verlorenen) USB-Laufwerk...

    Ist die wichtigste Verbesserung ist, dass Sie sollten nur speichern hash der token in der Datenbank. Jemand mit Zugriff auf die Datenbank (SQL-injection), können sonst verlangen, ein Passwort-reset für alle e-mail-Adresse, die er liebt, und weil er das neue token, er kann es benutzen, um sein eigenes Passwort.

    Dann würde ich diese lagern reset-Informationen in einer separaten Tabelle. Dort können Sie speichern Sie die Benutzer-id, die Hash-token, ein Ablaufdatum und die information, ob der link wurde bereits verwendet. Der Benutzer ist nicht in einem besonderen Zustand dann.

    Vielleicht habe ich missverstanden diesem Punkt, aber die reset-link auf eine spezielle Seite zum zurücksetzen des Kennworts. Wenn der Anwender geht auf die login-Seite sollte es keine Besondere Behandlung, die login-Seite sollte nicht bewusst sein, dass es eine ausstehende Passwort-reset.

    Den reset-token sollte unberechenbar sein, dies kann erreicht werden, am besten mit einer wirklich zufälligen code, Lesung aus dem random-source-Betriebssystem.

    • Interessante Idee, nur die Speicherung der token-hash. Dazu müsste ein Angreifer Zugriff auf den Hash-Algorithmus auf die Taste, um zum generieren eines token. Danke.
    • Ein hash-Algorithmus muss nicht einen Schlüssel, es ist ein one-way-operation, so ist es nicht möglich, den ursprünglichen text, wenn Sie nur den hash. Was Sie wohl im Sinn haben-Verschlüsselung, dies ist ein zwei-Wege-Betrieb, und braucht einen Schlüssel.
    • Du hast natürlich Recht, die hashing-Algorithmus, der selbst nicht die Verwendung eines Schlüssels, aber wenn Sie eine HMAC-Funktion können Sie generieren ein one-way-signierte Hashwert mit einem geheimen Schlüssel. Ich dachte, der Verwendung von HMAC-SHA256-wie PHP hash_hmac.
    • Es ist auch erwähnenswert, dass wenn Sie diese Methode verwenden, sollten Sie einen langsam-Vergleich-Funktion bei der überprüfung der hash zu vermeiden-timing-Angriffe schützt.
    • Ja, Sie können mit einem HMAC-aber der Vorteil ist nicht sehr groß, wichtig ist nur, dass man nicht fälschen kann ein token, was in der gleichen hash als die gespeicherten. Eine timing-attack ist nicht ein problem hier, denn der server ist der Vergleich der hash-Werte, nicht der nur-Text-Token. Aus einer ähnlichen hash-Wert, können Sie keine Rückschlüsse auf die ähnlichkeit der Token.
    InformationsquelleAutor martinstoeckli
  2. 2

    So, es gibt ein paar Probleme mit diesem Ansatz, dass ich versucht habe, zu entziehen, um in meinen Kommentar. Wenn Sie speichern Sie die "Bestätigungs-token" in das Benutzer-Passwort, Sie haben gerade im Grunde zerstört Ihr Passwort.

    Ich eine böswillige person, kann man dann auch eine Riesen Liste von E-Mail-Adressen und ein bot-Netz und Flut Ihre server mit Passwort-reset-Anfragen, und sperren Sie Ihre Benutzer aus Ihrem Konto. Sicher, die Benutzer erhalten eine E-Mail für das zurücksetzen, aber wenn ich die Passwort-reset-schnell genug, kann es zu einem Rückstau von E-Mails (oder, wenn du es synchron ist, kann ich wahrscheinlich DoS die gesamte Anwendung).

    Ich, ein normaler Benutzer des Systems, der versuchen kann um mein Passwort zurückzusetzen, und kann nicht herausfinden, warum ich bin nicht immer die reset-E-Mail, weil ich nicht einmal weiß, über einen spam-Ordner (oder es nie angekommen). Zum Glück, mir ist gerade eingefallen, was das Passwort war, aber es funktioniert nicht mehr, da das Kennwort ist jetzt ein deckend-GUID, und ich bin im Grunde tot im Wasser, bis ich den reset-E-Mail.

    Hier ist der Prozess, den Sie sollte verwenden.

    1. Generieren Sie ein Passwort-reset-Anfrage, die Sie nachschlagen mithilfe einer GUID, und Sie könnte wahrscheinlich auch sichern diese durch Vermischung dieser Wert mit einigen privaten Daten und übergabe in der URL als auch zu vermeiden, einen schnellen Angriff. Sie können auch sperren Sie diesen Antrag herunter, indem Sie es nur für eine gewisse Zeit.
    2. Mal jemand folgt dem link mit einem gültigen token und alle anderen Parameter, die Sie angeben, können Sie dann ändern Sie das Kennwort, an welcher Stelle Sie können sich nun sicher ändern Sie das Benutzer-Passwort.
    3. Flagge der Passwort-Anforderung als abgeschlossen oder löschen. Man könnte auch den track-Informationen wie IP-Adresse oder etwas ähnliches, wenn Sie wirklich besorgt über die änderung des Passwortes, wenn Sie wirklich besorgt über es.
    4. Senden Sie dem Benutzer eine E-Mail mit der Bestätigung, dass Sie haben Ihr Kennwort geändert.

    Auch, nur falls dies nicht geschieht bereits, stellen Sie sicher, dass Sie hashing und salting das Benutzer-Passwort. Es klingt nicht wie Sie waren, dies zu tun, wenn Sie waren einfach ersetzen Sie das Kennwort mit einer GUID, so doppelklicken Sie einfach überprüfen.

    • Die token ersetzt nicht das Passwort des Benutzers. Es ist eine separate Eigenschaft des betreffenden Objekts (member.ResetToken). Wenn der Benutzer auf "Kennwort zurücksetzen" wird der url in Ihrer E-Mail, meine site lookup wird Ihr Konto durch die ResetToken. Wenn das Konto gefunden wird, zeigen Sie ein Passwort-reset-Formular. Sobald das Mitglied setzt Ihr Kennwort, entfernen Sie das token von Ihrem Konto. Wenn Sie versucht, das Passwort zurücksetzen url wieder es würde nicht funktionieren, weil Ihr Konto nicht gefunden werden. Vielen Dank, sorry, wenn meine Wortwahl Sie verwirrt.
    • Ich aktualisiert meine Frage zu verdeutlichen.
    InformationsquelleAutor Darren Kopp
  3. 1

    Benutzer auch vergessen zum zurücksetzen von Kennwörtern (Dinge geschehen). Paranoid über Kennwörter, würde ich vorschlagen, dass die Begrenzung der link-Lebensdauer zu 24 Stunden. Dies sollte mehr als genug sein. Es löst nicht das problem der bösartigen abzufangen, aber es ist besser als nichts.

    InformationsquelleAutor Alexander L. Belikoff
  4. 1

    Möchte ich folgende Vorschläge:

    1. Erfordern einige Stück von Informationen, bevor der Benutzer berechtigt ist, klicken Sie auf den Passwort vergessen button. Zum Beispiel, benötigen Sie eine E-Mail-Adresse und Geburtsdatum.

      Idealerweise Ihre Benutzeroberfläche sollte nicht jede Rückmeldung, die es dem hacker ermöglicht, festzustellen, wenn sein reset-Anfrage erfolgreich war. Sie nicht wollen, dass die Landwirtschaft Ihre Seite für E-Mail-Adressen oder Dobsen. Dies ist jedoch ein usability-Kompromiss, so, ob Sie dies tun hängt davon ab, wie viel Sicherheit Sie wirklich brauchen.

      Könnten Sie auch erwägen, die eine captcha-das macht brute-force-und application-DoS-Attacken sehr viel schwieriger.

    2. Erlöschen der one-time-token, so schnell wie möglich. Ein paar Stunden reicht meiner Meinung nach. Sie sollten nie in Betracht, die E-Mail zu privaten-- es ist nicht, es sei denn, Sie sind über eine sichere E-Mail-Technologie (z.B. PGP) auf das Basis-Protokoll (die meisten Menschen tun dies nicht). Das Letzte, was Sie wollen, ist für einen schwarzen Markt zu öffnen, wo Sie Ihre GUIDs werden gekauft und verkauft, das ist genau das, was passieren könnte, wenn Sie haben unbegrenzte Lebensdauer.

    3. Nicht die Verwendung von GUIDs. Sie sind nicht kryptographisch zufällig und sind guessable. Ich schlage vor, Sie verwenden einen kryptografischen Zufallszahlengenerator und übersetzen Sie es in base64.

    InformationsquelleAutor John Wu
Schreibe einen Kommentar