Frage:
Links zum Zurücksetzen des Passworts: Zufallswert oder authentifizierte Nachricht?
John
2013-02-23 04:31:02 UTC
view on stackexchange narkive permalink

Was ist besser?

  1. Erstellen Sie ein manipulationssicheres Token zum Zurücksetzen des verschlüsselten Kennworts, das die Benutzer-ID und die Ablaufzeit innerhalb des verschlüsselten Tokens enthält.

  2. Generieren Sie ein zufälliges Token und speichern Sie es mit der Benutzer-ID und dem Ablaufdatum in der Datenbank. Suchen Sie nach dem Token, wenn der Benutzer auf den Link klickt.

  3. ol>

    Ein Vorteil, den ich bei Nummer 2 sehen kann, ist, dass Sie die Kontrolle über diese Token behalten. Wenn Sie es früher ablaufen lassen möchten, können Sie. Eine Schwierigkeit, die ich bei Nummer 1 sehe, besteht darin, sicherzustellen, dass die von Ihnen gesendeten Token wirklich sicher und manipulationssicher sind. Sie verlassen sich ganz darauf, die Kryptografie nicht zu vermasseln.

    Verfügt ASP.NET 2.0 über eine integrierte Methode zum Generieren von Token zum Zurücksetzen von Kennwörtern?

Ein Vorteil von # 2, den Sie verpasst haben: Sie können das Token bei Verwendung ungültig machen und sicherstellen, dass es nur einmal verwendet wird.
Fünf antworten:
Eric
2013-02-23 05:28:44 UTC
view on stackexchange narkive permalink

Das Erstellen eines zufälligen Tokens, das absolut keine Informationen enthält, und das Verknüpfen in der Datenbank mit einem Benutzernamen und einer Ablaufzeit ist bei weitem die beste Lösung.

Verschlüsselung (und Hashing) wird zum Speichern und Übertragen von Daten verwendet, die unbedingt gesendet werden müssen. Wenn es eine Möglichkeit gibt, etwas zu tun, ohne diese verschlüsselten oder nicht verschlüsselten Daten senden zu müssen, die gleiche Funktionalität und Sicherheit bieten, sollten Sie diese Methode verwenden. Mit anderen Worten, die Verschlüsselung sollte ein letzter Ausweg für die Datensicherung sein.

Einfache, effektive Argumentation.
Tinned_Tuna
2013-02-23 14:35:21 UTC
view on stackexchange narkive permalink

Diese Token sind Kennwortäquivalente und müssen als solche ähnliche Anforderungen erfüllen. Das mit Abstand größte ist jedoch, dass es von einem Gegner nicht willkürlich erraten werden darf. Es sollte daher nicht von zufälligen Daten zu unterscheiden sein.

Wenn Sie Daten codieren, müssen diese offensichtlich verschlüsselt werden. Dies beinhaltet wahrscheinlich ein gewisses Maß an Eigenwerbung oder zumindest das Zusammensetzen der Krypto-Grundelemente selbst, was Sie wahrscheinlich falsch machen werden (siehe: Sei kein Dave).

Dies bedeutet, dass Ihre sicherste und einfachste Lösung darin besteht, ein sehr zufälliges Token zu erstellen und es in der Datenbank sowie eine ID für dieses Token zu speichern. Verbinden Sie die ID und das Token, serialisieren Sie sie in hex oder Base32 und senden Sie sie an den Benutzer. Wenn das Token wieder eingeht, verwenden Sie die ID, um das Token / Salt aus der Datenbank zu holen, und hashen Sie den Rest des Tokens, um festzustellen, ob es übereinstimmt.

Sie müssen einige zusätzliche Dinge über Token sicherstellen, da diese in den E-Mails der Benutzer enthalten sind.

  • Stellen Sie sicher, dass sie eine Entropie haben, die hoch genug ist, um nicht zu raten
  • Sie müssen kurz genug sein, um bequem in eine URL zu kodieren.
  • Sie müssen nach einem relativ kurzen Zeitfenster ablaufen, da sie sich in den E-Mail-Posteingängen der Benutzer befinden.
  • Sie dürfen nur einmal verwendet werden
Warum muss der Token gesalzen werden? Ich dachte, der Zweck des Salting bestand darin, im Falle einer großen Passwortverletzung zu verhindern, dass bei einem geknackten Passwort sofort dasselbe Passwort in der Liste geknackt wird, wenn mehrere Personen dasselbe Passwort gewählt haben. In diesem Fall wäre das Token kryptografisch zufällig, eindeutig ... (Ich verstehe, dass es gehasht wird, um im Falle einer SQL-Injection-Sicherheitsanfälligkeit einen gewissen Schutz zu bieten).
Die Grundidee besteht darin, das Token (das einem Kennwort entspricht) mit der gleichen Schutzstufe zu verteidigen, die mit dem Schutz eines Kennworts einhergeht. Sie sollten auch sehr vorsichtig sein, wenn Sie Angriffe gegen die einmaligen Token steuern.
Jeff Ferland
2013-02-23 04:56:05 UTC
view on stackexchange narkive permalink

Sie können die Ablaufzeit in ein Token codieren und einen HMAC verwenden. Im Allgemeinen umfasst das Zurücksetzen des Kennworts jedoch den Besuch einer bestimmten URL. Um dem Benutzer die Arbeit zu erleichtern, wird das Token normalerweise als GET-Feld in die URL eingefügt.

Wenn Sie die URL relativ klein halten und nur aus druckbaren Zeichen bestehen möchten, würden Sie den Zeitstempel wahrscheinlich als codieren eine Ganzzahl und verwenden Sie Einstellungen mit fester Breite. Dies muss den Benutzer, den Ablauf und den MAC angeben. Ich würde es als zuverlässig bezeichnen, aber es ist nicht ohne Codierungsaufwand.

Da Sie ohnehin eine Datenbank für Kennwörter aufrufen müssen und keine Überlegungen erforderlich sind, um einen zufälligen Wert mit fester Breite zu codieren Aber ich würde einfach damit anfangen. Wenn alles andere gleich ist (und ich denke, es ist ziemlich gleich), gewinnt easy. Zusätzlicher Bonus: geringere CPU-Auslastung.

Tom Leek
2013-02-23 05:34:53 UTC
view on stackexchange narkive permalink

Es ist ein allgemeines Thema. Ihr Szenario Nr. 1 ist eine Speicheroptimierung gegenüber Szenario Nr. 2. In # 2 müssen Sie eine Server-Seite mit zufälligen Werten generieren und speichern. Dies gibt Ihnen alle Kontrolle, die Sie möchten, erfordert jedoch eine zusätzliche Spalte in Ihrer Datenbank oder ähnliches. Das Szenario entlädt diese Speicheranforderung clientseitig. Da dem Client nicht vertraut werden kann, müssen Sie dem Link eine Integritätsprüfung hinzufügen, d. H. Einen MAC; Eine Verschlüsselung ist nicht erforderlich, da der Reset-Link nichts enthält, was Sie vor dem Benutzer geheim halten müssen (der Benutzer kennt seinen Namen bereits und als er nach einem Zurücksetzen des Kennworts gefragt hat), aber Sie möchten verhindern, dass ein böswilliger Client eine Fälschung erstellt Link zurücksetzen, daher der MAC.

Der Token-Inhalt in Szenario 1 muss daher alle Daten enthalten, die Sie zum Durchsetzen Ihrer Richtlinie zum Zurücksetzen des Kennworts benötigen, jedoch nicht auf dem Server gespeichert werden. Dies bedeutet den Benutzernamen und einen Zeitstempel (Zeitpunkt, zu dem der Vorgang zum Zurücksetzen des Kennworts ausgelöst wurde, oder Ablaufzeit). Möglicherweise möchten Sie einen Hash des vorherigen Kennworts in die Eingabe in den MAC einfügen (nicht unbedingt in das Token), wenn Sie verhindern möchten, dass der Benutzer den Reset-Link mehrmals wiederverwendet.

Berechnen und Überprüfen von a MAC benötigt nicht viele Ressourcen, wahrscheinlich ein bisschen weniger als das Generieren eines zufälligen Tokens und das Speichern in einer Datenbank (der Datenbankzugriff ist erheblich teurer als die Kryptografie). Es besteht jedoch die Möglichkeit, dass dieser Effekt ohnehin vernachlässigbar ist (Datenbanken sind schnell). Ein Nachteil von Szenario 1 besteht darin, dass Sie einen geheimen Schlüssel auf dem Server aufbewahren müssen, der von den Front-Ends gemeinsam genutzt wird (wenn Sie mehrere haben) und für Neustarts unempfindlich ist (also nicht nur einen Schlüssel im RAM, es sei denn, Sie sind zum Ungültigmachen bereit Alle Links zum Zurücksetzen des Kennworts beim Neustart des Servers) und natürlich vor Lauschangriffen geschützt.

Das zufällige Token (Szenario 2) ist wahrscheinlich einfacher oder, wenn Sie es vorziehen, schwerer zu bekommen falsch . Das ist Grund genug, es zu empfehlen.

Ich mache mir überhaupt keine Sorgen um die Leistung. Unterschiede sind vernachlässigbar. Aber "schwerer falsch zu liegen" ist großartig :-)
null
2013-02-23 19:24:08 UTC
view on stackexchange narkive permalink

Ich empfehle diesen Artikel von Troy Hunt: Alles, was Sie schon immer über das Erstellen einer sicheren Funktion zum Zurücksetzen von Passwörtern wissen wollten

Hier ist, was er über den Umgang mit dem Zurücksetzen von Token sagt :

Wir möchten ein eindeutiges Token erstellen, das als Teil der zurückgesetzten URL in einer E-Mail gesendet und dann mit einem Datensatz auf dem Server neben dem Benutzerkonto abgeglichen werden kann, um das zu bestätigen Der E-Mail-Kontoinhaber ist in der Tat derjenige, der versucht, das Passwort zurückzusetzen. Beispielsweise kann das Token "3ce7854015cd38c862cb9e14a1ae552b" sein und wird in einer Tabelle neben der ID des Benutzers, der den Reset durchführt, und dem Zeitpunkt, zu dem das Token generiert wurde, gespeichert (mehr dazu gleich). Wenn die E-Mail gesendet wird, enthält sie eine URL wie "Zurücksetzen /? Id = 3ce7854015cd38c862cb9e14a1ae552b". Wenn der Benutzer diese lädt, überprüft die Seite das Vorhandensein des Tokens und bestätigt folglich die Identität des Benutzers und lässt das Kennwort zu geändert werden.

Es gibt auch einen Spickzettel im OWASP-Wiki: Passwort-Spickzettel vergessen, aber sie sagen nicht, ob es besser ist oder nicht, den zu speichern Informationen in der Datenbank.

Lesen Sie bereits seinen Artikel. Das hat die Frage aufgeworfen. Er gibt nicht an, welche Strategie bevorzugt wird.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...