Frage:
Kann jemand Referenzen für die ordnungsgemäße Implementierung von Mechanismen zum Zurücksetzen von Selbstkennwörtern für Webanwendungen bereitstellen?
bdg
2011-01-28 04:39:03 UTC
view on stackexchange narkive permalink

Wir implementieren das Zurücksetzen des Selbstkennworts in einer Webanwendung und ich weiß, wie ich dies tun möchte (zeitlich begrenzte URL zum Zurücksetzen des Kennworts per E-Mail an die vorregistrierte E-Mail-Adresse des Benutzers).

Mein Problem ist, dass ich keine Referenzen finden kann, die die Entwickler auf diese Technik hinweisen. Kann mich jemand auf einige gute Referenzen zu dieser Technik hinweisen?

Welche Programmiersprache verwenden Sie?
Siehe auch eine [ähnliche Frage] (http://stackoverflow.com/q/664673/10080) zu SO.
Siehe: [Passwort vergessen · OWASP-Spickzettel-Serie] (https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html)
Acht antworten:
D.W.
2011-01-30 12:05:38 UTC
view on stackexchange narkive permalink

Einige Vorschläge:

Setzen Sie das Kennwort des Benutzers erst zurück, wenn es bestätigt wurde. Setzen Sie das Kennwort des Benutzers nicht sofort zurück. Setzen Sie es erst zurück, wenn der Benutzer auf einen Bestätigungslink klickt, der an seine vorregistrierte E-Mail-Adresse gesendet wurde.

CAPTCHA erforderlich. Wenn ein Benutzer das Zurücksetzen seines Kennworts anfordert, erzwingen Sie ihn ein CAPTCHA zu lösen, bevor Sie fortfahren. Dies soll verhindern, dass automatisierte Tools versuchen, vielen Benutzern Kummer zu bereiten, und den Benutzer dazu zwingen, zu beweisen, dass sie ein Mensch (kein Roboter) sind.

Zufälligkeit. Die zeitlich begrenzte Die URL zum Zurücksetzen des Kennworts sollte eine zufällige, nicht erratbare Komponente enthalten. Stellen Sie sicher, dass Sie Zufälligkeit in Kryptoqualität verwenden. Die Ausgabe von / dev / urandom oder System.Security.Cryptography.RNGCryptoServiceProvider wäre eine gute Wahl. Die Ausgabe von rand () oder random () oder System.Random ist nicht zufällig genug und wäre eine schlechte Wahl. Eine GUID oder ein Zeitstempel ist nicht zufällig genug und wäre keine gute Wahl.

Geben Sie ein Zeitlimit an. Der Link zum Bestätigen des Zurücksetzens sollte nach einer angemessenen Zeit ablaufen: beispielsweise 24 Stunden . Der Link sollte nur einmal verwendbar sein und sofort ablaufen, sobald er verwendet wird.

Fügen Sie der E-Mail einen erläuternden Text hinzu. Möglicherweise möchten Sie dem Text einen erläuternden Text hinzufügen E-Mail, um zu erklären, warum die E-Mail gesendet wurde, falls jemand einen Reset für ein Konto anfordert, das nicht Ihr eigenes ist. Sie können einen Text wie "Jemand hat angefordert, dass das Passwort für Ihr Konto Benutzername auf der Site zurückgesetzt wird. Wenn Sie diese Anfrage gestellt haben, klicken Sie hier, um Ihr Passwort zu ändern. Wenn Wenn Sie diese Anforderung nicht gestellt haben, klicken Sie hier, um die Anforderung abzubrechen. "

E-Mail senden, nachdem das Kennwort zurückgesetzt wurde. Wenn das Kennwort erfolgreich zurückgesetzt wurde, senden Sie eine E-Mail an den Benutzer an Lassen Sie sie wissen, dass das Passwort geändert wurde. Fügen Sie das neue Passwort nicht in diese E-Mail ein.

Stornierungen überwachen. Sie können eine Logik einfügen, um die Häufigkeit zu überwachen, mit der Benutzer auf den Stornierungslink klicken, um anzuzeigen, dass sie keinen Reset angefordert haben. Wenn dies einen bestimmten Schwellenwert überschreitet, kann es nützlich sein, eine Warnung an die Systembetreiber zu senden. Wenn ein Stornierungslink für eine Anfrage nach dem Bestätigungslink besucht wird, ist dies ein möglicher Hinweis auf einen Angriff auf diesen Benutzer. Möglicherweise möchten Sie an diesem Punkt Maßnahmen ergreifen, z. B. ungültig machen das Passwort des Benutzers und fordern Sie ihn auf, sein Passwort erneut zurückzusetzen. (Dies ist eine Verteidigung gegen den folgenden Angriff: Der Angreifer erhält Zugriff auf das Postfach des Benutzers, fordert das Zurücksetzen seines Kennworts auf Ihrer Site an und besucht dann den Bestätigungslink. Wenn der Angreifer diese E-Mails nicht aus dem Posteingang des Benutzers löscht, Wenn der echte Benutzer dann seine E-Mail liest, klickt er möglicherweise auf den Stornierungslink, um auf mögliche Probleme hinzuweisen.)

Verwenden Sie HTTPS. Der Link sollte https (nicht http) verwenden :), um sich vor verschiedenen Angriffen zu schützen (z. B. Firesheep-Angriffe auf Benutzer, die von einem Internetcafé aus im Internet surfen).

Protokollieren Sie diese Vorgänge. Ich empfehle, alle derartigen Anforderungen zu protokollieren. Zusätzlich zur Protokollierung des Benutzernamens des Benutzers möchten Sie möglicherweise die IP-Adresse des Clients protokollieren, der eine E-Mail an den Benutzer gesendet hat, sowie die IP-Adresse des Clients, der den Rücksetzlink besucht hat.

Zusätzliche Lektüre. Vielleicht möchten Sie auch Troy Hunts hervorragenden Blog-Beitrag lesen, Alles, was Sie schon immer über das Erstellen einer sicheren Funktion zum Zurücksetzen von Passwörtern wissen wollten. Vielen Dank an @coryT für einen Link zu dieser Ressource.

Zuletzt sollten Sie die Nicht-Kennwortauthentifizierung in Betracht ziehen. Kennwörter haben viele Probleme als Authentifizierungsmechanismus, und Sie können andere Methoden zur Authentifizierung von Benutzern in Betracht ziehen, z. B. das Speichern eines sicheren dauerhaften Cookies auf ihrem Computer mit einem nicht erratbaren Wert Geheimnis, um sie zu authentifizieren. Auf diese Weise gibt es kein Passwort zum Vergessen und keine Möglichkeit für den Benutzer, einen Phishing durchzuführen registrierte Emailadresse). Dieses Umfragepapier bietet eine hervorragende Übersicht über viele Fallback-Authentifizierungsmethoden und ihre Stärken und Schwächen.

+1, beachten Sie auch, dass eine GUID * nicht * zufällig genug ist, obwohl sie beliebt ist (wie aus den meisten falschen Antworten [zu dieser SO-Frage] (http://stackoverflow.com/q/664673/10080) hervorgeht) . Außerdem würde ich nur einen Drosselungsmechanismus hinzufügen, d. H. Ein Benutzer kann nicht verlangen, sein Passwort zurückzusetzen, z. 3000 mal in einer Stunde.
Um mein Gespräch mit @avid bei seiner Antwort auf diese Frage zusammenzufassen, würde ich sagen, dass eine GUID der Version 4 in der Tat größtenteils zufällig ist und [ich denke, sie ist lang genug] (http://security.stackexchange.com/questions/). 1952 / wie lange sollte eine zufällige Nonce sein). Aber es ist wahrscheinlich albern und ein bisschen gefährlich zu benutzen, da es ursprünglich nicht für die Aufgabe entwickelt wurde. Und wer weiß, wo Ihr Code als nächstes portiert wird?
Es scheint nicht so, als ob "Wenn Sie diese Anfrage nicht gestellt haben, klicken Sie hier, um die Anfrage abzubrechen" für die E-Mail erforderlich wäre.
@nealmcb Hier ist ein Link von einem Mitglied des C # -Compilerteams, der über GUIDs spricht und sehr stark erwähnt, dass GUIDs keineswegs kryptografisch zufällig sind: http://blogs.msdn.com/b/ericlippert/archive/2012/05 /07/guid-guide-part-three.aspx - Es gab eine andere Studie, die zeigt, dass Windows-GUIDs nicht kryptografisch zufällig sind: http://www.gotdotnet.ru/blogs/denish/1965/ - Fazit: Nicht Verwenden Sie GUIDs für kryptografische Zwecke :) (Ich weiß nicht, ob ein Nicht-Windows-Betriebssystem diesbezüglich Garantien gibt, aber Unices haben normalerweise sowohl / dev / random als auch / dev / urandom)
Wie viele Zeichen sollte der zufällige Teil sein?
"Fügen Sie das neue Passwort nicht in diese E-Mail ein." Wenn Sie das Kennwort des Benutzers im Klartext haben, machen Sie es falsch.
@DavidMurdoch, 64-80 Bit sollten für den zufälligen Teil ausreichend sein. (40 Bit würden für diesen Zweck wahrscheinlich ausreichen, aber warum sollten Sie Risiken eingehen?)
AilitfqyppCMT See the link I posted above for more on D.W.'s answer (i.e. that a nonce of 64 bits is probably fine for this purpose): [How long should a random nonce be? - IT Security](http://security.stackexchange.com/questions/1952/how-long-should-a-random-nonce-be)
AilimkvlgeCMT Thanks for the links, and as I said it is a bad choice. But in terms of assessing the actual risk, Google translate didn't help much with that russian post by Nikolay Denishchenko on something like "Device and cryptanalysis UUID-Generator for Windows". Can you summarize the results in terms of how many unpredictable bits of entropy he thinks Windows version 4 GUIDs have, and how hard it would be to guess them remotely?
coryT
2012-07-20 02:11:58 UTC
view on stackexchange narkive permalink

Troy Hunt hat genau diese Frage sehr gut beschrieben. Alles, was Sie schon immer über das Erstellen einer sicheren Funktion zum Zurücksetzen von Passwörtern wissen wollten

Troys Blog ist eine großartige Ressource für alles, was mit Websicherheit zu tun hat
Jesper Mortensen
2011-04-05 14:25:56 UTC
view on stackexchange narkive permalink

OK, Ihre Frage ist also, wie Sie den Prozess zur Wiederherstellung von Kennwörtern / Konten strukturieren sollten. Dies hängt davon ab, wofür Sie optimieren möchten: problemlose Benutzererfahrung oder gute Sicherheit.

Wenn Sie gute Sicherheit wünschen:

  • Während der Anmeldung muss der Benutzer seine E-Mail-Adresse eingeben.
  • Während der Anmeldung muss der Benutzer einen sekundären Kanal zur Authentifizierung eingeben - Handynummer oder Frage stellen &-Antwort (dh " was ist Mädchenname Ihrer Mutter "oder besser).

  • Während der Wiederherstellung erhält Ihr System zunächst eine grobe Überprüfung der Identität mithilfe des oben genannten sekundären Kanals - der Herausforderung Frage oder per SMS an das Mobiltelefon oder ähnliches.

  • Wenn die erste oben genannte Identitätsprüfung abgeschlossen ist, sendet das System eine E-Mail zum Zurücksetzen des Kennworts nur an die zuvor eingegebene E-Mail-Adresse . Dies ist eine zusätzliche wichtige Maßnahme, um f.x. Exploits vom Typ Sarah Palin.

  • Die E-Mail darf kein neues Kennwort oder ähnliches enthalten. Es sollte einen anklickbaren Link zu einer HTTPS-verschlüsselten Webseite auf Ihrer Website enthalten, die a) über einen nicht erratenen geheimen Wert in der URL b) mit dem Konto verknüpft ist em> ist zeitlich begrenzt, sodass die Kontowiederherstellung nur x Stunden nach der Anforderung funktioniert. c) bietet dem Endbenutzer die Möglichkeit, ein neues Kennwort zu erstellen.

  • Haben Sie eine gute Protokollierung aller Transaktionen zum Zurücksetzen des Kontos und lassen Sie diese von einem Menschen tatsächlich überwachen und handeln, wenn sie verdächtig erscheinen (überprüfen Sie die Serverprotokolle auf die IP-Adressen fx, do Viele Anfragen kommen von derselben IP-Adresse. Gibt es Fälle, in denen ein Benutzer versucht, Kennwörter aus einem anderen Land als dem des registrierten Kontoinhabers usw. zurückzusetzen?

Sie können diese Komplexität auch ganz umgehen: Es ist noch sehr früh, aber OAuth / OpenID / Anmelden über Facebook, Google usw. entfernt diese Komplexität vollständig von Ihren Systemen, aber möglicherweise mit einem weniger gut etablierte Benutzerfreundlichkeit.

Herausforderungsfragen sind das Gegenteil von Sicherheit.
@DavidMurdoch: können Sie eine Referenz bereitstellen, die dies diskutiert? Ich würde gerne mehr darüber lesen.
@David Murdoch: Die Herausforderungsfragen sind passwortäquivalent - aber die Schlüsselfrage ist, wozu. In meinem Schema entsperren sie einen Mechanismus zum Zurücksetzen von Passwörtern, der (vermutlich) * nicht unter der Kontrolle des Angreifers steht *; die ursprüngliche E-Mail-Adresse. Aber wahr, Passwort-Reset-Mechanismen tauschen im Allgemeinen reduzierte Sicherheit gegen erhöhte Benutzerfreundlichkeit aus, vielleicht hätte ich das klarer machen sollen.
Beachten Sie, dass hier in der schillernden Zukunftswelt von 2015 die Verwendung einer Telefonnummer als Teil eines MFA-Schemas irgendwie auseinandergefallen ist, da dasselbe kleine verlierbare Gerät als Gateway für E-Mail und SMS dient.
Rich Homolka
2012-07-23 22:18:52 UTC
view on stackexchange narkive permalink

Jeder Ort, an dem Sie ein Passwort erhalten können, bedeutet, dass das Passwort nicht gehasht wird, sondern dort gespeichert wird, wo es für "Klartext" entschlüsselt werden kann. Dies ist an sich schlecht.

Wahrscheinlich nicht "am sichersten", aber sicherer wäre:

Senden Sie auf Anforderung eines Kennworts einen Link zum Zurücksetzen des Kennworts an den Benutzer mit eingebetteter GUID. Die Sitzung in der GUID läuft in, hmm, Stunde oder so ab.

Yeah no issues with it as I have session protected from SQL injection, so I send mail with well randomised password reset session code and allow hour to change it, that's OK.
@AndrewSmith - Sie sollten dem Benutzer erlauben, das neue Kennwort auszuwählen und es nicht an ihn zu senden, wie bereits erläutert. Wenn Sie das Kennwort an den Benutzer senden können, ist an Ihrem Sicherheitsmodell ein Fehler aufgetreten.
Diese Website generiert derzeit ein NEUES Passwort, sendet es per E-Mail, hasht es und speichert es in db, was meiner Meinung nach nicht gut ist.
Es ist in der Tat eine schlechte Idee, ein Passwort zu generieren und es bei der nächsten Verbindung nicht abzulaufen.
Wenn diese GUID im Klartext vorliegt, kann sie mit SQL Injection abgerufen werden, und dann haben Sie den gesamten Zweck des Passwort-Hashing außer Kraft gesetzt. Dieser Beitrag ist ein gefährlicher Vorschlag aufgrund von Mehrdeutigkeiten.
So I should encrypt well randomized password reset session code and in window of 1h afterwards allow for change - no problem.
Rory Alsop
2011-01-31 01:58:25 UTC
view on stackexchange narkive permalink

Eine andere Möglichkeit, die für Ihre Anwendung geeignet sein kann oder nicht, aber in Online-Banking-Anwendungen und ähnlichen Anwendungen verwendet wird, besteht darin, die Hälfte des Rücksetzcodes per SMS an ein registriertes Mobiltelefon zu senden. Aus der Sicht eines Angreifers ist dies eine vollständige PITA, da einige Kanäle kompromittiert werden müssen, um zu brechen.

Polynomial
2012-07-24 01:31:29 UTC
view on stackexchange narkive permalink

Der sicherste Weg, ein Zurücksetzen des Kennworts durchzuführen, besteht darin, ein großes zufälliges eindeutiges einmaliges Zurücksetzen-Token mit einem Ablaufdatum zu generieren, das an die Benutzer-ID gebunden ist. Das Token sollte in der Datenbank gehasht werden, da ein Angreifer mit SQL-Zugriff damit beliebige Benutzerkennwörter zurücksetzen kann.

Ein Reset-Link sollte an die E-Mail-Adresse gesendet werden, die das Reset-Token enthält. Wenn der Benutzer auf den Link klickt, sollte der Hash des Tokens in der Datenbank gefunden und das Ablaufdatum für die Zukunft überprüft werden. Wenn diese Bedingungen erfüllt sind, sollte dem Benutzer ein Bildschirm angezeigt werden, auf dem er ein neues Kennwort eingeben kann.

Dieser gesamte Vorgang muss über SSL erfolgen, andernfalls muss ein Angreifer Möglicherweise wird die URL beschnüffelt und das Kennwort zurückgesetzt, bevor der Benutzer dies tut.

Einige andere Tipps:

  1. Geheime Fragen stellen einen geringfügigen Ärger für Angreifer und einen großen Ärger für Benutzer dar. Vermeiden Sie sie vollständig.
  2. Stellen Sie den Benutzer vor dem Senden des Kennwort-Resets vor eine Herausforderung zur Überprüfung durch den Menschen (z. B. ein CAPTCHA). Dies verhindert automatische Rücksetzanforderungen.
  3. Überprüfen Sie, ob die IP-Adresse, die das Zurücksetzen durchführt, zuvor erfolgreich beim Konto angemeldet wurde. Wenn dies nicht der Fall ist, fragen Sie nach weiteren Details zum Konto / Benutzer, z. Erstellungsjahr des Kontos, Geburtsdatum, erste Adresszeile.
  4. Fügen Sie einen Link "Ich habe nicht nach dieser E-Mail gefragt" hinzu, damit Benutzer fehlerhafte Anfragen zum Zurücksetzen des Passworts melden können.
  5. ol >
Even if it is generated via SSL: you have no insurance that the e-mail itself is transferred over SSL and so this method has a huge flaw in transit -- the basic flaw of e-mail relay and retrieval.
@EvanCarroll "_der grundlegende Fehler bei der Weiterleitung von E-Mails und beim Abrufen von E-Mails ** ._" beim Abrufen von E-Mails **: Es liegt in der Verantwortung des Benutzers, eine E-Mail-Wiederherstellungsadresse von einem E-Mail-Anbieter mit POPS, IMAPS oder zu verwenden HTTPS-Webmail-Support (und die meisten E-Mail-Anbieter bieten heutzutage alle drei an).
@EvanCarroll Obwohl dies keine ideale Situation ist, ist Sicherheit * immer * sekundär zur Benutzerfreundlichkeit. Wenn Sie die weltweit sicherste Browser-Anmeldung implementieren, für deren Verwendung jedoch JavaScript, Flash, Java, ActiveX, Silverlight und ein Abschluss in Informatik erforderlich sind, werden Ihre Benutzer ausgeschaltet. E-Mail ist der De-facto-Standard für diese Art von Funktionalität, vor allem, weil sie von jedem verwendet werden kann. Die Sicherheitslast für das E-Mail-System und das persönliche Netzwerk eines Benutzers liegt bei mir * nicht * und sollte es auch nicht sein.
@curiousguy Wenn plausible Verleugnung Ihr Ziel ist, dann ja. Wenn Sicherheit Ihr Ziel ist, dann nein.
@polynomial "De-facto" -Standards haben nichts mit Sicherheit zu tun. Dies ist nur ein Argument, um den Status Quo beizubehalten, ohne die Auswirkungen auf die Sicherheit zu berücksichtigen.
AilixmbdrlCMT The argument for the status quo is that there is no acceptable alternative.
Ich stimme Ihrer Antwort zu, aber warum sollten Sie die Benutzer-ID in den Link aufnehmen? Wenn diese Benutzer-ID beispielsweise eine 8-stellige Zahl ist, sind diese 8 Zeichen ebenso leicht zu erraten wie 8 zusätzliche zufällige Zeichen in Ihrem Token. Mit den zufälligen Zeichen würden Sie die Benutzer-ID jedoch nicht verfügbar machen.
AilihuhznqCMT True, but exposing the user ID isn't usually a big deal. You're likely to do it through the interface to your site anyway - look at StackExchange. Question 17542, answer 17547, your comment is 28508, you're user 8343, I'm user 5400, OP is user 10787. Trying to hide that info is difficult and would only introduce obscurity. In this case, though, the tokens should be unique, so the search should always return a single row regardless of whether the user ID is in the link.
frank
2011-04-06 10:36:01 UTC
view on stackexchange narkive permalink

2-Faktor-Authentifizierung per SMS! Wenn Sie den Kunden und seine Handynummer kennen, senden Sie ihm einen eindeutigen Code, der der Website hinzugefügt werden muss, um zu bestätigen, dass er es ist :)

Das ist nicht unbedingt eine 2-Faktor-Lösung, aber sie ist außerhalb des Bandes.
Bis jemand sein Handy stiehlt.
Andrzej Bobak
2012-07-24 19:28:06 UTC
view on stackexchange narkive permalink

Machen Sie ein paar Schritte. Zum Beispiel:

  1. Benutzer vergisst sein Passwort. Er klickt auf die Schaltfläche "Ich habe mein Passwort vergessen, sende mir eine E-Mail, was als nächstes zu tun ist" (Tastenbeschriftung kann abweichen;))
  2. Ihr Server sendet ihm einen Link www.yourdomain.com/lostpassword?param_1 = x; param_2 = y
  3. Er klickt auf den Link und kann sich ein neues Passwort erstellen.
  4. Er klickt auf Senden. Alles getan. Alle glücklich
  5. ol>

    Ein einziger Fang ist in Punkt 3). X- und Y-Werte sollten zufällig, unvorhersehbar und mit diesem einen bestimmten Konto verbunden sein. Sie sollten auch nur einmal verwendet werden und nach kurzer Zeit (24 Stunden?) Veraltet sein. Speichern Sie beide Werte in einer dedizierten Tabelle mit den entsprechenden Spalten:

      | some_id | user_id | X | Y | expire_time  

    Wenn ein Benutzer versucht, den richtigen Link zu verwenden, prüfen Sie, ob die Ablaufzeit nicht eingehalten wird, und erlauben Sie ihm, das Kennwort zu ändern, wenn dies nicht der Fall ist.

Wie unterscheidet sich das von den anderen Antworten? Es hat keinen Vorteil, sowohl X als auch Y zu haben. Verwenden Sie einfach einen einzelnen Zufallswert.
OK cool, aber wie sicher ist es gegen SQL Injection? Liegt es an einem dedizierten Tisch?
AiliqqhqwsCMT one value is easy to break via brute force attack.
AilihitrfoCMT you prevent yourself from an sql injection in a complete different way. It's how you filter user input and how you pass it to your queries.
@AndrzejBobak: Zwei Werte lassen sich genauso leicht durch Brute-Force durchbrechen wie ein Wert, der doppelt so lang ist wie beide.


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 2.0-Lizenz, unter der er vertrieben wird.
Loading...