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, sondern auch für allgemeine Richtlinien sein sollte wie man Schwankungen bei häufigen Problemen löst. "Formularbasierte Authentifizierung für Websites" sollte ein gutes Thema für ein solches Experiment sein.

    Es sollte folgende Themen enthalten:

    • Anmelden
    • Abmelden
    • So bleiben Sie angemeldet
    • Verwalten Cookies (einschließlich empfohlener Einstellungen)
    • SSL / HTTPS-Verschlüsselung
    • So speichern Sie Kennwörter
    • Verwenden geheimer Fragen
    • Benutzername / Kennwort vergessen
    • Verwendung von Nonces , um Cross-Site-Anforderungsfälschungen (CSRF)
    • OpenID
    • Kontrollkästchen "Remember me"
    • Browser-automatische Vervollständigung von Benutzernamen und Kennwörtern
    • Geheime URLs (öffentlich ) URL geschützt durch Digest)
    • Überprüfung der Passwortstärke
    • E-Mail-Überprüfung
    • und vieles mehr über formularbasierte Authentifizierung ...

    Es sollte nicht Dazu gehören:

    • Rollen und Autorisierung
    • HTTP-Basisauthentifizierung

    Bitte helfen Sie uns durch:

    1. Vorschläge zu Unterthemen
    2. Senden Sie dazu gute Artikel Betreff
    3. Bearbeiten der offiziellen Antwort
    09 April 2018
    Josh Kodroff
12 answers
  • TEIL I: Anmelden

    Es wird davon ausgegangen, dass Sie bereits wissen, wie Sie ein Anmelde- und Kennwort-HTML-Formular erstellen, in das die Werte für ein Skript gepostet werden die Serverseite zur Authentifizierung. In den folgenden Abschnitten werden Muster für die praktische Soundauthentifizierung beschrieben, und Sie erfahren, wie Sie die häufigsten Sicherheitsrisiken umgehen können.

    HTTPS oder nicht HTTPS?

    Wenn die Verbindung nicht bereits sicher ist (dh über HTTPS mit SSL / TLS getunnelt) wird, werden Ihre Anmeldeformularwerte im Klartext gesendet, sodass jeder die Verbindung zwischen den Browsern abhören kann und der Webserver kann Anmeldungen beim Durchlauf lesen. Diese Art des Abhörens wird von Regierungen routinemäßig durchgeführt, aber im Allgemeinen werden wir nicht auf "eigene" Leitungen verweisen, außer um Folgendes zu sagen: Wenn Sie wichtige Dinge schützen, verwenden Sie HTTPS.

    Im Wesentlichen ist die einzige praktische Methode zum Schutz vor Abhören / Paket-Sniffing während der Anmeldung die Verwendung von HTTPS oder eines anderen zertifikatsbasierten Verschlüsselungsschemas (z. B. TLS ) oder ein bewährter & amp; getestetes Challenge-Response-Schema (z. B. das Diffie-Hellman -basiert) SRP). Jede andere Methode kann von einem abhörenden Angreifer leicht umgangen werden.

    Wenn Sie bereit sind, ein wenig unpraktisch zu werden, können Sie dies natürlich auch tun eine Art Zwei-Faktor-Authentifizierungsschema (z. B. die Google Authenticator-App, ein physisches Codebuch im Stil des „Cold War“ -Stil oder ein RSA-Schlüsselgenerator-Dongle). Bei korrekter Anwendung könnte dies auch bei einer ungesicherten Verbindung funktionieren. Es ist jedoch schwer vorstellbar, dass ein Entwickler bereit ist, Zwei-Faktoren-Authentifizierung, aber keine SSL zu implementieren.

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

    Angesichts der nicht-Null-Kosten und der wahrgenommenen technischen Schwierigkeiten bei der EinstellungWenn Sie ein SSL-Zertifikat auf Ihrer Website einrichten, sind einige Entwickler versucht, ihre eigenen In-Browser-Hash- oder -Verschlüsselungsverfahren zu erstellen, um zu vermeiden, dass Klartext-Logins über eine ungesicherte Verbindung übertragen werden.

    While Dies ist ein edler Gedanke, er ist im Wesentlichen nutzlos (und kann ein Sicherheitslücke ), sofern es nicht mit einem der oben genannten kombiniert wird - dh entweder die Sicherung der Leitung durch starke Verschlüsselung oder die Verwendung eines bewährten Challenge-Response-Mechanismus (wenn Sie dies nicht tun) Wissen Sie, was das ist, wissen Sie einfach, dass es eines der am schwierigsten zu beweisenden, am schwierigsten zu konzipierenden und am schwierigsten zu implementierenden Konzepte für die digitale Sicherheit ist.

    Während es ist true, dass das Hashing des Kennworts gegen die Kennwortveröffentlichung wirksam sein kann, es ist anfällig für Wiederholungsangriffe, Man-In-The-Middle-Angriffe / -Entführungen (wenn ein Angreifer eine einige Bytes in Ihre ungesicherte HTML-Seite, bevor sie Ihren Browser erreicht, können sie das Hashing in JavaScript einfach auskommentieren) oder Brute-Force-Angriffe (da Sie dem Angreifer sowohl den Benutzernamen, das Salt- als auch das Hash-Kennwort übergeben).

    CAPTCHAS gegen die Menschheit

    CAPTCHAs sollen einer bestimmten Angriffskategorie entgegenwirken: automatisiertes Wörterbuch / Brute-Force-Versuch und Irrtum ohne menschlichen Bediener. Es besteht kein Zweifel, dass dies eine echte Bedrohung ist. Es gibt jedoch Möglichkeiten, nahtlos damit umzugehen, für die kein CAPTCHA erforderlich ist. Dies gilt insbesondere für ordnungsgemäß konzipierte serverseitige Login-Drosselungsschemata - wir werden später darauf eingehen.

    Wisse, dass CAPTCHA-Implementierungen nicht gleich erstellt werden. Sie sind oft nicht für Menschen lösbar, die meisten von ihnen sind tatsächlich gegen Bots unwirksam, alle sind gegen billige Arbeitskräfte aus der Dritten Welt (gemäß OWASP , die aktuelle Sweatshop-Rate liegt bei $ 12 pro 500 Tests), und einige Implementierungen sind in einigen Ländern technisch illegal (siehe OWASP-Authentifizierungs-Spickzettel ). Wenn Sie ein CAPTCHA verwenden müssen, verwenden Sie reCAPTCHA von Google, da es per Definition OCR-hard ist (seit es verwendet bereits OCR-falsch klassifizierte Buchscans und ist sehr bemüht, benutzerfreundlich zu sein.

    Ich persönlich finde CAPTCHAS ärgerlich und benutze sie nur als letzten Ausweg Ein Benutzer hat sich mehrmals nicht anmelden können, und die Drosselungsverzögerungen sind maximal. Dies geschieht selten genug, um akzeptabel zu sein, und stärkt das gesamte System.

    Kennwörter speichern / Anmeldungen überprüfen

    Nach all den in den letzten Jahren vielfach publizierten Hacks und Benutzerdatenverlusten ist dies möglicherweise allgemein bekannt, aber es muss gesagt werden: Speichern Sie Kennwörter nicht in Klartext in Ihrer Datenbank. Benutzerdatenbanken werden routinemäßig gehackt, durchgesickert oder durch SQL-Injection gesammelt. Wenn Sie rohe Klartext-Passwörter speichern, ist dies für Ihre Anmeldesicherheit augenblicklich vorbei.

    Wenn Sie können Speichern Sie das Passwort nicht. Wie können Sie überprüfen, ob die Login-Passwort-Kombination aus dem Login-Formular korrekt ist? Die Antwort lautet Hashing mit einer Schlüsselableitungsfunktion . Immer wenn ein neuer Benutzer erstellt oder ein Kennwort geändert wird, nehmen Sie das Kennwort und führen es über eine KDF wie Argon2, bcrypt, scrypt oder PBKDF2 aus. Dabei wird das Klartext-Kennwort ("correcthorsebatterystaple") zu einer langen, zufällig aussehenden Zeichenfolge , das ist viel sicherer in Ihrer Datenbank zu speichern. Um ein Login zu überprüfen, führen Sie dieselbe Hash-Funktion für das eingegebene Passwort aus, übergeben diesmal den Salt-Wert und vergleichen die resultierende Hash-Zeichenfolge mit dem Werte in Ihrer Datenbank gespeichert. Argon2, bcrypt und scrypt speichern das Salt bereits mit dem Hash. Ausführlichere Informationen finden Sie in diesem Artikel in sec.stackexchange.

    Der Grund für die Verwendung von Salt ist, dass das Hashing an sich nicht ausreicht. Sie sollten ein sogenanntes 'Salt' hinzufügen, um den Hash vor Regenbogentabellen . Ein Salt verhindert effektiv, dass zwei Passwörter, die genau übereinstimmen, als derselbe Hashwert gespeichert werden. Dadurch wird verhindert, dass die gesamte Datenbank in einem Lauf gescannt wird, wenn ein Angreifer einen Angriff auf das Erraten von Passwörtern ausführt.

    Ein kryptografischer Hash sollte nicht zum Speichern von Kennwörtern verwendet werden, da die vom Benutzer ausgewählten Kennwörter nicht stark genug sind (dh sie enthalten normalerweise nicht genügend Entropie) und ein Angriff zum Erraten von Kennwörtern von einem Angreifer mit Zugriff auf die Hashes in relativ kurzer Zeit abgeschlossen werden kann. Aus diesem Grund wird eine KDF verwendet, die effektiv "den Schlüssel strecken" bedeutet, dass jedes Kennwort ein Kennwort erraten muss Bei einem Angreifer wird der Hash-Algorithmus mehrere Male durchlaufen, beispielsweise 10.000 Mal, wodurch das Passwort des Angreifers 10.000 Mal langsamer erraten wird.

    Sitzungsdaten - "Sie sind als Spiderman69 angemeldet "

    Nachdem der Server Login und Passwort anhand Ihrer Benutzerdatenbank überprüft und eine Übereinstimmung gefunden hat, muss das System feststellen, dass der Browser authentifiziert wurde. Diese Tatsache sollte immer nur serverseitig in den Sitzungsdaten gespeichert werden.

    Wenn Sie mit Sitzungsdaten nicht vertraut sind, funktioniert es folgendermaßen: Die generierte Zeichenfolge wird in einem abgelaufenen 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 behandeltbereits.

    Stellen Sie nach Möglichkeit sicher, dass für das Sitzungscookie die Kennzeichen "sicher" und "Nur HTTP" gesetzt sind, wenn Sie an den Browser gesendet werden. Das httponly-Flag bietet einen gewissen Schutz gegen das Lesen eines Cookies durch einen XSS-Angriff. Das Secure-Flag stellt sicher, dass das 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 angegeben wird, das auf eine nicht vorhandene Sitzung verweist, sollte der Wert sofort ersetzt werden, um eine Sitzungsfixierung .

    PART II: So bleiben Sie angemeldet - Das Infamous-Kontrollkästchen "Remember me"

    Cookies für beständige Anmeldung ( "erinnern Sie sich an mich" -Funktionalität) sind eine Gefahrenzone; Zum einen sind sie vollkommen so sicher wie herkömmliche Anmeldungen, wenn die Benutzer mit ihrer Handhabung umgehen können. Andererseits stellen sie ein enormes Sicherheitsrisiko in den Händen unvorsichtiger Benutzer dar, die sie auf öffentlichen Computern verwenden und vergessen, sich abzumelden, und die möglicherweise nicht wissen, was Browser-Cookies sind oder wie sie gelöscht werden sollen.

    Ich persönlich mag persistente Anmeldungen für die Websites, die ich regelmäßig besuche, aber ich weiß, wie ich sie sicher handhaben kann. Wenn Sie sicher sind, dass Ihre Benutzer dasselbe wissen, können Sie beständige Anmeldungen mit gutem Gewissen verwenden. Wenn nicht - gut, dann können Sie der Philosophie zustimmen, dass Benutzer, die mit ihren Anmeldeinformationen unvorsichtig sind, es sich selbst überlassen haben, wenn sie gehackt werden. Es ist nicht so, als würden wir in die Häuser unserer Benutzer gehen und all die Facepalm-Post-It-Notizen mit Passwörtern abreißen, die sie am Rand ihrer Monitore aufgereiht haben.

    Of Natürlich können sich einige Systeme nicht leisten, irgendwelche Konten gehackt zu haben. Für solche Systeme können Sie keine dauerhaften Anmeldungen rechtfertigen.

    Wenn Sie sich dafür entscheiden, dauerhafte Anmelde-Cookies zu implementieren, gehen Sie folgendermaßen vor:

    1. Nehmen Sie sich zunächst etwas Zeit, um Artikel der Paragon-Initiative zu diesem Thema. Sie müssen eine Reihe von Elementen in die richtige Richtung bringen, und der Artikel erklärt die einzelnen Elemente sehr gut.

    2. Um nur eine der häufigsten Fallstricke zu wiederholen , SPEICHERN SIE DEN PERSISTENT LOGIN COOKIE (TOKEN) NICHT IN IHRER DATENBANK AUF, NUR EIN HASH OF IT! Das Anmelde-Token ist ein Passwort-Äquivalent Token, um sich bei jedem Konto anzumelden, als wären es Klartext-Login-Passwort-Kombinationen. Verwenden Sie daher Hashing (gemäß https://security.stackexchange.com/a/63438/5002 ) schwach hash eignet sich gut für diesen Zweck, wenn Sie persistente Login-Token speichern.

    TEIL III: Verwenden geheimer Fragen

    Keine "geheimen Fragen" implementieren . Die 'geheime Fragen'-Funktion ist ein Sicherheits-Anti-Pattern. Lesen Sie den Artikel von Link Nummer 4 aus der MUST-READ-Liste. Sie können Sarah Palin danach fragen, nachdem sie Yahoo! Das E-Mail-Konto wurde während einer früheren Präsidentschaftskampagne gehackt, weil die Antwort auf ihre Sicherheitsfrage war ... "Wasilla High School"!

    Selbst bei benutzerdefinierten Fragen ist es sehr wahrscheinlich Die meisten Benutzer wählen entweder:

    • Eine 'Standard' geheime Frage wie der Mädchenname der Mutter oder das Lieblingshaustier

    • Eine einfache Kleinigkeit, die jeder von seinem Blog, LinkedIn Profil oder Ähnlichem abnehmen kann.

    • Jede Frage, die einfacher ist Antwort als das Passwort zu erraten. Was für jedes anständige Passwort eine Frage ist, die Sie sich vorstellen können:

    Sicherheitsfragen sind daher inhärent praktisch unsicher alle ihre Formen undVariationen und sollten aus keinem Grund in einem Authentifizierungsschema verwendet werden.

    Der wahre Grund, warum Sicherheitsfragen überhaupt in der Wildnis existieren, ist, dass sie die Kosten bequem sparen Einige Supportanrufe von Benutzern, die nicht auf ihre E-Mail zugreifen können, um einen Reaktivierungscode zu erhalten. Dies auf Kosten der Sicherheit und des Ansehens von Sarah Palin. Es ist es wert? Wahrscheinlich nicht.

    TEIL IV: Funktion für vergessenes Passwort

    Ich habe bereits erwähnt, warum Sie niemals Sicherheitsfragen verwenden sollten

    1. Nicht reset ein vergessenes Kennwort für ein automatisch generiertes, starkes Kennwort - solche Kennwörter sind bekanntermaßen schwer zu merken, was bedeutet, dass der Benutzer das Kennwort entweder ändern oder aufschreiben muss - beispielsweise auf einem hellgelben Post-It am Rand des Monitors. Anstatt ein neues Kennwort festzulegen, lassen Sie die Benutzer einfach ein neues auswählen - was sie sowieso wollen. (Eine Ausnahme hiervon kann sein, wenn die Benutzer universell einen Passwort-Manager zum Speichern / Verwalten von Passwörtern verwenden, an die man sich normalerweise nicht erinnern kann, ohne sie aufzuschreiben.)

    2. Hash den verlorenen Passwortcode / das Token immer in der Datenbank. WIEDER , dieser Code ist ein weiteres Beispiel für ein Passwort-Äquivalent. Daher MÜSSEN Sie es unbedingt aktivieren, wenn ein Angreifer Ihre Datenbank in die Hände bekommt. Wenn ein verlorener Kennwortcode angefordert wird, senden Sie den Klartextcode an die E-Mail-Adresse des Benutzers, markieren Sie ihn, speichern Sie den Hash in Ihrer Datenbank - und verwerfen Sie das Original . So wie ein Passwort oder ein beständiges Anmelde-Token.

    Eine letzte Anmerkung: Stellen Sie sicher, dass Ihre Schnittstelle immer den Passwort-Code eingeben kann 'ist mindestens so sicher wie Ihr Anmeldeformular selbst, oder ein Angreifer verwendet einfach thstattdessen Zugang zu erhalten. Wenn Sie sicherstellen, dass Sie sehr lange "verlorene Kennwortcodes" generieren (z. B. 16 alphanumerische Zeichen, bei denen die Groß- und Kleinschreibung beachtet wird), ist dies ein guter Anfang. Erwägen Sie jedoch, dass Sie das gleiche Drosselungsschema wie für das Anmeldeformular selbst hinzufügen.

    TEIL V: Überprüfen der Kennwortstärke

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

    Okay, vielleicht ist die Liste nicht die kanonische Liste der gebräuchlichsten Kennwörter auf jedem System überall , aber es ist ein guter Hinweis darauf, wie schlecht Personen ihre Kennwörter wählen werden, wenn es keine erzwungenen Richtlinien gibt an Ort und Stelle. Außerdem sieht die Liste beängstigend aus, wenn Sie sie mit öffentlich verfügbaren Analysen kürzlich gestohlener Kennwörter vergleichen.

    Also: Ohne Mindestanforderungen an die Kennwortsicherheit verwenden 2% der Benutzer eines von den Top 20 der häufigsten Passwörter. Das bedeutet: Wenn ein Angreifer nur 20 Versuche erhält, ist jedes 50. Konto auf Ihrer Website knackbar.

    Um dies zu verhindern, müssen Sie die Entropie eines Kennworts berechnen und dann einen Schwellenwert anwenden. Das Nationale Institut für Standards und Technologie (NIST) Special Publication 800-63 hat eine sehr gute Vorschläge. Wenn in Kombination mit einer Wörterbuch- und Tastaturlayoutanalyse (z. B. 'qwertyuiop' ein falsches Kennwort ist), kann lehnen 99% aller schlecht ausgewählten Kennwörter ab auf einer Ebene von 18 Entropiebits. Berechnen Sie einfach die Kennwortstärke und ein visuelles Stärkemessgerät für einen Benutzer ist gut, aber nicht ausreichend. Es sei denn, es ist EnfoNach einiger Zeit werden viele Benutzer dies höchstwahrscheinlich ignorieren.

    Und für eine erfrischende Annäherung an die Benutzerfreundlichkeit von Kennwörtern mit hoher Entropie ist Randall Munroes Kennwortstärke xkcd wird dringend empfohlen.

    TEIL VI: Viel mehr - Oder: Schnellfeuer verhindern Anmeldeversuche

    Schauen Sie sich zuerst die Zahlen an: Geschwindigkeit der Passwortwiederherstellung - Wie lange wird Ihr Passwort aufrecht erhalten

    Wenn Sie keine Zeit haben, die Tabellen in diesem Link durchzusehen Hier ist die Liste:

    1. Es dauert so gut wie keine Zeit , ein schwaches Passwort zu knacken, selbst wenn Sie es tun mit einem Abakus knacken

    2. Es dauert praktisch keine Zeit , um ein alphanumerisches 9-stelliges Kennwort zu knacken, falls es Groß- / Kleinschreibung wird nicht berücksichtigt

    3. Es dauert so gut wie keine Zeit , um komplexe Symbole, Buchstaben, Buchstaben und Zahlen zu knacken bers, Kennwort für Groß- und Kleinschreibung, wenn es weniger als 8 Zeichen lang ist (Ein Desktop-PC kann den gesamten Schlüsselbereich mit bis zu 7 Zeichen innerhalb von Tagen oder sogar Stunden durchsuchen)

    4. Es würde jedoch unangemessen lange dauern, sogar ein 6-stelliges Passwort zu knacken, , wenn Sie auf einen Versuch pro Sekunde beschränkt wären! < / em>

    Was können wir aus diesen Zahlen lernen? Nun, viele, aber wir können uns auf den wichtigsten Teil konzentrieren: Die Tatsache, dass es sehr viele aufeinanderfolgende Anmeldeversuche (dh den Brute-Force-Angriff ) verhindert, ist wirklich nicht so schwierig. Es ist jedoch nicht so einfach, es zu verhindern, richtig .

    Im Allgemeinen haben Sie drei Optionen, die alle gegen Brute-Force-Angriffe wirken < em> (und Wörterbuchangriffe, aber da Sie bereits eine strikte Kennwortrichtlinie verwenden, sollte dies kein Problem sein) :

    • Präsentieren Sie einen CAPTCHA nach N fehlgeschlagenen Versuchen (ärgerlich und oft ineffektiv - aber ich wiederhole mich hier)

    • Konten sperren < / strong> und erfordert eine E-Mail-Bestätigung nach N fehlgeschlagenen Versuchen (Hierbei handelt es sich um einen DoS -Angriff warten)

    • Und schließlich Login-Drosselung : das Einstellen einer Zeitverzögerung zwischen Versuchen nach N fehlgeschlagenen Versuchen (ja, DoS-Angriffe sind zwar immer noch möglich, aber sie sind zumindest viel unwahrscheinlicher und komplizierter.)

    Best Practice # 1: Eine kurze Zeitverzögerung, die sich mit der Anzahl der fehlgeschlagenen Versuche erhöht, z. B .:

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

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

    Zur Klarstellung: Die Verzögerung ist nicht eine Verzögerung, bevor die Antwort an den Browser gesendet wird. Es ist eher eine Zeitüberschreitung oder eine Refraktärzeit, in der Anmeldeversuche für ein bestimmtes Konto oder eine bestimmte IP-Adresse nicht akzeptiert oder überhaupt nicht bewertet werden. Das heißt, korrekte Anmeldeinformationen werden bei einer erfolgreichen Anmeldung nicht zurückgegeben, und falsche Anmeldeinformationen lösen keine Verzögerungserhöhung aus.

    Bewährtes Verfahren 2 : Eine Zeitverzögerung von mittlerer Länge, die nach N fehlgeschlagenen Versuchen wirksam wird, wie:

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

    DoS, die dieses Schema angreifen, wäre ziemlich unpraktisch, aber durchaus machbar. Es kann auch relevant sein zu beachten, dass eine so lange Verzögerung für eine legiti sehr ärgerlich sein kannKamerad Benutzer Vergessliche Benutzer werden Sie nicht mögen.

    Best Practice # 3: Kombination der beiden Ansätze - entweder eine feste, kurze Zeitverzögerung, die nach einem N-Ausfall wirksam wird Versuche wie:

    • 1-4 Fehlversuche = keine Verzögerung
    • 5+ Fehlversuche = 20 Sekunden Verzögerung < / li>

    Oder eine zunehmende Verzögerung mit fester Obergrenze, wie:

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

    Dieses letzte Schema wurde aus den OWASP-Best Practices-Vorschlägen (Link 1 aus der MUST-READ-Liste) übernommen und sollte als bewährte Methode betrachtet werden, auch wenn dies im Rahmen des restriktive Seite.

    Als Faustregel würde ich jedoch sagen: Je stärker Ihre Passwortrichtlinie ist, desto weniger müssen Sie Benutzer Fehler melden mit Verzögerungen. Wenn Sie Kennwörter mit 9 oder mehr Zeichen (Groß- und Kleinschreibung, Groß- und Kleinschreibung und erforderliche Zahlen und Symbole) benötigen, können Sie den Benutzern 2 bis 4 nicht verzögerte Kennwortversuche erteilen, bevor Sie die Einschränkung aktivieren.

    < / blockquote>

    Ein Angriff auf dieses letzte Login-Drosselungsschema wäre sehr unpraktisch. Lassen Sie zum Abschluss immer persistente (Cookie-) Anmeldungen (und / oder ein von CAPTCHA verifiziertes Anmeldeformular) durch, damit legitime Benutzer während des Angriffs nicht einmal verzögert werden . Auf diese Weise wird der sehr unpraktische DoS-Angriff zu einem extrem unpraktischen Angriff.

    Außerdem ist es sinnvoll, die Admin-Konten aggressiver zu drosseln sind die attraktivsten Einstiegspunkte

    TEIL VII: Verteilte Brute-Force-Angriffe

    Nur nebenbei versuchen fortgeschrittenere Angreifer Umgehen der Anmeldebeschränkung durch "Verbreitung ihrer Aktivitäten":

    • Verteilen der Versuche in einem Botnet, um das Kennzeichnen von IP-Adressen zu verhindern

    • Anstatt einen Benutzer auszuwählen aWenn Sie die 50.000 gebräuchlichsten Passwörter ausprobieren (was sie aufgrund unserer Drosselung nicht können), werden sie das am häufigsten verwendete Passwort auswählen und es mit 50.000 Benutzern versuchen. Auf diese Weise werden nicht nur Maximalversuche wie CAPTCHAs und Login-Drosselung umgangen, sondern auch ihre Erfolgschancen, da das häufigste Kennwort Nr. 1 mit größerer Wahrscheinlichkeit als 49.995

    • Abstand der Anmeldeanforderungen für jedes Benutzerkonto, zum Beispiel im Abstand von 30 Sekunden, um unter dem Radar zu schleichen

    Hier empfiehlt es sich, die Protokollierung der Anzahl fehlgeschlagener Anmeldungen systemweit zu protokollieren und einen laufenden Durchschnitt der Bad-Login-Häufigkeit Ihrer Website als Grundlage für eine Obergrenze zu verwenden, die Sie dann festlegen für alle Benutzer.

    Zu abstrakt? Lassen Sie mich umformulieren:

    Angenommen, Ihre Website hatte in den letzten 3 Monaten durchschnittlich 120 fehlerhafte Anmeldungen pro Tag. Mit diesem (laufenden Durchschnitt) kann Ihr System das globale Limit auf das Dreifache setzen, d. H. 360 Fehlversuche über einen Zeitraum von 24 Stunden. Wenn die Gesamtzahl der fehlgeschlagenen Versuche für alle Konten diese Zahl innerhalb eines Tages überschreitet (oder besser, überwachen Sie die Beschleunigungsrate und den Trigger auf einen berechneten Schwellenwert), wird die systemweite Login-Drosselung aktiviert. Dies bedeutet 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 heikle Pitfals vermeiden kann bei der Abwehr verteilter Brute-Force-Angriffe

    TEIL VIII: Zwei-Faktor-Authentifizierungs- und Authentifizierungsanbieter

    Die Berechtigungsnachweise können beeinträchtigt werden, entweder durch Exploits, durch das Abschreiben von Kennwörtern und durch die Eingabe von Schlüsseln gestohlen oder Benutzer, die sich in Phishing-Sites einloggen. Anmeldungen können durch Zwei-Faktor-Authentifizierung weiter geschützt werden

    18 July 2018
    46 revs, 31 users 31%Jens Roland
  • Endgültiger Artikel

    Senden von Anmeldeinformationen

    Die einzige praktische Möglichkeit, Anmeldeinformationen zu 100% sicher zu senden, ist die Verwendung von < a href = "http://en.wikipedia.org/wiki/SSL" rel = "noreferrer"> SSL . Die Verwendung von JavaScript zum Hashing des Passworts ist nicht sicher. Häufige Fehler beim clientseitigen Passwort-Hashing:

    • Wenn die Verbindung zwischen Client und Server unverschlüsselt ist, müssen Sie nur vulnerable für Man-in-the-Middle-Angriffe . Ein Angreifer könnte das eingehende Javascript ersetzen, um das Hashing zu brechen oder alle Anmeldeinformationen an seinen Server zu senden, die Antworten des Kunden zu hören und die Benutzer perfekt zu benennen usw. usw. SSL mit vertrauenswürdigen Zertifizierungsstellen soll MitM-Angriffe verhindern.
    • Das vom Server empfangene gehashte Kennwort ist weniger Sichern Sie , wenn Sie keine zusätzlichen, redundanten Arbeiten auf dem Server ausführen.

    Es gibt eine andere sichere Methode mit dem Namen SRP , aber es ist patentiert (obwohl es frei lizenziert ist) und es gibt einige gute Implementierungen.

    Speichern von Passwörtern

    Speichern Sie Passwörter niemals als Klartext in der Datenbank. Auch nicht, wenn Sie sich nicht für die Sicherheit Ihrer eigenen Website interessieren. Angenommen, einige Benutzer verwenden das Kennwort ihres Online-Bankkontos wieder. Speichern Sie also das gehashte Passwort und werfen Sie das Original weg. Stellen Sie sicher, dass das Kennwort nicht in Zugriffsprotokollen oder Anwendungsprotokollen angezeigt wird. OWASP empfiehlt die Verwendung von Argon2 als erste Wahl für neue Anwendungen. Ist dies nicht verfügbar, können Sie PBKDF2 oder scrypt sho verwendenstattdessen verwendet werden. Und wenn keine der oben genannten Möglichkeiten verfügbar ist, verwenden Sie bcrypt.

    Hashes selbst sind ebenfalls unsicher. Beispielsweise bedeuten identische Passwörter identische Hashes - Hash-Lookup-Tabellen sind daher eine effektive Möglichkeit, viele Passwörter gleichzeitig zu knacken. Speichern Sie stattdessen den Hash Salted . Ein Salt ist eine Zeichenfolge, die vor dem Hashing an das Kennwort angehängt wird. Verwenden Sie für jeden Benutzer ein anderes (zufälliges) Salt. Der Salt ist ein öffentlicher Wert, also können Sie sie mit dem Hash in der Datenbank speichern. Weitere Informationen finden Sie hier .

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

    Sicherheit Fragen

    Sicherheitsfragen sind unsicher - vermeiden Sie deren Verwendung. Warum? Alles, was eine Sicherheitsfrage tut, ist ein Passwort besser. Lesen Sie TEIL III: Verwenden geheimer Fragen in @Jens Roland Beantworten Sie hier in diesem Wiki.

    Sitzungscookies

    Nachdem sich der Benutzer angemeldet hat, sendet der Server den Benutzer a Session-Cookie. Der Server kann den Benutzernamen oder die ID aus dem Cookie abrufen, aber niemand kann ein solches Cookie generieren (TODO-Erklärungsmechanismen).

    Cookies können missbraucht werden : Sie sind nur so sicher wie der Rest des Computers des Kunden und andere Kommunikationen. Sie können von der Festplatte gelesen, im Netzwerkverkehr entdeckt werden, durch einen siteübergreifenden Skripting-Angriff gehemmt und von einem vergifteten DNS abgeholt werden, sodass der Client seine Cookies an die falschen Server sendet. Senden Sie keine dauerhaften Cookies. Cookies sollten am Ende der Client-Sitzung ablaufen (browser Schließen oder Verlassen Ihrer Domain).

    Wenn Sie Ihre Benutzer automatisch anmelden möchten, können Sie einen permanenten Cookie setzen, der sich jedoch von einem Full-Session-Cookie unterscheiden sollte. Sie können ein zusätzliches Flag setzen, das der Benutzer automatisch angemeldet hat und sich für sensible Vorgänge anmelden muss. Dies ist bei Shopping-Sites beliebt, die Ihnen ein nahtloses, personalisiertes Einkaufserlebnis bieten möchten und dennoch Ihre finanziellen Details schützen. Wenn Sie beispielsweise zu Amazon zurückkehren, wird eine Seite angezeigt, die aussieht, als wären Sie angemeldet. Wenn Sie jedoch eine Bestellung aufgeben (oder Ihre Lieferadresse, Ihre Kreditkarte usw. ändern), werden Sie zur Bestätigung aufgefordert Ihr Passwort.

    Auf Finanzwebsites wie Banken und Kreditkarten werden dagegen nur vertrauliche Daten gespeichert, die keine automatische Anmeldung oder einen Modus mit niedriger Sicherheit zulassen.

    Liste der externen Ressourcen

  • Erstens, ein starker Vorbehalt, dass diese Antwort für diese genaue Frage nicht optimal ist. Es sollte definitiv nicht die beste Antwort sein!

    Ich werde weitermachen und Mozillas Vorschlag erwähnen BrowserID (oder genauer gesagt das Verified Email Protocol ) im Geiste von einem Upgrade-Pfad zu besseren Ansätzen für die Authentifizierung in der Zukunft.

    Ich fasse es so zusammen:

    1. Mozilla ist ein gemeinnütziger Verein mit Werten , die sich gut mit der Suche nach guten Lösungen verbinden
    2. Die Realität heute ist, dass die meisten Websites formularbasierte Authentifizierung verwenden.
    3. Die formularbasierte Authentifizierung hat einen großen Nachteil, was das Risiko erhöht Phishing . Die Benutzer werden aufgefordert, vertrauliche Informationen in einen Bereich einzugeben, der von einer entfernten Entität kontrolliert wird, und nicht in einen Bereich, der von ihrem Benutzeragenten (Browser) kontrolliert wird.
    4. Da Browser implizit vertrauenswürdig sind (die gesamte Idee eines User Agent soll für den Benutzer handeln), sie können dazu beitragen, diese Situation zu verbessern.
    5. Die Hauptkraft, die den Fortschritt hier zurückhält, ist Deadlock der Bereitstellung . Lösungen müssen in Schritte zerlegt werden, die von sich aus einen inkrementellen Vorteil bieten.
    6. Die einfachste dezentrale Methode zum Ausdrücken von Identität, die in die Internetinfrastruktur eingebaut ist, ist der Domänenname.
    7. Als zweite Identitätsstufe verwaltet jede Domäne ihre eigenen Konten.
    8. Das Formular "eine ccount@< / code> -Domäne" ist knapp und wird von einer breiten Domäne unterstützt Reihe von Protokollen und URI-Schemata. Eine solche Kennung wird natürlich am ehesten als E-Mail-Anzeige erkanntdress.
    9. E-Mail-Anbieter sind bereits de facto die primären Identitätsanbieter im Internet. Bei aktuellen Kennwortrücksetzflüssen können Sie normalerweise die Kontrolle über ein Konto übernehmen, wenn Sie nachweisen können, dass Sie die zugehörige E-Mail-Adresse dieses Kontos steuern.
    10. Es wurde vorgeschlagen, dass das Verified Email Protocol eine sichere Methode basierend auf der Öffentlichkeit bietet Schlüsselkryptografie, zur Vereinfachung des Nachweises für Domäne B, dass Sie über ein Konto in Domäne A verfügen.
    11. Für Browser, die nicht das Verified Email Protocol (derzeit alle) unterstützen, Mozilla stellt ein Shim bereit, das das Protokoll in clientseitigem JavaScript-Code implementiert.
    12. Bei E-Mail-Diensten, die das Verified Email Protocol nicht unterstützen, können Dritte durch das Protokoll als vertrauenswürdiger Vermittler agieren dass sie das Eigentum eines Benutzers an einem Konto bestätigt haben. Es ist nicht wünschenswert, eine große Anzahl solcher Dritter zu haben. Diese Funktion soll nur einen Aktualisierungspfad zulassen, und es wird bevorzugt, dass E-Mail-Dienste diese Zusicherungen selbst bereitstellen.
    13. Mozilla bietet einen eigenen Dienst an, der als vertrauenswürdiger Dritter fungiert. Dienstanbieter (dh vertrauende Parteien), die das verifizierte E-Mail-Protokoll implementieren, können Mozillas Behauptungen vertrauen oder nicht. Der Dienst von Mozilla überprüft den Besitz des Kontos der Benutzer auf herkömmliche Weise, indem eine E-Mail mit einem Bestätigungslink gesendet wird.
    14. Dienstanbieter können dieses Protokoll natürlich zusätzlich zu jeder anderen Methode als Option anbieten ( s) der Authentifizierung, die sie möglicherweise anbieten möchten.
    15. Ein großer Vorteil der Benutzeroberfläche, der hier gesucht wird, ist der "Identitätsselektor". Wenn ein Benutzer eine Website besucht und sich für die Authentifizierung entscheidet, zeigt sein Browser eine Auswahl von E-Mail-Adressen an ("persönliche", "Arbeit", "politischer Aktivismus" usw.), die er zur Identifizierung der Site verwenden kann.
    16. Ein weiterer großer Vorteil der Benutzeroberfläche, der im Rahmen dieser Bemühungen gesucht wird, ist
07 November 2012
8 revs, 3 users 78%Charlie
  • Ich dachte nur, ich würde diese Lösung teilen, von der ich herausfand, dass sie gut funktioniert.

    Ich nenne sie das Dummy-Feld (obwohl ich das nicht erfunden habe, schreiben Sie mir also nichts.)

    Kurz gesagt: Sie müssen dies nur in Ihre <form> einfügen und prüfen, ob es leer ist at at validation:

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

    Der Trick besteht darin, einen Bot zu täuschen zu denken, er müsste Daten in ein erforderliches einfügen Feld, deshalb habe ich die Eingabe "E-Mail" genannt. Wenn Sie bereits ein Feld namens email haben, das Sie verwenden, sollten Sie dem Dummy-Feld einen anderen Namen geben, beispielsweise "company", "phone" oder "emailaddress". Wählen Sie einfach etwas aus, von dem Sie wissen, dass Sie es nicht brauchen, und was sich anhört, als würden die Leute es normalerweise für logisch halten, ein Webformular auszufüllen. Blenden Sie nun das Feld input mit CSS oder JavaScript / jQuery aus - je nachdem, was Ihnen am besten passt - einfach nicht setzen Sie die Eingabe type auf hidden .

    Wenn Sie das Formular (Client- oder Serverseite) überprüfen, prüfen Sie, ob Ihr Dummy-Feld gefüllt wurde, um festzustellen, ob es von einem Mitarbeiter oder einem Bot gesendet wurde.

    Beispiel:

    Im Falle eines Menschen: Der Benutzer sieht das Dummy-Feld nicht (in meinem Fall "email") und versucht nicht, es auszufüllen. Der Wert des Dummy-Felds sollte also nach dem Senden des Formulars noch leer sein.

    Im Falle eines Bot: Der Bot sieht ein Feld deren Typ text und ein Name email ist (oder wie auch immer Sie es nennen) und versucht logisch, es mit den entsprechenden Daten zu füllen. Es macht nichts aus, wenn Sie das Eingabeformular mit ein paar ausgefallenen CSS gestylt haben. Webentwickler machen das ständig. Was auch immer der Wert im Dummy-Feld ist, ist uns egal, solange er größer als 0 Zeichen ist.

    Ich habe diese Methode in einem Gästebuch in Kombination mit CAPTCHA , und ich habe & # 3

    13 November 2012
    3 revs, 3 users 87%Pieter888
  • Ich denke nicht, dass die obige Antwort "falsch" ist, aber es gibt große Bereiche der Authentifizierung, die nicht angesprochen werden (bzw. der Schwerpunkt liegt auf "wie man Cookiesitzungen umsetzt"), nicht auf den "Optionen" verfügbar und was sind die Kompromisse ".

    Meine vorgeschlagenen Änderungen / Antworten sind

    • Das Problem liegt mehr bei der Kontoeinrichtung als bei der Passwortprüfung.
    • Die Verwendung der Zwei-Faktor-Authentifizierung ist wesentlich sicherer als die Verwendung geschickterer Mittel zur Passwortverschlüsselung.
    • Do Versuchen Sie NICHT, Ihr eigenes Anmeldeformular oder Ihre Datenbank für das Speichern von Passwörtern zu implementieren, es sei denn, die gespeicherten Daten sind bei der Kontoerstellung wertlos und werden automatisch generiert (dh Web 2.0-Stil wie Facebook, Flickr , etc.)

      1. Die Digest-Authentifizierung basiert auf Standards Dieser Ansatz wird in allen gängigen Browsern und Servern unterstützt, der auch über einen sicheren Kanal kein Kennwort sendet.
    < p > Dadurch werden keine "Sitzungen" oder Cookies benötigt, da der Browser die Kommunikation jedes Mal neu verschlüsselt. Dies ist der "leichteste" Entwicklungsansatz.

    Allerdings empfehle ich diesen Service nicht, außer für öffentliche Dienste von geringem Wert. Dies ist ein Problem bei einigen der anderen Antworten - versuchen Sie nicht, serverseitige Authetisierungsmechanismen erneut zu implementieren. Dieses Problem wurde behoben und wird von den meisten gängigen Browsern unterstützt. Verwenden Sie keine Cookies. Speichern Sie nichts in Ihrer eigenen handgerollten Datenbank. Fragen Sie einfach auf Anfrage, ob die Anfrage authentifiziert ist. Alles andere sollte durch Konfiguration und vertrauenswürdige Software von Drittanbietern unterstützt werden.

    Also ...

    Zuerst verwirren wir die Erstes Anlegen eines Kontos (mit Passwort) mit anschließendem Überprüfen des Passworts. Wenn ich Flickr bin und Ihre Website zum ersten Mal erstellt habe, hat der neue Benutzer Zugriff auf den Wert Null (leerer Webspace). Ich bin wirklich kein Autoe wenn die Person, die das Konto erstellt, über ihren Namen lügt. Wenn ich ein Konto des Krankenhaus-Intranets / Extranets erstelle, liegt der Wert in allen Krankenakten, und so kümmere ich mich um die Identität (*) des Kontoerstellers.

    Dies ist der sehr schwierige Teil. Die anständige Lösung only ist ein Netz des Vertrauens. Zum Beispiel treten Sie als Arzt in das Krankenhaus ein. Sie erstellen eine Website, die irgendwo mit Ihrem Foto, Ihrer Passnummer und einem öffentlichen Schlüssel gehostet wird, und haken sie alle mit dem privaten Schlüssel ein. Sie besuchen dann das Krankenhaus, und der Systemadministrator sieht Ihren Pass an, stellt fest, ob das Foto zu Ihnen passt, und hasht dann den Webseiten- / Foto-Hash mit dem privaten Schlüssel des Krankenhauses. Ab sofort können wir Schlüssel und Token sicher austauschen. So wie jeder, der dem Krankenhaus vertraut (es gibt übrigens die geheime Sauce). Der Systemadministrator kann Ihnen auch einen RSA -Dongle oder eine andere Zwei-Faktor-Authentifizierung zur Verfügung stellen.

    Aber dies ist eine Reihe von Ärger und nicht sehr Web 2.0. Dies ist jedoch die einzige sichere Methode zum Erstellen neuer Konten, die Zugriff auf wertvolle Informationen haben, die nicht selbst erstellt werden.

    1. Kerberos und SPNEGO - Single-Sign-On-Mechanismen bei einem vertrauenswürdigen Dritten - Der Benutzer überprüft grundsätzlich gegen einen vertrauenswürdigen Dritten. (NB: Dies ist in keiner Weise das nicht vertrauenswürdige OAuth )

    2. SRP - eine Art clevere Kennwortauthentifizierung ohne Vertrauenswürdigkeit dritte Seite. Aber hier kommen wir in den Bereich "Es ist sicherer, die Zwei-Faktor-Authentifizierung zu verwenden, auch wenn dies kostspieliger ist"

    3. SSL - Clientseite - Geben Sie den Clients ein öffentliches Schlüsselzertifikat (Unterstützung in allen gängigen Browsern) - wirft jedoch eine Frage auf

    09 November 2012
    4 revs, 3 users 76%you cad sir - take that
  • Verwenden Sie beim Hashing keine schnellen Hash-Algorithmen wie MD5 (es gibt viele Hardware-Implementierungen). Verwenden Sie so etwas wie SHA-512. Für Kennwörter sind langsamere Hashes besser.

    Je schneller Sie Hashes erstellen können, desto schneller kann jeder Brute-Force-Checker arbeiten. Langsamere Hashes verlangsamen daher das Brute Forcing. Ein langsamer Hash-Algorithmus macht das Brute-Forcieren für längere Kennwörter (8-stellig +)

    unpraktisch
    04 August 2013
    2 revs, 2 users 50%josh
  • Ein guter Artikel zur realistischen Schätzung der Kennwortstärke lautet:

  • 24 April 2015
    3 revs, 3 users 54%blade19899
  • Ich möchte einen Vorschlag hinzufügen, den ich verwendet habe, basierend auf einer umfassenden Verteidigung. Sie müssen nicht das gleiche auth & amp; auth-System für Admins haben als normale Benutzer. Sie können ein separates Anmeldeformular für eine separate URL einrichten, das separaten Code für Anforderungen ausführt, die hohe Berechtigungen gewähren. Dies kann eine Auswahl treffen, die für normale Benutzer ein totaler Schmerz wäre. So habe ich beispielsweise die Anmelde-URL für den Administratorzugriff verschlüsselt und dem Administrator die neue URL per E-Mail gesendet. Stoppt jeden Brute-Force-Angriff sofort, da Ihre neue URL willkürlich schwierig sein kann (sehr lange zufällige Zeichenfolge). Ihr Admin-Benutzer kann jedoch nur auf einen Link in seiner E-Mail zugreifen. Der Angreifer weiß nicht mehr, wohin er überhaupt gehen soll.

    18 July 2015
    Iain Duncan
  • Ich weiß nicht, ob es am besten war, dies als Antwort oder als Kommentar zu beantworten. Ich entschied mich für die erste Option.

    In Bezug auf das Poing TEIL IV: Funktion für vergessenes Passwort in der ersten Antwort möchte ich etwas zu Timing-Attacken sagen.

    In den Formularen Kennwort speichern kann ein Angreifer möglicherweise eine vollständige Liste der E-Mails prüfen und ermitteln, welche im System registriert sind (siehe Link unten). .

    In Bezug auf das "Forgotten Password" -Formular würde ich hinzufügen, dass es eine gute Idee ist, zwischen erfolgreichen und nicht erfolgreichen Abfragen mit einer Verzögerungsfunktion gleichzusetzen.

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

    16 August 2015
    xyz