Frage Der definitive Leitfaden zur formularbasierten Website-Authentifizierung [geschlossen]


Formularbasierte Authentifizierung für Websites

Wir sind der Meinung, dass Stack Overflow nicht nur eine Ressource für sehr spezifische technische Fragen sein sollte, sondern auch allgemeine Richtlinien zur Lösung von Variationen bei häufig auftretenden Problemen. "Formularbasierte Authentifizierung für Websites" sollte ein gutes Thema für ein solches Experiment sein.

Es sollte Themen enthalten wie:

  • Wie man sich anmeldet
  • Wie man sich ausloggen kann
  • Wie bleibt man eingeloggt?
  • Cookies verwalten (einschließlich empfohlener Einstellungen)
  • SSL / HTTPS-Verschlüsselung
  • Wie man Passwörter speichert
  • Verwenden geheimer Fragen
  • Benutzername und Passwort vergessen
  • Gebrauch von Nonzen verhindern Cross-Site-Request-Fälschungen (CSRF)
  • OpenID
  • "Remember me" Kontrollkästchen
  • Browser automatische Vervollständigung von Benutzernamen und Passwörtern
  • Geheime URLs (öffentlich URL durch Digest geschützt)
  • Überprüfen der Passwortstärke
  • E-Mail-Validierung
  • und viel mehr darüber  formularbasierte Authentifizierung...

Es sollte keine Dinge wie beinhalten:

  • Rollen und Berechtigungen
  • HTTP-Standardauthentifizierung

Bitte helfen Sie uns durch:

  1. Unterthemen vorschlagen
  2. Gute Artikel zu diesem Thema einreichen
  3. Bearbeiten der offiziellen Antwort

4992


Ursprung


Antworten:


TEIL I: Wie man sich anmeldet

Wir nehmen an, dass Sie bereits wissen, wie Sie ein Login + Passwort-HTML-Formular erstellen, das die Werte an ein Skript auf der Serverseite zur Authentifizierung sendet. Die folgenden Abschnitte befassen sich mit Mustern für eine fundierte praktische Authentifizierung und die Vermeidung der häufigsten Sicherheitslücken.

Zu HTTPS oder nicht zu HTTPS?

Sofern die Verbindung nicht bereits sicher ist (dh über HTTPS mit SSL / TLS getunnelt), werden Ihre Anmeldeformularwerte in Klartext gesendet, sodass jeder, der die Verbindung zwischen Browser und Webserver überwacht, Logins lesen kann, wenn sie übergeben werden durch. Diese Art des Abhörens wird routinemäßig von Regierungen durchgeführt, aber im Allgemeinen werden wir die "eigenen" Kabel nicht anders behandeln, als dies zu sagen: Wenn Sie etwas Wichtiges schützen, verwenden Sie HTTPS.

Im Wesentlichen, das einzige praktisch Schutz vor Abhören / Paketschnüffeln während der Anmeldung besteht in der Verwendung von HTTPS oder einem anderen zertifikatbasierten Verschlüsselungsschema (z. B. TLS) oder ein bewährtes und erprobtes Challenge-Response-Schema (zum Beispiel Diffie-HellmanSRP). Jede andere Methode kann leicht umgangen werden durch einen abhörenden Angreifer.

Wenn Sie bereit sind, ein wenig unpraktisch zu werden, können Sie natürlich auch ein Zwei-Faktoren-Authentifizierungsschema verwenden (z. B. die Google Authenticator-App, ein physisches "Cold War Style" -Codebuch oder einen RSA-Key-Generator-Dongle). Bei korrekter Anwendung könnte dies sogar mit einer unsicheren Verbindung funktionieren, aber es ist schwer vorstellbar, dass ein Entwickler bereit wäre, eine Zwei-Faktor-Authentifizierung, aber nicht SSL, zu implementieren.

(Do not) Roll-your-own JavaScript-Verschlüsselung / Hashing

Angesichts der Kosten, die nicht Null sind und der technischen Schwierigkeit, ein SSL-Zertifikat auf Ihrer Website einzurichten, sind manche Entwickler versucht, ihre eigenen In-Browser-Hashing- oder Verschlüsselungsschemata zu verwenden, um Klartext-Logins über eine ungesicherte Leitung zu vermeiden.

Während dies ein edler Gedanke ist, ist es im Wesentlichen nutzlos (und kann ein Sicherheitsfehler) es sei denn, es wird mit einem der oben genannten kombiniert, das heißt entweder die Linie mit starker Verschlüsselung sichern oder einen erprobten Challenge-Response-Mechanismus verwenden (wenn Sie nicht wissen, was das ist, wissen Sie, dass es eins ist) der am schwierigsten zu bearbeitenden, am schwierigsten zu gestaltenden und am schwierigsten zu implementierenden Konzepte der digitalen Sicherheit).

Es stimmt zwar, dass das Passwort hasht kann sein wirksam gegen Passwort-Offenlegunges ist anfällig für Replay-Angriffe, Man-In-The-Middle-Angriffe / Hijackings (wenn ein Angreifer ein paar Bytes in Ihre ungesicherte HTML-Seite injizieren kann, bevor er Ihren Browser erreicht, kann er das Hashing im JavaScript einfach auskommentieren), oder Brute-Force-Angriffe (da Sie dem Angreifer sowohl den Benutzernamen als auch das Salz- und Hash-Passwort übergeben).

CAPTCHAS gegen die Menschheit

CAPTCHAs sollen eine bestimmte Angriffskategorie vereiteln: automatisiertes Wörterbuch / Brute-Force-Trial-and-Error ohne menschlichen Operator. Es besteht kein Zweifel, dass dies eine echte Bedrohung darstellt, es gibt jedoch Möglichkeiten, nahtlos damit umzugehen, die kein CAPTCHA erfordern, speziell richtig entworfene serverseitige Login-Drosselungsschemata - wir werden diese später besprechen.

Wissen, dass CAPTCHA-Implementierungen nicht gleich erstellt werden; Sie sind oft nicht von Menschen lösbar, die meisten von ihnen sind tatsächlich gegen Bots unwirksam, alle sind unwirksam gegen billige Dritte-Welt-Arbeit (nach OWASP, die aktuelle Sweatshop - Rate beträgt $ 12 pro 500 Tests), und einige Implementierungen können in einigen Ländern technisch illegal sein (siehe OWASP Authentication Spickzettel). Wenn Sie ein CAPTCHA verwenden müssen, verwenden Sie Google reCaptcha, da es per Definition OCR-hart ist (da es bereits OCR-falsch klassifizierte Buchscans verwendet) und sehr bemüht ist, benutzerfreundlich zu sein.

Persönlich finde ich CAPTCHAS nervig und benutze sie nur als letzten Ausweg, wenn ein Benutzer sich mehrmals nicht einloggen konnte und die Verzögerungszeiten maximal sind. Dies wird selten genug sein, um akzeptabel zu sein, und es stärkt das System als Ganzes.

Passwörter speichern / Logins verifizieren

Dies ist nach all den in den letzten Jahren publizierten Hacks und Benutzerdaten-Leaks endlich allgemein bekannt, aber es muss gesagt werden: Speichern Sie keine Passwörter in Klartext in Ihrer Datenbank. Benutzerdatenbanken werden routinemäßig gehackt, durchgesickert oder durch SQL-Injection erfasst, und wenn Sie unverschlüsselte Klartextpasswörter speichern, ist das Instant-Game für Ihre Anmeldesicherheit vorbei.

Also, wenn Sie das Passwort nicht speichern können, wie überprüfen Sie, dass die Login + Passwort-Kombination POSTed aus dem Login-Formular korrekt ist? Die Antwort lautet Hashing mit a Schlüsselableitungsfunktion. Wenn ein neuer Benutzer erstellt oder ein Passwort geändert wird, nehmen Sie das Passwort und führen es durch eine KDF, wie Argon2, bcrypt, scrypt oder PBKDF2, und verwandeln das Klartext-Passwort ("correcthorsebatterystaple") in eine lange, zufällige Zeichenfolge , die viel sicherer in Ihrer Datenbank gespeichert werden kann. Um eine Anmeldung zu verifizieren, führen Sie die gleiche Hash-Funktion für das eingegebene Passwort aus. Geben Sie diesmal die Salzmenge ein und vergleichen Sie die resultierende Hash-Zeichenfolge mit dem Wert, der in Ihrer Datenbank gespeichert ist. Argon2, bcrypt und scrypt speichern das Salz bereits mit dem Hash. Schau dir das an Artikel auf sec.stackexchange für detailliertere Informationen.

Der Grund, warum ein Salz verwendet wird, ist, weil Hashing an sich nicht ausreicht - Sie sollten ein sogenanntes 'Salz' hinzufügen, um den Hash gegen zu schützen Regenbogen-Tische. Ein Salt verhindert effektiv, dass zwei Passwörter, die genau übereinstimmen, als derselbe Hashwert gespeichert werden, wodurch verhindert wird, dass die gesamte Datenbank in einem Durchgang gescannt wird, wenn ein Angreifer einen Passwortratenangriff ausführt.

Ein kryptografischer Hash sollte nicht zum Speichern von Passwörtern verwendet werden, da vom Benutzer ausgewählte Passwörter nicht stark genug sind (d. H. Üblicherweise nicht genug Entropie enthalten) und ein Angriff zum Erraten von Kennwörtern in relativ kurzer Zeit von einem Angreifer mit Zugriff auf die Hashes ausgeführt werden könnte. Deshalb wird eine KDF verwendet - diese effektiv "strecke den Schlüssel" Das bedeutet, dass bei jedem von einem Angreifer erratenen Passwort der Hashing-Algorithmus mehrere Male wiederholt wird, beispielsweise 10.000 Mal, sodass das Passwort des Angreifers 10.000-mal langsamer rät.

Sitzungsdaten - "Sie sind als Spiderman69 angemeldet"

Sobald der Server die Anmeldung und das Passwort für Ihre Benutzerdatenbank überprüft und eine Übereinstimmung gefunden hat, muss das System sich daran erinnern, dass der Browser authentifiziert wurde. Diese Tatsache sollte nur serverseitig in den Sitzungsdaten gespeichert werden.

Wenn Sie mit Sitzungsdaten nicht vertraut sind, geht es so: Ein einzelner zufällig generierter String wird in einem ablaufenden Cookie gespeichert und verwendet, um auf eine Sammlung von Daten - die Sitzungsdaten - zu verweisen, die auf dem Server gespeichert sind. Wenn Sie ein MVC-Framework verwenden, wird dies zweifellos bereits behandelt.

Stellen Sie nach Möglichkeit sicher, dass der Sitzungscookie die sicheren und nur HTTP-Flags aufweist, wenn er an den Browser gesendet wird. Das httponly-Flag bietet einen gewissen Schutz gegen das Lesen des Cookies durch einen XSS-Angriff. Das Secure-Flag stellt sicher, dass der Cookie nur über HTTPS zurückgesendet wird und schützt somit vor Netzwerk-Sniffing-Angriffen. Der Wert des Cookies sollte nicht vorhersehbar sein. Wenn ein Cookie mit einer nicht vorhandenen Sitzung angezeigt wird, sollte dessen Wert sofort ersetzt werden, um dies zu verhindern Sitzfixierung.

Teil II: Wie man sich anmeldet - Die berüchtigte "Remember Me" Checkbox

Persistente Login-Cookies ("Remember Me" -Funktionalität) sind eine Gefahrenzone; Auf der einen Seite sind sie völlig so sicher wie herkömmliche Logins, wenn die Benutzer verstehen, wie sie damit umgehen sollen. Andererseits sind sie ein enormes Sicherheitsrisiko in den Händen unvorsichtiger Benutzer, die sie auf öffentlichen Computern benutzen und vergessen, sich abzumelden, und die vielleicht nicht wissen, welche Browser-Cookies sind oder wie sie gelöscht werden.

Persönlich mag ich hartnäckige Anmeldungen für die Websites, die ich regelmäßig besuche, aber ich weiß, wie man mit ihnen sicher umgeht. Wenn Sie sicher sind, dass Ihre Benutzer das gleiche wissen, können Sie persistente Logins mit gutem Gewissen verwenden. Wenn nicht - nun, dann können Sie sich der Philosophie anschließen, dass Benutzer, die mit ihren Zugangsdaten unachtsam sind, es auf sich selbst gebracht haben, wenn sie gehackt werden. Es ist nicht so, als würden wir in die Häuser unserer Nutzer gehen und all diese Facepalm-induzierenden Post-It-Notizen mit Passwörtern abreißen, die sie am Rand ihrer Monitore aufgestellt haben.

Natürlich können sich einige Systeme nicht leisten irgendein Konten gehackt; Für solche Systeme gibt es keine Möglichkeit, dauerhafte Logins zu rechtfertigen.

Wenn Sie sich dafür entscheiden, dauerhafte Login-Cookies zu implementieren, dann machen Sie das so:

  1. Nehmen Sie sich zunächst etwas Zeit zum Lesen Paragon Initiative Artikel zum Thema. Sie müssen eine Reihe von Elementen richtig machen, und der Artikel macht eine großartige Arbeit, jedes zu erklären.

  2. Und nur um eine der häufigsten Fallstricke zu wiederholen, SPEICHERN SIE NICHT DEN PERSISTENTEN LOGIN COOKIE (TOKEN) IN IHRER DATENBANK, NUR EIN HASH VON IHM! Das Login-Token ist Password Equivalent. Wenn also ein Angreifer Ihre Datenbank in die Hände bekommen hat, könnte er die Token verwenden, um sich bei jedem Konto anzumelden, als ob es sich um Klartext-Login-Passwort-Kombinationen handelt. Verwenden Sie daher Hashing (nach https://security.stackexchange.com/a/63438/5002 ein schwacher Hash wird für diesen Zweck gut funktionieren) beim Speichern persistenter Login-Token.

TEIL III: Verwenden geheimer Fragen

Implementieren Sie keine "geheimen Fragen". Das Feature "geheime Fragen" ist ein Sicherheits-Anti-Pattern. Lesen Sie das Papier von Link Nummer 4 aus der MUST-READ-Liste. Sie können Sarah Palin nach ihrer Yahoo! E-Mail-Account wurde während einer früheren Präsidentschaftskampagne gehackt, weil die Antwort auf ihre Sicherheitsfrage war ... "Wasilla High School"!

Auch bei benutzerdefinierten Fragen ist es sehr wahrscheinlich, dass die meisten Benutzer entweder Folgendes auswählen:

  • Eine "normale" geheime Frage wie der Mädchenname der Mutter oder das Lieblingstier

  • Ein einfaches Stück Wissen, das jeder aus seinem Blog, LinkedIn-Profil oder ähnlichem herausheben könnte

  • Jede Frage, die einfacher zu beantworten ist, als ihr Passwort zu erraten. Was für ein anständiges Passwort, ist jede Frage, die Sie sich vorstellen können

Schlussendlich sind Sicherheitsfragen in fast allen ihren Formen und Variationen inhärent unsicher und sollten aus irgendeinem Grund nicht in einem Authentifizierungsschema verwendet werden.

Der wahre Grund, warum Sicherheitsfragen sogar in freier Wildbahn existieren, ist, dass sie bequem die Kosten einiger Supportanrufe von Benutzern sparen, die nicht auf ihre E-Mails zugreifen können, um zu einem Reaktivierungscode zu gelangen. Dies auf Kosten von Sicherheit und Sarah Palins Ruf. Es ist es wert? Wahrscheinlich nicht.

Teil IV: Passwort vergessen Funktionalität

Ich habe bereits erwähnt, warum Sie sollten Verwenden Sie niemals Sicherheitsfragenzur Handhabung vergessener / verlorener Benutzerpasswörter; Es versteht sich von selbst, dass Sie Ihren Benutzern niemals ihre tatsächlichen Passwörter per E-Mail senden sollten. Es gibt mindestens zwei weitere allzu häufige Fallstricke, die in diesem Bereich zu vermeiden sind:

  1. Nicht zurücksetzen ein vergessenes Passwort für ein automatisch erzeugtes starkes Passwort - solche Passwörter sind bekanntermaßen schwer zu merken, was bedeutet, dass der Benutzer sie entweder ändern oder aufschreiben muss - etwa auf einem leuchtend gelben Post-It am Rand ihres Monitors. Anstatt ein neues Passwort zu setzen, lassen Sie die Nutzer einfach gleich einen neuen auswählen - was sie ohnehin tun möchten. (Eine Ausnahme davon könnte sein, dass die Benutzer einen Passwortmanager zum Speichern / Verwalten von Passwörtern verwenden, die normalerweise nicht gespeichert werden können, ohne sie aufzuschreiben).

  2. Hasht immer den verlorenen Passwort-Code / Token in der Datenbank. NOCHMAL, dieser Code ist ein weiteres Beispiel für ein Passwort-Äquivalent, also muss er Hash-Code für den Fall sein, dass ein Angreifer Ihre Daten in die Hände bekommt. Wenn ein Passwort verloren gegangener Code angefordert wird, senden Sie den Klartext-Code an die E-Mail-Adresse des Benutzers, dann hash es, speichern Sie den Hash in Ihrer Datenbank - und Wirf das Original weg. Genau wie ein Passwort oder ein dauerhaftes Login-Token.

Ein letzter Hinweis: Stellen Sie immer sicher, dass Ihre Schnittstelle für die Eingabe des "Passwort verloren" -Kennworts mindestens so sicher ist wie Ihr Login-Formular selbst, oder ein Angreifer verwendet dies einfach, um stattdessen Zugang zu erhalten. Stellen Sie sicher, dass Sie sehr lange "verlorene Passwortcodes" (z. B. 16 alphanumerische Zeichen mit Groß- und Kleinschreibung) generieren, aber beginnen Sie, das gleiche Einschränkungsschema wie für das Login-Formular selbst hinzuzufügen.

TEIL V: Überprüfen der Passwortstärke

Zuerst sollten Sie diesen kleinen Artikel für einen Realitätscheck lesen: Die 500 häufigsten Passwörter

Okay, vielleicht ist die Liste nicht die kanonisch Liste der häufigsten Passwörter auf irgendein System überall, aber es ist ein guter Hinweis darauf, wie schlecht die Leute ihre Passwörter wählen, wenn keine erzwungene Richtlinie vorhanden ist. Außerdem sieht die Liste erschreckend nah an zu Hause aus, wenn Sie sie mit öffentlich verfügbaren Analysen kürzlich gestohlener Kennwörter vergleichen.

Also: Ohne Mindestanforderungen für die Passwortstärke verwenden 2% der Benutzer eines der 20 häufigsten Passwörter. Das bedeutet: Wenn ein Angreifer nur 20 Versuche erhält, ist 1 von 50 Konten auf Ihrer Website crackbar.

Um dies zu vereiteln, muss die Entropie eines Passworts berechnet und dann ein Schwellenwert angewendet werden. Das Nationale Institut für Standards und Technologie (NIST) Spezielle Publikation 800-63 hat eine Reihe sehr guter Vorschläge. Das kann, wenn es mit einer Wörterbuch- und Tastaturlayout-Analyse kombiniert wird (z. B. "qwertyuiop" ist ein schlechtes Passwort), dies tun lehnen Sie 99% aller schlecht ausgewählten Passwörter ab auf einer Ebene von 18 Bit Entropie. Einfach die Passwortstärke berechnen und zeigt einen visuellen Stärke-Meter zu einem Benutzer ist gut, aber nicht ausreichend. Wenn es nicht durchgesetzt wird, werden viele Benutzer es wahrscheinlich ignorieren.

Und für eine erfrischende Benutzerfreundlichkeit der High-Entropie-Passwörter ist Randall Munroe Passwortstärke xkcd ist sehr zu empfehlen.

Teil VI: Viel mehr - Oder: Verhindern von Rapid-Fire Login-Versuchen

Sehen Sie sich zunächst die Zahlen an: Passwort Recovery Speeds - Wie lange wird Ihr Passwort stehen?

Wenn Sie nicht die Zeit haben, durch die Tabellen in diesem Link zu sehen, ist hier die Liste von ihnen:

  1. Es braucht praktisch keine Zeit um ein schwaches Passwort zu knacken, auch wenn Sie es mit einem Abakus knacken

  2. Es braucht praktisch keine Zeit um ein alphanumerisches 9-stelliges Passwort zu knacken, falls ja Groß- und Kleinschreibung

  3. Es braucht praktisch keine Zeit um ein kompliziertes Passwort für Groß- und Kleinbuchstaben, Groß- und Kleinbuchstaben und Groß- und Kleinbuchstaben zu knacken, wenn dies der Fall ist weniger als 8 Zeichen lang (Ein Desktop-PC kann den gesamten Schlüsselraum innerhalb von Tagen oder sogar Stunden bis zu 7 Zeichen durchsuchen)

  4. Es würde jedoch eine übermäßige Menge an Zeit benötigen, um sogar ein 6-stelliges Passwort zu knacken, wenn Sie auf einen Versuch pro Sekunde beschränkt waren!

Was können wir aus diesen Zahlen lernen? Nun, viele, aber wir können uns auf den wichtigsten Teil konzentrieren: die Tatsache, dass eine große Anzahl von schnellen aufeinanderfolgenden Anmeldeversuchen verhindert wird (z. B. die rohe Gewalt Angriff) ist wirklich nicht so schwierig. Aber es verhindern Recht ist nicht so einfach wie es scheint.

Im Allgemeinen haben Sie drei Möglichkeiten, die gegen Brute-Force-Angriffe wirksam sind (und Wörterbuchangriffe, aber da Sie bereits eine starke Kennwortrichtlinie verwenden, sollten sie kein Problem sein):

  • Präsentieren a CAPTCHA nach N gescheiterten Versuchen (nervtötend und oft unwirksam - aber ich wiederhole mich hier)

  • Konten sperren und die E-Mail-Überprüfung nach N fehlgeschlagenen Versuchen erfordert (dies ist a DOS Angriff wartet auf passieren)

  • Und schlussendlich, AnmeldedrosselungDas heißt, eine Zeitverzögerung zwischen Versuchen nach N fehlgeschlagenen Versuchen einzustellen (ja, DoS-Attacken sind immer noch möglich, aber zumindest sind sie viel weniger wahrscheinlich und viel komplizierter zu ziehen).

Best Practice # 1: Eine kurze Zeitverzögerung, die mit der Anzahl fehlgeschlagener Versuche zunimmt, wie:

  • 1 fehlgeschlagener Versuch = keine Verzögerung
  • 2 fehlgeschlagene Versuche = 2 Sekunden Verzögerung
  • 3 fehlgeschlagene Versuche = 4 Sekunden Verzögerung
  • 4 fehlgeschlagene Versuche = 8 Sekunden Verzögerung
  • 5 fehlgeschlagene Versuche = 16 Sekunden Verzögerung
  • etc.

DoS, die dieses Schema angreifen, wäre sehr unpraktisch, da die resultierende Sperrzeit etwas größer ist als die Summe der vorherigen Sperrzeiten.

Um zu verdeutlichen: Die Verzögerung ist nicht eine Verzögerung, bevor die Antwort an den Browser zurückgegeben wird. Es ist eher ein Timeout oder eine Refraktärzeit, in der Login-Versuche zu einem bestimmten Account oder von einer bestimmten IP-Adresse überhaupt nicht akzeptiert oder ausgewertet werden. Das heißt, dass die korrekten Anmeldeinformationen bei einer erfolgreichen Anmeldung nicht zurückgegeben werden und falsche Anmeldeinformationen keine Verzögerung auslösen.

Best Practice # 2: Eine mittlere Zeitverzögerung, die nach N fehlgeschlagenen Versuchen wirksam wird, wie:

  • 1-4 fehlgeschlagene Versuche = keine Verzögerung
  • 5 fehlgeschlagene Versuche = 15-30 Minuten Verzögerung

DoS, die dieses Schema angreifen, wären ziemlich unpraktisch, aber sicherlich machbar. Es könnte auch wichtig sein zu bemerken, dass solch eine lange Verzögerung für einen legitimen Benutzer sehr lästig sein kann. Vergessliche Nutzer werden Sie nicht mögen.

Best Practice # 3: Kombinieren der beiden Ansätze - entweder eine feste, kurze Zeitverzögerung, die nach N fehlgeschlagenen Versuchen wirksam wird, wie:

  • 1-4 fehlgeschlagene Versuche = keine Verzögerung
  • 5+ fehlgeschlagene Versuche = 20 Sekunden Verzögerung

Oder eine zunehmende Verzögerung mit einer festen oberen Grenze, wie:

  • 1 fehlgeschlagener Versuch = 5 Sekunden Verzögerung
  • 2 fehlgeschlagene Versuche = 15 Sekunden Verzögerung
  • 3+ fehlgeschlagene Versuche = 45 Sekunden Verzögerung

Dieses endgültige Schema wurde aus den OWASP Best-Practice-Vorschlägen (Link 1 der MUST-READ-Liste) übernommen und sollte als Best Practice gelten, auch wenn es zugegebenermaßen auf der restriktiven Seite ist.

Als Faustregel würde ich jedoch sagen: Je stärker Ihre Passwortrichtlinie ist, desto weniger müssen Sie Benutzer mit Verzögerungen belästigen. Wenn Sie starke (Groß- / Kleinschreibung + alphanumerische Zeichen + erforderliche Zahlen und Symbole) Kennwörter mit 9 + Zeichen benötigen, können Sie den Benutzern 2-4 nicht verzögerte Kennwortversuche geben, bevor Sie die Drosselung aktivieren.

DoS greift dieses letzte Login-Drosselungsschema an sehr unpraktisch. Als letzten Schliff erlauben Sie immer persistente (Cookie) Logins (und / oder ein CAPTCHA-verifiziertes Login-Formular) zu passieren, damit legitime Benutzer nicht einmal verzögert werden während der Angriff läuft. Auf diese Weise wird der sehr unpraktische DoS - Angriff zu einem äußerst unpraktischer Angriff.

Darüber hinaus ist es sinnvoll, die Administratorkonten aggressiver zu drosseln, da dies die attraktivsten Einstiegspunkte sind

Teil VII: Verteilte Brute-Force-Angriffe

Nebenbei werden fortgeschrittene Angreifer versuchen, die Login-Drosselung zu umgehen, indem sie "ihre Aktivitäten verbreiten":

  • Verteilen der Versuche auf einem Botnet, um das Markieren von IP-Adressen zu verhindern

  • Anstatt einen Benutzer auszuwählen und die 50.000 gängigsten Passwörter auszuprobieren (was sie aufgrund unserer Drosselung nicht tun können), wählen sie DAS häufigste Passwort und versuchen es stattdessen gegen 50.000 Benutzer. Auf diese Weise umgehen sie nicht nur Maximum-Versuche wie CAPTCHAs und Logindrosselung, sondern erhöhen auch ihre Erfolgschancen, da das häufigste Passwort mit der Nummer 1 weitaus wahrscheinlicher ist als die Nummer 49.995

  • Legen Sie die Anmeldeanforderungen für jedes Benutzerkonto fest, z. B. 30 Sekunden, um sich unter das Radar zu schleichen

Hier wäre die beste Praxis Protokollieren der Anzahl fehlgeschlagener Anmeldungen systemweitund verwenden Sie einen laufenden Durchschnitt der Häufigkeit der häufigen Anmeldung Ihrer Website als Grundlage für eine Obergrenze, die Sie dann allen Benutzern auferlegen.

Zu abstrakt? Lass mich neu formulieren:

Angenommen, Ihre Website hat in den letzten 3 Monaten durchschnittlich 120 fehlerhafte Anmeldungen pro Tag erhalten. Wenn Sie das verwenden (laufender Durchschnitt), könnte Ihr System das globale Limit auf das 3-fache festlegen. 360 fehlgeschlagene Versuche über einen Zeitraum von 24 Stunden. Wenn dann die Gesamtzahl der fehlgeschlagenen Versuche für alle Konten innerhalb eines Tages die Anzahl der fehlgeschlagenen Versuche übersteigt (oder noch besser, die Beschleunigungsrate überwachen und bei einem berechneten Schwellenwert auslösen), aktiviert sie die systemweite Anmeldedrosselung - dh kurze Verzögerungen für ALLE Benutzer (mit Ausnahme von Cookie-Logins und / oder Backup-CAPTCHA-Logins).

Ich habe auch eine Frage mit mehr Details und eine wirklich gute Diskussion darüber, wie man knifflige Pitfals vermeiden kann bei der Abwehr verteilter Brute-Force-Angriffe

Teil VIII: Zwei-Faktor-Authentifizierung und Authentifizierung Anbieter

Berechtigungsnachweise können kompromittiert werden, sei es durch Exploits, das Abschreiben von Passwörtern, den Verlust von Laptops mit gestohlenen Schlüsseln oder das Einloggen von Benutzern in Phishing-Sites. Logins können durch eine Zwei-Faktor-Authentifizierung weiter geschützt werden, die Out-of-Band-Faktoren wie Einmal-Codes, die von einem Telefonanruf, einer SMS-Nachricht, einer App oder einem Dongle empfangen werden. Mehrere Anbieter bieten Zwei-Faktor-Authentifizierungsdienste an.

Die Authentifizierung kann vollständig an einen Single Sign-On-Dienst delegiert werden, bei dem ein anderer Anbieter das Sammeln von Anmeldeinformationen übernimmt. Dies schiebt das Problem an eine vertrauenswürdige dritte Partei. Google und Twitter bieten beide standardbasierte SSO-Dienste, während Facebook eine ähnliche proprietäre Lösung bietet.

MUSS LINKS LESEN Über die Web-Authentifizierung

  1. OWASP Leitfaden zur Authentifizierung / OWASP Authentication Spickzettel
  2. Dos und Don'ts der Client-Authentifizierung im Web (sehr lesenswertes MIT-Forschungspapier)
  3. Wikipedia: HTTP-Cookie
  4. Persönliche Wissensfragen zur Fallback-Authentifizierung: Sicherheitsfragen im Zeitalter von Facebook (sehr lesenswertes Berkeley-Forschungspapier)

3497



Endgültiger Artikel

Anmeldeinformationen senden

Die einzige praktische Möglichkeit, Anmeldeinformationen zu 100% sicher zu senden, ist die Verwendung von SSL. Die Verwendung von JavaScript zum Hashing des Passworts ist nicht sicher. Häufige Fehler beim clientseitigen Passwort-Hashing:

  • Wenn die Verbindung zwischen dem Client und dem Server unverschlüsselt ist, ist alles, was Sie tun anfällig für Man-in-the-Middle-Angriffe. Ein Angreifer könnte das eingehende Javascript ersetzen, um den Hash zu brechen oder alle Anmeldeinformationen an seinen Server zu senden, sie könnten Clientantworten anhören und die Benutzer perfekt repräsentieren usw. usw. SSL mit vertrauenswürdigen Zertifizierungsstellen soll MitM-Angriffe verhindern.
  • Das vom Server empfangene Hash-Passwort lautet weniger sicher wenn Sie keine zusätzlichen, redundanten Arbeiten auf dem Server ausführen.

Es gibt eine andere sichere Methode namens SRPaber es ist patentiert (obwohl es ist frei lizenziert) und es gibt nur wenige gute Implementierungen.

Speichern von Passwörtern

Speichern Sie Kennwörter niemals als Klartext in der Datenbank. Nicht einmal, wenn Ihnen die Sicherheit Ihrer eigenen Website egal ist. Angenommen, einige Ihrer Nutzer werden das Passwort ihres Online-Bankkontos wiederverwenden. Speichern Sie das Hash-Passwort und werfen Sie das Original weg. Und stellen Sie sicher, dass das Passwort nicht in Zugriffsprotokollen oder Anwendungsprotokollen angezeigt wird. OWASP empfiehlt die Verwendung von Argon2 als Ihre erste Wahl für neue Anwendungen. Wenn dies nicht möglich ist, sollten stattdessen PBKDF2 oder scrypt verwendet werden. Und wenn keine der oben genannten Möglichkeiten verfügbar ist, verwenden Sie bcrypt.

Hashes allein sind ebenfalls unsicher. Zum Beispiel, identische Kennwörter bedeuten identische Hashes - das macht Hash-Lookup-Tabellen eine effektive Möglichkeit, viele Passwörter auf einmal zu knacken. Speichern Sie stattdessen die gesalzen Hash. Ein Salt ist eine Zeichenkette, die vor dem Hashing an das Passwort angehängt wird. Verwenden Sie für jeden Benutzer ein anderes (zufälliges) Salt. Das Salz ist ein öffentlicher Wert, so dass Sie sie mit dem Hash in der Datenbank speichern können. Sehen Hier mehr dazu.

Dies bedeutet, dass Sie dem Benutzer seine vergessenen Passwörter nicht senden können (weil Sie nur den Hash haben). Setzen Sie das Passwort des Benutzers nur zurück, wenn Sie den Benutzer authentifiziert haben (Benutzer müssen nachweisen, dass sie E-Mails lesen können, die an die gespeicherte (und validierte) E-Mail-Adresse gesendet wurden.)

Sicherheitsfragen

Sicherheitsfragen sind unsicher - vermeiden Sie sie. Warum? Was auch immer eine Sicherheitsfrage ist, ein Passwort ist besser. Lesen TEIL III: Verwenden geheimer Fragen im @Jens Roland antwortet hier in diesem Wiki.

Sitzungscookies

Nachdem sich der Benutzer angemeldet hat, sendet der Server dem Benutzer einen Sitzungscookie. Der Server kann den Benutzernamen oder die ID aus dem Cookie abrufen, aber niemand anderes kann einen solchen Cookie erzeugen (TODO-Erklärungsmechanismen).

Cookies können entführt werden: Sie sind nur so sicher wie der Rest der Maschine des Kunden und andere Kommunikationen. Sie können von der Festplatte gelesen, im Netzwerkverkehr gecrackt, durch einen Cross-Site-Scripting-Angriff aufgehoben werden, der von einem vergifteten DNS stammt, so dass der Client seine Cookies an die falschen Server sendet. Senden Sie keine dauerhaften Cookies. Cookies sollten am Ende der Client-Sitzung ablaufen (Browser schließt oder verlässt Ihre Domain).

Wenn Sie Ihre Benutzer automatisch anmelden möchten, können Sie einen dauerhaften Cookie festlegen, der sich jedoch von einem vollständigen Cookie unterscheiden sollte. Sie können ein zusätzliches Flag festlegen, dass der Benutzer sich automatisch angemeldet hat und sich für sensible Vorgänge anmelden muss. Dies ist beliebt bei Shopping-Websites, die Ihnen ein nahtloses, personalisiertes Einkaufserlebnis bieten, aber dennoch Ihre finanziellen Daten schützen möchten. Wenn Sie zum Beispiel zu Amazon zurückkehren, wird Ihnen eine Seite angezeigt, die aussieht, als wären Sie eingeloggt. Wenn Sie jedoch eine Bestellung aufgeben (oder Ihre Lieferadresse, Kreditkarte usw. ändern), werden Sie aufgefordert, dies zu bestätigen Ihr Passwort.

Finanzielle Websites wie Banken und Kreditkarten hingegen haben nur sensible Daten und sollten keine automatische Anmeldung oder einen Low-Security-Modus zulassen.

Liste der externen Ressourcen


387



Erstens, eine starke Einschränkung, dass diese Antwort nicht die beste Lösung für diese genaue Frage ist. Es sollte definitiv nicht die beste Antwort sein!

Ich werde fortfahren und Mozillas Vorschlag erwähnen Browser-ID (oder genauer gesagt, die Bestätigtes E-Mail-Protokoll) im Sinne eines Aufrüstungsweges zu besseren Authentifizierungsansätzen in der Zukunft.

Ich fasse es so zusammen:

  1. Mozilla ist eine gemeinnützige Organisation mit Werte das passt gut dazu, gute Lösungen für dieses Problem zu finden.
  2. Die Realität heute ist, dass die meisten Websites formularbasierte Authentifizierung verwenden
  3. Die formularbasierte Authentifizierung hat einen großen Nachteil, der das Risiko erhöht Phishing. Benutzer werden aufgefordert, vertrauliche Informationen in einen Bereich einzugeben, der von einer entfernten Entität gesteuert wird, und nicht in einem Bereich, der von ihrem Benutzeragenten (Browser) gesteuert wird.
  4. Da Browser implizit vertrauenswürdig sind (die gesamte Idee eines Benutzeragenten besteht darin, im Namen des Benutzers zu handeln), können sie dazu beitragen, diese Situation zu verbessern.
  5. Die primäre Kraft, die den Fortschritt hier zurückhält, ist Deadlock für die Bereitstellung. Lösungen müssen in Schritte zerlegt werden, die allein einen zusätzlichen Nutzen bringen.
  6. Die einfachste dezentrale Methode zum Ausdrücken von Identität, die in die Internetinfrastruktur eingebaut ist, ist der Domainname.
  7. Als zweite Ebene der Identitätsauslegung verwaltet jede Domäne ihre eigenen Konten.
  8. Das Formular "Konto"@domain "ist prägnant und wird durch eine breite Palette von Protokollen und URI-Schemata unterstützt. Eine solche Kennung wird natürlich am häufigsten als E-Mail-Adresse erkannt.
  9. E-Mail-Anbieter sind bereits de-facto primäre Identitätsanbieter online. Mit den aktuellen Flüssen zum Zurücksetzen von Kennwörtern können Sie normalerweise die Kontrolle über ein Konto erlangen, wenn Sie nachweisen können, dass Sie die diesem Konto zugeordnete E-Mail-Adresse steuern.
  10. Das verifizierte E-Mail-Protokoll wurde vorgeschlagen, um eine sichere Methode auf der Grundlage der Kryptografie mit öffentlichen Schlüsseln zur Verfügung zu stellen, um den Prozess der Überprüfung von Domäne B, dass Sie ein Konto in Domäne A haben, zu optimieren.
  11. Für Browser, die das Verified Email Protocol nicht unterstützen (derzeit alle), bietet Mozilla ein Shim, das das Protokoll im clientseitigen JavaScript-Code implementiert.
  12. Bei E-Mail-Diensten, die das verifizierte E-Mail-Protokoll nicht unterstützen, ermöglicht das Protokoll es Drittanbietern, als vertrauenswürdiger Vermittler zu agieren und zu bestätigen, dass sie die Eigentumsrechte eines Benutzers an einem Konto überprüft haben. Es ist nicht wünschenswert, eine große Anzahl solcher Dritten zu haben; Diese Funktion soll nur einen Upgrade-Pfad zulassen, und es ist sehr bevorzugt, dass E-Mail-Dienste diese Assertionen selbst bereitstellen.
  13. Mozilla bietet seinen eigenen Service an, um als vertrauenswürdiger Dritter zu agieren. Dienstanbieter (dh vertrauende Parteien), die das verifizierte E-Mail-Protokoll implementieren, können sich dafür entscheiden, Mozillas Behauptungen zu vertrauen oder nicht. Der Mozilla-Dienst überprüft die Kontoinhaberschaft des Benutzers auf herkömmliche Weise, indem er eine E-Mail mit einem Bestätigungslink sendet.
  14. Dienstanbieter können dieses Protokoll natürlich zusätzlich zu jeder anderen Authentifizierungsmethode, die sie anbieten möchten, als eine Option anbieten.
  15. Ein großer Benutzeroberflächenvorteil, der hier gesucht wird, ist der "Identitätsselektor". Wenn ein Benutzer eine Website besucht und sich dafür entscheidet, sich zu authentifizieren, zeigt sein Browser ihnen eine Auswahl von E-Mail-Adressen ("persönlich", "Arbeit", "politischer Aktivismus" usw.) an, mit denen sie sich auf der Website identifizieren können.
  16. Im Rahmen dieser Bemühungen wird eine weitere große Benutzerschnittstellen-Leistung gesucht dem Browser helfen, mehr über die Sitzung des Benutzers zu erfahren - Wem sind sie in der Hauptsache angemeldet? So kann das im Browser Chrome angezeigt werden.
  17. Aufgrund der verteilten Natur dieses Systems vermeidet es die Sperrung wichtiger Websites wie Facebook, Twitter, Google usw. Jede Person kann ihre eigene Domain besitzen und somit als ihr eigener Identitätsanbieter fungieren.

Dies ist nicht streng "formularbasierte Authentifizierung für Websites". Es ist jedoch ein Versuch, von der aktuellen Norm der formularbasierten Authentifizierung auf etwas Sichereres überzugehen: browsergestützte Authentifizierung.


146



Ich dachte nur, ich würde diese Lösung teilen, die meiner Meinung nach gut funktioniert.

Ich nenne es das Dummy-Feld (Obwohl ich das nicht erfunden habe, verdanke es mir nicht).

Kurz gesagt: Sie müssen dies nur in Ihre einfügen <form> und überprüfen Sie, ob es bei der Validierung leer ist:

<input type="text" name="email" style="display:none" />

Der Trick besteht darin, einen Bot so zu täuschen, dass er denkt, er müsste Daten in ein Pflichtfeld einfügen, deshalb habe ich die Eingabe "E-Mail" genannt. Wenn Sie bereits ein Feld namens E-Mail haben, das Sie verwenden, sollten Sie versuchen, das Dummy-Feld etwas anderes wie "Firma", "Telefon" oder "E-Mail-Adresse" zu nennen. Suchen Sie sich einfach etwas aus, von dem Sie wissen, dass Sie es nicht brauchen, und was nach etwas klingt, was Leute normalerweise logisch finden würden, um es in ein Webformular zu füllen. Verstecke jetzt die input Feld mit CSS oder JavaScript / jQuery - was auch immer Ihnen am besten passt - nur nicht Setze die Eingabe type zu hidden oder der Bot wird nicht darauf hereinfallen.

Überprüfen Sie bei der Überprüfung des Formulars (Client- oder Serverseite), ob Ihr Dummy-Feld ausgefüllt wurde, um festzustellen, ob es von einem Menschen oder einem Bot gesendet wurde.

Beispiel:

Im Falle eines Menschen: Der Benutzer wird das Dummy-Feld (in meinem Fall "E-Mail" genannt) nicht sehen und wird nicht versuchen, es zu füllen. Daher sollte der Wert des Dummy-Felds immer noch leer sein, wenn das Formular gesendet wurde.

Im Falle eines Bot: Der Bot wird ein Feld sehen, dessen Typ ist text und ein Name email (oder wie auch immer Sie es genannt haben) und wird logischerweise versuchen, es mit geeigneten Daten zu füllen. Es ist egal, wenn Sie das Eingabeformular mit etwas schickem CSS gestalten, Web-Entwickler tun es die ganze Zeit. Was auch immer der Wert im Dummy-Feld ist, ist uns egal, solange es größer ist als 0 Figuren.

Ich habe diese Methode in Kombination mit einem Gästebuch verwendet CAPTCHAund ich habe seitdem keinen einzigen Spam-Post mehr gesehen. Ich hatte vorher nur eine CAPTCHA-Lösung verwendet, aber irgendwann gab es jede Stunde etwa fünf Spam-Posts. Durch das Hinzufügen des Dummy-Felds im Formular wurde (zumindest bis jetzt) ​​der gesamte Spam gestoppt.

Ich glaube, dass dies auch gut mit einem Login / Authentifizierungsformular verwendet werden kann.

Warnung: Natürlich ist diese Methode nicht zu 100% narrensicher. Bots können so programmiert werden, dass Eingabefelder mit dem Stil ignoriert werden display:none darauf angewendet. Sie müssen auch an Leute denken, die eine Form der automatischen Vervollständigung verwenden (wie die meisten Browser eingebaute!), Um automatisch alle Formularfelder für sie zu füllen. Sie könnten genauso gut ein Dummy-Feld aufnehmen.

Sie können dies auch etwas variieren, indem Sie das Dummy-Feld zwar sichtbar, aber außerhalb der Grenzen des Bildschirms lassen, aber das liegt ganz bei Ihnen.

Seien Sie kreativ!


120



Ich denke nicht, dass die obige Antwort "falsch" ist, aber es gibt große Bereiche der Authentifizierung, die nicht behandelt werden (oder eher die Betonung auf "wie Cookie-Sitzungen implementiert werden"), nicht auf "welche Optionen verfügbar sind und was der Handel ist offs ".

Meine vorgeschlagenen Bearbeitungen / Antworten sind

  • Das Problem liegt eher in der Kontoeinrichtung als in der Passwortprüfung.
  • Die Verwendung der Zwei-Faktor-Authentisierung ist viel sicherer als eine geschicktere Methode der Passwort-Verschlüsselung
  • Versuchen Sie NICHT, Ihr eigenes Login-Formular oder Ihren Datenbankspeicher für Passwörter zu implementieren, es sei denn Die Daten, die gespeichert werden, sind wertlos bei der Kontoerstellung und selbst generiert (das heißt, Web 2.0-Stil wie Facebook, Flickr, etc.)

    1. Die Digest-Authentifizierung ist ein standardbasierter Ansatz, der in allen gängigen Browsern und Servern unterstützt wird und kein Kennwort auch über einen sicheren Kanal sendet.

Dies verhindert, dass "Sitzungen" oder Cookies erforderlich sind, da der Browser die Kommunikation jedes Mal neu verschlüsselt. Es ist der "leichteste" Entwicklungsansatz.

Ich empfehle das jedoch nicht, außer für öffentliche Dienste mit geringem Wert. Dies ist ein Problem mit einigen der anderen Antworten oben - versuchen Sie nicht, serverseitige Authentifizierungsmechanismen neu zu implementieren - dieses Problem wurde gelöst und wird von den meisten gängigen Browsern unterstützt. Verwenden Sie keine Cookies. Verwahren Sie nichts in Ihrer eigenen handgerollten Datenbank. Fragen Sie einfach nach Anfrage, ob die Anfrage authentifiziert ist. Alles andere sollte von der Konfiguration und vertrauenswürdiger Software von Drittanbietern unterstützt werden.

Damit ...

Zunächst verwechseln wir die erstmalige Erstellung eines Accounts (mit einem Passwort) mit dem Erneutes Überprüfen des Passworts anschließend. Wenn ich Flickr bin und Ihre Site zum ersten Mal erstelle, hat der neue Benutzer Zugriff auf null Wert (leerer Webspace). Es interessiert mich wirklich nicht, ob die Person, die den Account erstellt, ihren Namen lügt. Wenn ich ein Konto für das Krankenhaus-Intranet / Extranet erstelle, liegt der Wert in allen Krankenakten, und so kann ich machen kümmern sich um die Identität (*) des Kontoerstellers.

Dies ist der sehr sehr schwierige Teil. Das nur Anständige Lösung ist ein Netz des Vertrauens. Zum Beispiel treten Sie als Arzt in das Krankenhaus ein. Sie erstellen eine Webseite, die irgendwo mit Ihrem Foto, Ihrer Passnummer und einem öffentlichen Schlüssel gehostet wird, und hashen Sie alle mit dem privaten Schlüssel. Sie besuchen dann das Krankenhaus und der Systemadministrator schaut sich Ihren Reisepass an, prüft, ob das Foto zu Ihnen passt und hackt dann den Webseiten- / Foto-Hash mit dem privaten Krankenhausschlüssel. Von nun an können wir sicher Schlüssel und Token austauschen. Wie kann jemand das Krankenhaus vertrauen (es gibt die geheime Soße BTW). Der Systemadministrator kann Ihnen auch einen geben RSA Dongle oder andere Zwei-Faktor-Authentifizierung.

Aber das ist ein Menge von Ärger und nicht sehr Web 2.0. Dies ist jedoch die einzige sichere Möglichkeit, neue Konten zu erstellen, die auf wertvolle Informationen zugreifen können, die nicht selbst erstellt wurden.

  1. Kerberos und SPNEGO - Single-Sign-On-Mechanismen mit einer vertrauenswürdigen dritten Partei - im Grunde überprüft der Benutzer gegen eine vertrauenswürdige dritte Partei. (NB: Dies ist keinesfalls das, dem man nicht trauen kann OAuth)

  2. SRP - eine Art gescheite Passwort-Authentifizierung ohne eine vertrauenswürdige dritte Partei. Aber hier sind wir in den Bereichen "es ist sicherer, zwei-Faktor-Authentifizierung zu verwenden, auch wenn das teurer ist"

  3. SSL Client-Seite - Geben Sie den Clients ein Zertifikat mit öffentlichem Schlüssel (Unterstützung in allen gängigen Browsern -, wirft jedoch Fragen bezüglich der Client-Computer-Sicherheit auf).

Am Ende ist es ein Kompromiss - was kostet eine Sicherheitsverletzung im Vergleich zu den Kosten für die Implementierung sicherer Ansätze. Eines Tages sehen wir vielleicht eine richtige PKI weitestgehend akzeptiert und damit keine eigenen gerollten Authentifizierungsformen und Datenbanken mehr. Eines Tages...


71



Verwenden Sie beim Hashen keine schnellen Hashalgorithmen wie MD5 (viele Hardwareimplementierungen sind vorhanden). Verwenden Sie etwas wie SHA-512. Für Passwörter sind langsamere Hashes besser.

Je schneller Sie Hashes erstellen können, desto schneller kann ein Brute-Force-Checker arbeiten. Langsamere Hashes werden daher den Brute Forcing verlangsamen. Ein langsamer Hashalgorithmus macht Brute Forcing für längere Passwörter (8 Ziffern +) unpraktisch


48



Ein guter Artikel über realistische Passwortstärkenschätzung ist:

Dropbox Tech Blog »Blog Archiv» zxcvbn: realistische Passwortstärke Schätzung


46



Meine Lieblingsregel in Bezug auf Authentifizierungssysteme: Verwenden Sie Passphrasen, keine Passwörter. Leicht zu merken, schwer zu knacken. Mehr Info: Coding Horror: Passwörter vs. Pass-Phrasen


41



Ich möchte einen Vorschlag hinzufügen, den ich verwendet habe, basierend auf der Verteidigung in der Tiefe. Sie müssen nicht dasselbe Auth & Auth-System für Administratoren wie normale Benutzer haben. Sie können ein separates Anmeldeformular für eine separate URL verwenden, das separaten Code für Anforderungen ausführt, die hohe Berechtigungen gewähren. Dieser kann Entscheidungen treffen, die für normale Benutzer ein totaler Schmerz sind. Eine solche, die ich verwendet habe, besteht darin, die Login-URL für den Administratorzugriff zu verschlüsseln und dem Administrator die neue URL per E-Mail zu senden. Stoppt jeden Brute-Force-Angriff sofort, da Ihre neue URL beliebig schwierig sein kann (sehr lange zufällige Zeichenfolge), aber die einzige Unannehmlichkeit Ihres Admin-Benutzers besteht darin, einem Link in ihrer E-Mail zu folgen. Der Angreifer weiß nicht mehr, wo er selbst POST machen soll.


20



Ich weiß nicht, ob es am besten war, dies als Antwort oder als Kommentar zu beantworten. Ich habe mich für die erste Option entschieden.

Bezüglich des poing Teil IV: Passwort vergessen Funktionalität In der ersten Antwort möchte ich auf Timing Attacks hinweisen.

In dem Merken Sie sich Ihr Passwort In Formularen kann ein Angreifer möglicherweise eine vollständige Liste von E-Mails prüfen und erkennen, welche im System registriert sind (siehe Link unten).

In Bezug auf das Formular für vergessene Passwörter möchte ich hinzufügen, dass es eine gute Idee ist, zwischen erfolgreichen und unsachgemäßen Abfragen mit einer gewissen Verzögerungsfunktion zu gleichen Zeiten zu kommen.

https://crypto.stanford.edu/~dabo/papers/webtiming.pdf


12