security - software - was ist marketo




Der definitive Leitfaden zur formularbasierten Website-Authentifizierung (8)

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 für allgemeine Richtlinien zur Lösung von Variationen häufiger Probleme. "Formularbasierte Authentifizierung für Websites" sollte ein gutes Thema für ein solches Experiment sein.

Es sollte Themen enthalten wie:

  • Wie melde ich mich an?
  • Wie melde ich mich ab?
  • So bleiben Sie angemeldet
  • Cookies verwalten (einschließlich empfohlener Einstellungen)
  • SSL / HTTPS-Verschlüsselung
  • Wie speichert man Passwörter?
  • Mit geheimen Fragen
  • Benutzername / Passwort-Funktion vergessen
  • Verwendung von nonces , um standortübergreifende Anfragenfälschungen (CSRF) zu verhindern
  • OpenID
  • Kontrollkästchen "Erinnere dich an mich"
  • Browser-automatische Vervollständigung von Benutzernamen und Passwörtern
  • Geheime URLs (öffentliche URL durch Digest geschützt)
  • Passwortstärke überprüfen
  • E-Mail-Bestätigung
  • und vieles mehr zur formularbasierten Authentifizierung ...

Es sollte keine Dinge enthalten wie:

  • Rollen und Autorisierung
  • HTTP-Basisauthentifizierung

Bitte helfen Sie uns durch:

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

Endgültiger Artikel

Anmeldeinformationen senden

Die einzige praktische Methode zum sicheren Senden von Anmeldeinformationen 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 Client und Server unverschlüsselt ist, ist alles, was Sie tun, anfällig für Man-in-the-Middle-Angriffe . Ein Angreifer könnte das ankommende Javascript ersetzen, um das Hashing zu brechen oder alle Anmeldeinformationen an seinen Server zu senden, die Antworten des Kunden abhören und die Benutzer perfekt imitieren, usw. usw. SSL mit vertrauenswürdigen Zertifizierungsstellen soll MitM-Angriffe verhindern.
  • Das gehashte Kennwort, das vom Server empfangen wird, ist weniger sicher, wenn Sie keine zusätzlichen, redundanten Arbeiten auf dem Server ausführen.

Es gibt eine andere sichere Methode namens SRP , die jedoch patentiert ist (obwohl sie frei lizenziert ist ), und es gibt nur wenige gute Implementierungen.

Kennwörter speichern

Speichern Sie Kennwörter niemals als Klartext in der Datenbank. Auch 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, sollte stattdessen PBKDF2 oder scrypt verwendet werden. Und wenn keine der oben genannten Möglichkeiten verfügbar ist, verwenden Sie bcrypt.

Hashes an sich 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 gesalzenen Hash. 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, Sie können sie also mit dem Hash in der Datenbank speichern. Mehr dazu hier.

Das bedeutet, dass Sie dem Benutzer nicht die vergessenen Kennwörter senden können (da 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 E-Mails lesen können, die an die gespeicherte (und validierte) E-Mail-Adresse gesendet werden.)

Sicherheitsfragen

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

Session-Cookies

Nachdem sich der Benutzer angemeldet hat, sendet der Server dem Benutzer ein Sitzungscookie. 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 Cross-Site-Scripting-Angriff aufgehoben werden, von einem vergifteten DNS aus phishing, sodass der Client seine Cookies an die falschen Server sendet. Senden Sie keine dauerhaften Cookies. Cookies sollten am Ende der Clientsitzung ablaufen (Browser schließen oder Domain verlassen).

Wenn Sie sich automatisch bei Ihren Benutzern anmelden möchten, können Sie ein dauerhaftes Cookie setzen. Dieses Cookie sollte sich jedoch von einem Full-Session-Cookie unterscheiden. 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.

Finanzwebsites wie Banken und Kreditkarten enthalten dagegen nur sensible Daten und sollten keine automatische Anmeldung oder einen Modus mit niedriger Sicherheit zulassen.

Liste der externen Ressourcen


TEIL I: Wie melde ich mich an?

Wir gehen davon aus, dass Sie bereits wissen, wie Sie ein Anmelde- und Kennwort-HTML-Formular erstellen, das die Werte zur Authentifizierung an ein Skript auf dem Server sendet. In den folgenden Abschnitten wird beschrieben, wie Sie Muster für die Klangpraxis erstellen und wie Sie die häufigsten Sicherheitsrisiken vermeiden.

Zu HTTPS oder nicht zu HTTPS?

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

Im Wesentlichen ist die einzige praktische Möglichkeit zum Schutz vor Abhören / Packet Sniffing während der Anmeldung die Verwendung von HTTPS oder eines anderen zertifikatsbasierten Verschlüsselungsschemas (z. B. TLS ) oder eines bewährten und getesteten Challenge-Response-Schemas (z. B. Diffie-Hellman SRP). Jede andere Methode kann von einem abhörenden Angreifer leicht umgangen werden.

Wenn Sie bereit sind, etwas unpraktisch zu werden, können Sie natürlich auch ein Zwei-Faktor-Authentifizierungsschema verwenden (z. B. die Google Authenticator-App, ein physisches Codebuch „Cold War Style“ oder einen 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-Faktor-Authentifizierung, jedoch nicht SSL, zu implementieren.

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

Angesichts der geringen Kosten und der wahrscheinlichen technischen Schwierigkeit, ein SSL-Zertifikat auf Ihrer Website einzurichten, sind einige Entwickler versucht, ihre eigenen Browser-Hashing- oder -Verschlüsselungsverfahren zu verwenden, um zu vermeiden, dass Klartext-Logins über eine ungesicherte Verbindung übertragen werden.

Dies ist zwar ein edler Gedanke, aber im Wesentlichen unbrauchbar (und kann ein Sicherheitsmangel sein ), sofern er nicht mit einem der oben genannten kombiniert wird - das heißt, entweder die Sicherung der Leitung durch starke Verschlüsselung oder die Verwendung einer bewährten Challenge-Response Mechanismus (wenn Sie nicht wissen, was das ist, wissen Sie einfach, dass dies einer der schwierigsten zu beweisen ist, der am schwierigsten zu entwerfen ist und der am schwierigsten ist, Konzepte in der digitalen Sicherheit zu implementieren).

Es ist zwar wahr, dass das Hashing des Passworts gegen die Offenlegung von Passwörtern wirksam sein kann , es ist jedoch anfällig für Wiederholungsangriffe, Man-In-The-Middle-Angriffe / -Hijackings (wenn ein Angreifer einige Bytes in Ihre ungesicherte HTML-Seite einschleusen kann, bevor er Sie erreicht Browser können sie das Hashing in JavaScript einfach auskommentieren) oder Brute-Force-Angriffe (da Sie dem Angreifer sowohl den Benutzernamen als auch das Salt- und das Hash-Kennwort übergeben).

CAPTCHAS gegen die Menschheit

CAPTCHAs sollen einer bestimmten Angriffskategorie entgegenwirken: automatisiertes Wörterbuch und 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 unwirksam (laut OWASP liegt die derzeitige Sweatshop-Rate bei $ 12 pro 500 Tests), und einige Implementierungen sind möglicherweise möglich technisch in einigen Ländern illegal (siehe OWASP-Authentifizierungs-Spickzettel ). Wenn Sie ein CAPTCHA verwenden müssen, verwenden Sie das reCAPTCHA Google, da es per Definition OCR-hard ist (da es bereits OCR-falsch klassifizierte Buchscans verwendet) und sehr bemüht ist, benutzerfreundlich zu sein.

Ich persönlich finde CAPTCHAS ärgerlich und benutze sie nur als letzte Möglichkeit, wenn sich ein Benutzer mehrmals nicht angemeldet hat und die Throttling-Verzögerungen maximal sind. Dies wird selten genug passieren, um akzeptabel zu sein, und es stärkt das System als Ganzes.

Kennwörter speichern / Anmeldungen überprüfen

Nach all den vielfach publizierten Hacks und Datenlecks, die wir in den letzten Jahren gesehen haben, 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 die SQL-Injektion ausgelesen. Wenn Sie rohe Klartextpasswörter speichern, ist dies für Ihre Anmeldesicherheit ein sofortiges Spiel.

Wenn Sie das Passwort nicht speichern können, wie können Sie also überprüfen, ob die Kombination Login + Passwort POSTed vom 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 in Ihrer Datenbank gespeicherten Wert. Argon2, bcrypt und scrypt speichern das Salt bereits mit dem Hash. Weitere Informationen finden Sie in diesem article unter sec.stackexchange.

Der Grund für die Verwendung eines Salzes ist, dass das Hashing an sich nicht ausreicht. Sie sollten ein sogenanntes "Salz" hinzufügen, um den Hash vor Regenbogentischen zu schützen. 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 durch einen Angreifer mit Zugriff auf die Hashes in relativ kurzer Zeit abgeschlossen werden kann. Aus diesem Grund wird eine KDF verwendet. Dies bedeutet, dass bei jedem Kennwort, das ein Angreifer vermutet, der Hash-Algorithmus mehrmals wiederholt wird, beispielsweise 10.000 Mal, wodurch das Kennwort des Angreifers 10.000 Mal langsamer wird.

Sitzungsdaten - "Sie sind als Spiderman69 angemeldet"

Nachdem der Server den Benutzernamen und das Kennwort anhand Ihrer Benutzerdatenbank überprüft und eine Übereinstimmung gefunden hat, muss das System wissen, 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: Eine einzelne, zufällig generierte Zeichenfolge wird in einem abgelaufenen Cookie gespeichert und dient zum Referenzieren einer Sammlung von Daten - den Sitzungsdaten -, die auf dem Server gespeichert sind. Wenn Sie ein MVC-Framework verwenden, wird dies zweifellos bereits behandelt.

Stellen Sie nach Möglichkeit sicher, dass für das Sitzungscookie die sicheren Kennzeichen "Nur" 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 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 angegeben wird, das auf eine nicht vorhandene Sitzung verweist, sollte der Wert sofort ersetzt werden, um eine Sitzungsfixierung zu verhindern.

TEIL II: So bleiben Sie angemeldet - Das berüchtigte Kontrollkästchen "Remember Me"

Persistent Login Cookies ("Remember Me" -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 möglicherweise 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.

Persönlich mag ich dauerhafte Anmeldungen für die Webseiten, die ich regelmäßig besuche, aber ich weiß, wie ich mit ihnen sicher umgehen 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 zu den Benutzern unserer Benutzer gehen und all diese Face-It-Notizen mit Passwörtern mit Passwörtern abreißen, die sie am Rand ihrer Monitore aufgereiht haben.

Natürlich können manche Systeme es nicht leisten, dass Konten gehackt werden. Für solche Systeme können Sie keine dauerhaften Anmeldungen rechtfertigen.

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

  1. Nehmen Sie sich zunächst etwas Zeit, um den Artikel der Paragon-Initiative zu diesem Thema zu lesen. Sie müssen eine Reihe von Elementen richtig zusammenstellen, und der Artikel erklärt die einzelnen Elemente hervorragend.

  2. Um nur eines der häufigsten Fallbeispiele zu wiederholen, HALTEN SIE DEN PERSISTENTEN LOGIN-COOKIE (TOKEN) NICHT IN IHRER DATENBANK AUF, NUR HASCHEN! Das Login-Token ist Password Equivalent. Wenn also ein Angreifer Ihre Datenbank in die Hände bekommen hat, könnte er sich mit den Token bei jedem Konto anmelden, als wären es Klartext-Login-Passwort-Kombinationen. Verwenden Sie daher Hashing (gemäß https://security.stackexchange.com/a/63438/5002 ), wenn Sie einen persistenten Login-Token speichern.

TEIL III: Mit geheimen Fragen

Implementiere keine "geheimen Fragen" . 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! 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 wählen die meisten Benutzer höchstwahrscheinlich entweder:

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

  • Eine einfache Kleinigkeit, die jeder von seinem Blog, LinkedIn Profil oder ähnlichem abrufen kann

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

Zusammenfassend sind Sicherheitsfragen in praktisch allen ihren Formen und Variationen von Natur aus unsicher und sollten aus keinem Grund in einem Authentifizierungsschema verwendet werden.

Der wahre Grund, warum Sicherheitsfragen sogar in der Wildnis existieren, ist, dass sie bequem die Kosten für einige Supportanfragen von Benutzern sparen, die nicht auf ihre E-Mails 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 für den Umgang mit vergessenen / verlorenen Benutzerpasswörtern verwenden sollten. Es versteht sich von selbst, dass Sie Benutzern niemals ihre tatsächlichen Passwörter per E-Mail senden sollten. In diesem Bereich sind mindestens zwei allzu häufige Fallstricke zu vermeiden:

  1. Setzen Sie ein vergessenes Kennwort nicht auf ein automatisch generiertes sicheres Kennwort zurück. Solche Kennwörter sind bekanntermaßen schwer zu merken. Das 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 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 das verlorene Passwort / Token immer in der Datenbank. Dieser Code ist WIEDER ein weiteres Beispiel für ein Passwort-Äquivalent. Sie MÜSSEN daher gehasht werden, falls ein Angreifer in Ihre Datenbank gelangt. 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 werfen Sie das Original weg . Genau wie ein Passwort oder ein dauerhaftes Login-Token.

Eine letzte Anmerkung: Stellen Sie immer sicher, dass Ihre Benutzeroberfläche für die Eingabe des Kennworts für verlorene Kennwörter mindestens so sicher ist wie Ihr Anmeldeformular selbst. Andernfalls wird ein Angreifer dieses verwenden, um Zugriff 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 Passwortstärke

Zunächst sollten Sie diesen kleinen Artikel für einen Reality-Check lesen: Die 500 häufigsten Passwörter

Okay, vielleicht ist die Liste nicht die kanonische Liste der gebräuchlichsten Passwörter auf einem System, aber es ist ein guter Hinweis darauf, wie schlecht Menschen ihre Passwörter wählen werden, wenn es keine durchgesetzten Richtlinien gibt. Darüber hinaus sieht die Liste in der Nähe des Hauses beängstigend aus, wenn Sie sie mit öffentlich verfügbaren Analysen kürzlich gestohlener Kennwörter vergleichen.

Also: Ohne Mindestanforderungen an 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 einer von 50 Konten auf Ihrer Website knackbar.

Um dies zu verhindern, müssen Sie die Entropie eines Kennworts berechnen und anschließend einen Schwellenwert anwenden. Die Sonderpublikation 800-63 des National Institute of Standards and Technology (NIST) enthält sehr gute Vorschläge. In Kombination mit einer Wörterbuch- und Tastaturlayoutanalyse (z. B. "qwertyuiop" ist ein falsches Kennwort), können 99% aller schlecht ausgewählten Kennwörter auf einer Ebene von 18 Bit Entropie zurückgewiesen werden. Das einfache Berechnen der Passwortstärke und das Anzeigen eines visuellen Stärkemessers für einen Benutzer ist gut, aber nicht ausreichend. Wenn es nicht erzwungen wird, werden viele Benutzer es höchstwahrscheinlich ignorieren.

Um die Benutzerfreundlichkeit der Passwörter mit hoher Entropie aufzufrischen, ist Randall Munroes Password Strength xkcd sehr zu empfehlen.

TEIL VI: Viel mehr - Oder: Schnellversuche beim Login verhindern

Sehen Sie sich zunächst die Zahlen an: Password Recovery-Geschwindigkeiten - Wie lange wird Ihr Passwort aufrechterhalten?

Wenn Sie nicht die Zeit haben, die Tabellen in diesem Link zu durchsuchen, finden Sie hier eine Liste:

  1. Es ist praktisch keine Zeit , ein schwaches Passwort zu knacken, selbst wenn Sie es mit einem Abakus knacken

  2. Es dauert praktisch keine Zeit , ein alphanumerisches 9-stelliges Kennwort zu knacken, wenn die Groß- und Kleinschreibung nicht beachtet wird

  3. Es dauert praktisch keine Zeit , ein kompliziertes Kennwort (Groß- und Kleinbuchstaben) mit Symbolen und Buchstaben und Zahlen zu knacken, wenn es weniger als 8 Zeichen umfasst (ein Desktop-PC kann den gesamten Schlüsselbereich mit bis zu 7 Zeichen in einem Buchstaben durchsuchen Angelegenheit von Tagen oder sogar Stunden)

  4. Es wäre jedoch unangemessen lang, sogar ein 6-stelliges Passwort zu knacken, wenn Sie auf einen Versuch pro Sekunde beschränkt wären!

Was können wir also aus diesen Zahlen lernen? Nun, viele, aber wir können uns auf den wichtigsten Teil konzentrieren: Die Tatsache, dass es sehr viele aufeinanderfolgende Anmeldeversuche (z. B. den Brute-Force- Angriff) verhindert, ist nicht so schwierig. Aber es zu verhindern, ist nicht so einfach, wie es scheint.

Im Allgemeinen stehen Ihnen drei Optionen zur Verfügung, die alle gegen Brute-Force-Angriffe (und Wörterbuchangriffe) wirksam sind. Da Sie jedoch bereits eine strikte Kennwortrichtlinie verwenden, sollten sie kein Problem darstellen.

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

  • Konten sperren und E-Mail-Bestätigung nach N fehlgeschlagenen Versuchen anfordern (dies ist ein DoS Angriff, der gerade wartet)

  • Und schließlich die Login-Drosselung : Das heißt, eine Zeitverzögerung zwischen Versuchen nach N fehlgeschlagenen Versuchen einstellen (Ja, DoS-Angriffe sind immer noch möglich, aber zumindest sind sie weitaus weniger wahrscheinlich und viel schwieriger zu machen).

Best Practice Nr. 1: Eine kurze Zeitverzögerung, die mit der Anzahl der fehlgeschlagenen Versuche zunimmt, z.

  • 1 fehlgeschlagener Versuch = keine Verzögerung
  • 2 Fehlversuche = 2 Sek. Verzögerung
  • 3 Fehlversuche = 4 Sek. Verzögerung
  • 4 Fehlversuche = 8 Sek. Verzögerung
  • 5 Fehlversuche = 16 Sek. Verzögerung
  • usw.

Ein DoS-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 keine 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 von einer bestimmten IP-Adresse aus nicht akzeptiert oder ausgewertet werden. Das heißt, korrekte Anmeldeinformationen werden bei einer erfolgreichen Anmeldung nicht zurückgegeben, und falsche Anmeldeinformationen lösen keine Verzögerungserhöhung aus.

Best Practice 2: Eine Zeitverzögerung von mittlerer Länge, die nach N fehlgeschlagenen Versuchen wirksam wird, z.

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

Ein DoS-Angriff auf dieses Schema wäre ziemlich unpraktisch, aber durchaus machbar. Es kann auch relevant sein zu beachten, dass eine solch lange Verzögerung für einen rechtmäßigen Benutzer sehr ärgerlich sein kann. Vergessliche Benutzer werden Sie nicht mögen.

Best Practice Nr. 3: Kombination der beiden Ansätze - entweder eine feste, kurze Zeitverzögerung, die nach N fehlgeschlagenen Versuchen wirksam wird, z.

  • 1-4 Fehlversuche = keine Verzögerung
  • 5+ Fehlversuche = 20 Sek. Verzögerung

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

  • 1 fehlgeschlagener Versuch = 5 Sek. Verzögerung
  • 2 Fehlversuche = 15 Sek. Verzögerung
  • 3+ Fehlversuche = 45 Sek. Verzögerung

Dieses endgültige Schema wurde den OWASP-Best Practices-Vorschlägen (Link 1 aus der MUST-READ-Liste) entnommen und sollte als best practice angesehen werden, auch wenn es sich auf der restriktiven Seite befindet.

Als Faustregel kann ich jedoch sagen: Je stärker Ihre Passwortrichtlinie ist, desto weniger Fehler müssen Sie mit Benutzern verspüren. Wenn Sie 9-stellige Kennwörter mit strengen Kennzeichen (Groß- und Kleinschreibung, Groß- und Kleinschreibung und erforderliche Zahlen und Symbole) benötigen, können Sie den Benutzern 2-4 nicht verzögerte Kennwortversuche erteilen, bevor Sie die Drosselung aktivieren.

Ein Angriff auf dieses letzte Login-Throttling-Schema wäre sehr unpraktisch. Lassen Sie zum Schluss 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 äußerst unpraktischen Angriff.

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

TEIL VII: Verteilte Brute-Force-Angriffe

Abgesehen davon werden fortgeschrittene Angreifer versuchen, die Zugangsbeschränkung durch "Verbreitung ihrer Aktivitäten" zu umgehen:

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

  • Anstatt einen Benutzer auszuwählen und die 50.000 gebräuchlichsten Kennwörter auszuprobieren (was aufgrund unserer Drosselung nicht möglich ist), werden sie das am häufigsten verwendete Kennwort auswählen und es stattdessen mit 50.000 Benutzern versuchen. Auf diese Weise werden nicht nur Maximalversuche wie CAPTCHAs und Login-Throttling umgangen, sondern auch ihre Erfolgschancen erhöht, da das häufigste Kennwort Nummer 1 weitaus wahrscheinlicher ist als die Nummer 49.995

  • Abstand der Anmeldeanforderungen für jedes Benutzerkonto, beispielsweise 30 Sekunden, um unter das Radar zu schleichen

In diesem Fall empfiehlt es sich, die Anzahl der fehlgeschlagenen Anmeldungen systemweit zu protokollieren und einen laufenden Durchschnitt der Häufigkeit der fehlerhaften Anmeldung Ihrer Site als Grundlage für eine Obergrenze zu verwenden, die Sie dann allen Benutzern auferlegen.

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 Anzahl 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 für ALLE Benutzer eine kurze Verzögerung (weiterhin mit Ausnahme von Cookie-Logins und / oder Backup-CAPTCHA-Logins).

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

TEIL VIII: Zwei-Faktor-Authentifizierungsanbieter

Anmeldeinformationen können gefährdet werden, sei es durch Exploits, das Aufschreiben und Verpassen von Kennwörtern, Laptops mit gestohlenen Schlüsseln oder das Eingeben von Anmeldungen in Phishing-Sites durch Benutzer. Anmeldungen können mit der Zwei-Faktor-Authentifizierung weiter geschützt werden, bei der Out-of-Band-Faktoren verwendet werden, z. B. Einmalcodes, 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-Service delegiert werden, bei dem ein anderer Anbieter das Sammeln von Anmeldeinformationen übernimmt. Dadurch wird das Problem an einen vertrauenswürdigen Dritten weitergegeben. Google und Twitter bieten standardbasierte SSO-Dienste, während Facebook eine ähnliche proprietäre Lösung bietet.

LINKS MÜSSEN LESEN Informationen zur Webauthentifizierung

  1. OWASP-Handbuch zur Authentifizierung / OWASP-Authentifizierung
  2. Dos and Don'ts der Client-Authentifizierung im Internet (sehr gut lesbares MIT-Forschungspapier)
  3. Wikipedia: HTTP-Cookie
  4. Persönliche Wissensfragen zur Fallback-Authentifizierung: Sicherheitsfragen in der Ära von Facebook (sehr lesbarer Berkeley-Forschungsbericht)


Ich dachte nur, ich würde diese Lösung teilen, die ich gut funktionierte.

Ich nenne es das Dummy-Feld (obwohl ich das noch nicht erfunden habe, gib mir also keine Schulden).

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

<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 Feld einfügen. 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 wie "Firma", "Telefon" oder "Emailadresse". 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 normalerweise logisch finden, um sie in ein Webformular auszufüllen. Jetzt verstecken das inputFeld mit Hilfe von CSS oder JavaScript / jQuery - was auch immer Sie am besten passt - einfach nicht stellen Sie den Eingang typezu hiddenoder aber der Bot wird nicht darauf hereinfallen.

Wenn Sie das Formular überprüfen (entweder auf Client- oder auf Server-Seite), überprüfen Sie, ob Ihr Dummy-Feld ausgefü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 (in meinem Fall "E-Mail") nicht und versucht nicht, es auszufüllen. Der Wert des Dummy-Felds sollte also noch leer sein, wenn das Formular gesendet wurde.

Im Falle eines Bot: Der Bot sieht ein Feld, dessen Typ textund Name email(oder wie auch immer Sie es heißen), 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 es ständig. Was auch immer der Wert im Dummy-Feld ist, wir kümmern uns nicht darum, solange er größer als die 0Zeichen ist.

Ich habe diese Methode in einem Gästebuch in Kombination mit CAPTCHAs , und seitdem habe ich keinen einzigen Spam-Beitrag mehr gesehen. Ich hatte vorher eine reine CAPTCHA-Lösung verwendet, aber schließlich wurden etwa fünf Spam-Posts pro Stunde erstellt. Durch das Hinzufügen des Dummy-Felds im Formular wurde (zumindest bis jetzt) ​​der gesamte Spam nicht mehr angezeigt.

Ich glaube, dass dies auch mit einem Anmelde- / Authentifizierungsformular verwendet werden kann.

Achtung : Natürlich ist diese Methode nicht zu 100% narrensicher. Bots können so programmiert werden, dass sie Eingabefelder mit dem darauf display:noneangewendeten Stil ignorieren . Sie müssen auch über Personen nachdenken, die eine Form der automatischen Vervollständigung verwenden (wie die meisten Browser über integrierte Funktionen verfügen!), Um alle Formularfelder für sie automatisch auszufüllen. Sie könnten genauso gut ein Dummy-Feld aufnehmen.

Sie können dies auch etwas variieren, indem Sie das Dummy-Feld außerhalb der Bildschirmgrenzen sichtbar lassen. Dies liegt jedoch ganz bei Ihnen.

Seien Sie kreativ!


Ich möchte einen sehr wichtigen Kommentar hinzufügen:

  • "In einer Unternehmensinternet- Umgebung" trifft das meiste, wenn nicht alles, möglicherweise nicht zu!

Viele Unternehmen stellen "nur für den internen Gebrauch" Websites bereit, bei denen es sich effektiv um "Unternehmensanwendungen" handelt, die zufällig über URLs implementiert wurden. Diese URLs können (angeblich ...) nur innerhalb des internen Netzwerks des Unternehmens aufgelöst werden. (Welches Netzwerk umfasst auf magische Weise alle über VPN verbundenen "Straßenkämpfer".)

Wenn ein Benutzer pflichtgemäß mit dem zuvor genannten Netzwerk verbunden ist, ist seine Identität ("Authentifizierung") "abschließend" bekannt, ebenso wie ihre Erlaubnis ("Autorisierung") , bestimmte Dinge zu tun ... .. "um auf diese Website zuzugreifen."

Dieser Dienst "Authentifizierung + Autorisierung" kann durch verschiedene Technologien bereitgestellt werden, z. B. LDAP (Microsoft OpenDirectory) oder Kerberos.

Aus Ihrer Sicht wissen Sie einfach Folgendes: Jeder, der sich legitimerweise auf Ihrer Website aufhält , muss von einer Umgebungsvariablen begleitet werden, die auf magische Weise einen "Token" enthält. ( dh das Fehlen eines solchen Zeichens muss ein unmittelbarer Grund sein 404 Not Found.)

Der Wert des Tokens macht für Sie keinen Sinn, aber, falls dies erforderlich sein sollte, gibt es "geeignete Mittel", mit denen Ihre Website "autoritativ jemanden, der (LDAP ... usw.) kennt", über alle !) Frage, die Sie haben könnten. Mit anderen Worten, Sie nicht in Anspruch nehmen , sie von jeder „home-grown - Logik.“ Stattdessen erkundigen Sie sich bei The Authority und vertrauen implizit auf dessen Urteil.

Ähm ... es ist ein ziemlich mentaler Wechsel vom "wild-wolligen Internet".


Ich möchte einen Vorschlag hinzufügen, den ich verwendet habe, basierend auf einer umfassenden Verteidigung. Für Admins brauchen Sie nicht das gleiche auth & auth-System 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 regelmäßige 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). Der einzige Nachteil Ihres Administrators ist jedoch der Link in seiner E-Mail. Der Angreifer weiß nicht mehr, wohin er überhaupt gehen soll.


Meine Lieblingsregel in Bezug auf Authentifizierungssysteme: Verwenden Sie Passphrasen, keine Passwörter. Leicht zu merken, schwer zu knacken. Weitere Informationen: Coding Horror: Passwörter vs. Passphrasen






article