Was ist die beste verteilte Brute-Force-Gegenmaßnahme?

Zunächst ein kleiner Hintergrund: Es ist kein Geheimnis, dass ich ein auth + auth-System für CodeIgniter implementiere, und bis jetzt gewinne ich (sozusagen). Aber ich bin auf eine ziemlich nicht triviale Herausforderung gestoßen (eine, die die meisten Auth-Bibliotheken völlig vermissen, aber ich bestehe darauf, sie richtig zu handhaben): Wie man intelligent mit großen, verteilten Brute-Force-Angriffen mit variablem Benutzernamen umgeht .

Ich kenne alle üblichen Tricks:

1. Begrenzung der Anzahl fehlgeschlagener Versuche pro IP / Host und Verweigerung des Zugriffs des Täters (z. B. Fail2Ban) - was nicht mehr funktioniert, da Botnets intelligenter geworden sind
2. Kombinieren Sie das oben Genannte mit einer schwarzen Liste bekannter "schlechter" IPs / Hosts (z. B. DenyHosts) - was darauf beruht, dass Botnets auf Platz 1 fallen, was sie zunehmend nicht tun
3. IP / Host-Whitelists kombiniert mit herkömmlicher Authentifizierung (leider nutzlos bei dynamischen IP-Benutzern und der hohen Abwanderung auf den meisten Websites)
4. Festlegen eines landesweiten Limits für die Anzahl fehlgeschlagener Versuche innerhalb eines Zeitraums von N Minuten / Stunde und Drosseln (Anhalten) aller Anmeldeversuche danach für einige Minuten / Stunden (mit dem Problem, dass DoS, das Sie angreift, zum Kinderspiel des Botnetzes wird)
5. Obligatorische digitale Signaturen (Public-Key-Zertifikate) oder RSA-Hardware-Token für alle Benutzer ohne Anmelde- / Kennwortoption (ohne Frage eine solide Lösung, aber nur praktisch für geschlossene, dedizierte Dienste)
6. Erzwungene ultrastarke Passwortschemata (z. B.> 25 Unsinnzeichen mit Symbolen - wiederum zu unpraktisch für Gelegenheitsbenutzer)
7. Und schließlich CAPTCHAs (die in den meisten Fällen funktionieren könnten, aber für Benutzer ärgerlich und gegen einen entschlossenen, einfallsreichen Angreifer praktisch nutzlos sind )

Dies sind nur die theoretisch umsetzbaren Ideen. Es gibt viele Müllideen, die die Site weit öffnen (z. B. für triviale DoS-Angriffe). Was ich will, ist etwas Besseres. Und besser gesagt, ich meine:

• Es muss sicher (+) gegen DoS- und Brute-Force-Angriffe sein und darf keine neuen Sicherheitslücken einführen, die es einem etwas hinterhältigeren Bot ermöglichen könnten, unter dem Radar weiter zu arbeiten

• Es muss automatisiert werden. Wenn ein menschlicher Bediener jedes Login überprüfen oder verdächtige Aktivitäten überwachen muss, funktioniert dies in einem realen Szenario nicht

• Es muss für die Mainstream-Webnutzung machbar sein (dh hohe Abwanderung, hohes Volumen und offene Registrierung, die von Nicht-Programmierern durchgeführt werden kann).

• Es kann die Benutzererfahrung nicht so stark beeinträchtigen, dass Gelegenheitsbenutzer verärgert oder frustriert werden (und möglicherweise die Website verlassen).

• Es können keine Kätzchen beteiligt sein, es sei denn, sie sind wirklich sehr, sehr sichere Kätzchen

(+) Mit "sicher" meine ich mindestens so sicher wie die Fähigkeit eines paranoiden Benutzers, sein Passwort geheim zu halten

Also - lass es uns hören! Wie würdest du das machen ? Kennen Sie eine Best Practice, die ich nicht erwähnt habe (oh, bitte sagen Sie, dass Sie dies tun)? Ich gebe zu, dass ich eine eigene Idee habe (Ideen aus 3 und 4 kombinieren), aber ich werde die wahren Experten sprechen lassen, bevor ich mich in Verlegenheit bringe ;-)

In Ordnung, genug Abwürgen; Folgendes habe ich mir bisher ausgedacht

(Entschuldigung, langer Beitrag voraus. Sei mutig, Freund, die Reise wird sich lohnen.)

Kombinieren Sie die Methoden 3 und 4 aus dem ursprünglichen Beitrag zu einer Art "Fuzzy" - oder dynamischer Whitelist und blockieren Sie dann - und hier ist der Trick - nicht IPs ohne Whitelist, sondern drosseln Sie sie nur in die Hölle und zurück .

Beachten Sie, dass diese Maßnahme nur dazu gedacht ist, diese sehr spezifische Art von Angriff zu vereiteln. In der Praxis würde dies natürlich in Kombination mit anderen Best-Practice-Ansätzen zur Authentifizierung funktionieren: Drosselung fester Benutzernamen, Drosselung pro IP, Code-erzwungene Richtlinie für strenge Kennwörter, nicht gedrosselte Cookie-Anmeldung, Hashing aller Kennwortäquivalente vor dem Speichern, niemals mit Sicherheitsfragen usw.

Annahmen zum Angriffsszenario

Wenn ein Angreifer auf variable Benutzernamen abzielt, wird die Drosselung unserer Benutzernamen nicht ausgelöst. Wenn der Angreifer ein Botnetz verwendet oder Zugriff auf einen großen IP-Bereich hat, ist unsere IP-Drosselung machtlos. Wenn der Angreifer unsere Benutzerliste vorab überprüft hat (normalerweise bei Webdiensten mit offener Registrierung möglich), können wir keinen laufenden Angriff anhand der Anzahl der Fehler "Benutzer nicht gefunden" erkennen. Und wenn wir eine restriktive systemweite Drosselung (alle Benutzernamen, alle IPs) erzwingen, wird jeder solche Angriff unsere gesamte Site für die Dauer des Angriffs plus der Drosselungsperiode betreffen.

Also müssen wir etwas anderes tun.

Der erste Teil der Gegenmaßnahme: Whitelisting

Wir können ziemlich sicher sein, dass der Angreifer die IP-Adressen mehrerer tausend unserer Benutzer (+) nicht erkennen und dynamisch fälschen kann. Das macht Whitelisting möglich. Mit anderen Worten: Für jeden Benutzer speichern wir eine Liste der (gehashten) IPs, von denen aus sich der Benutzer zuvor (kürzlich) angemeldet hat.

Daher fungiert unser Whitelist-Schema als verschlossene "Haustür", an der ein Benutzer von einer seiner anerkannten "guten" IPs aus verbunden sein muss, um sich überhaupt anzumelden. Ein Brute-Force-Angriff auf diese 'Haustür' wäre praktisch unmöglich (+).

(+) Wenn der Angreifer nicht entweder den Server, alle Boxen unserer Benutzer oder die Verbindung selbst "besitzt" - und in diesen Fällen haben wir kein "Authentifizierungs" -Problem mehr, haben wir ein echtes Franchise-Unternehmen -Stecker FUBAR Situation

Der zweite Teil der Gegenmaßnahme: Systemweite Drosselung nicht erkannter IPs

Damit eine Whitelist für einen Webdienst mit offener Registrierung funktioniert, bei dem Benutzer häufig den Computer wechseln und / oder eine Verbindung über dynamische IP-Adressen herstellen, müssen wir eine "Katzentür" offen halten, damit Benutzer eine Verbindung von nicht erkannten IP-Adressen herstellen können. Der Trick besteht darin, diese Tür so zu gestalten, dass Botnets hängen bleiben und legitime Benutzer so wenig wie möglich gestört werden .

In meinem Schema wird dies erreicht, indem eine sehr restriktive maximale Anzahl fehlgeschlagener Anmeldeversuche durch nicht genehmigte IPs über einen Zeitraum von beispielsweise 3 Stunden festgelegt wird (je nach Art des Dienstes kann es sinnvoller sein, einen kürzeren oder längeren Zeitraum zu verwenden) diese Einschränkung global machen , dh. für alle Benutzerkonten.

Selbst eine langsame (1-2 Minuten zwischen den Versuchen) Brute Force würde mit dieser Methode schnell und effektiv erkannt und vereitelt. Natürlich könnte eine wirklich langsame Brute Force immer noch unbemerkt bleiben, aber zu langsame Geschwindigkeiten machen den eigentlichen Zweck des Brute Force-Angriffs zunichte.

Was ich mit diesem Drosselmechanismus erreichen möchte, ist, dass bei Erreichen der Höchstgrenze unsere "Katzentür" für eine Weile zugeschlagen wird, unsere Vordertür jedoch für legitime Benutzer offen bleibt, die auf übliche Weise eine Verbindung herstellen:

• Entweder durch Herstellen einer Verbindung von einer ihrer erkannten IPs
• Oder indem Sie ein dauerhaftes Login-Cookie verwenden (von überall)

Die einzigen legitimen Benutzer, die während eines Angriffs betroffen wären - dh. während die Drosselung aktiviert war - wären Benutzer ohne dauerhafte Anmelde-Cookies, die sich von einem unbekannten Ort oder mit einer dynamischen IP anmelden. Diese Benutzer können sich erst anmelden, wenn die Drosselung nachgelassen hat (was möglicherweise eine Weile dauern kann, wenn der Angreifer sein Botnetz trotz Drosselung am Laufen hält).

Um dieser kleinen Gruppe von Benutzern zu ermöglichen, sich durch die ansonsten versiegelte Katzentür zu quetschen, selbst wenn noch Bots darauf hämmerten, würde ich ein 'Backup'-Anmeldeformular mit einem CAPTCHA verwenden. Wenn Sie also die Meldung "Entschuldigung, aber Sie können sich derzeit nicht von dieser IP-Adresse aus anmelden" anzeigen, fügen Sie einen Link mit der Aufschrift " Sichere Backup-Anmeldung - NUR MENSCHEN ( Bots: kein Lügen ) " hinzu. Scherz beiseite, wenn sie auf diesen Link klicken, geben Sie ihnen ein reCAPTCHA-authentifiziertes Anmeldeformular, das die Site-weite Drosselung umgeht. Auf diese Weise wird ihnen , wenn sie menschlich sind UND das richtige Login + Passwort kennen (und CAPTCHAs lesen können), niemals der Dienst verweigert, selbst wenn sie eine Verbindung von einem unbekannten Host herstellen und das Autologin-Cookie nicht verwenden.

Oh, und nur zur Klarstellung: Da ich CAPTCHAs im Allgemeinen als böse betrachte, wird die Anmeldeoption "Backup" nur angezeigt, wenn die Drosselung aktiv war .

Es ist nicht zu leugnen, dass ein solcher anhaltender Angriff immer noch eine Form von DoS-Angriff darstellt, aber mit dem beschriebenen System würde es nur das beeinflussen, was ich für eine winzige Untergruppe von Benutzern halte, nämlich Leute, die das nicht verwenden Cookie "Erinnere dich an mich" UND melde dich zufällig an, während ein Angriff stattfindet UND melde dich nicht von einer ihrer üblichen IP-Adressen an UND wer CAPTCHAs nicht lesen kann. Nur diejenigen, die zu ALLEN dieser Kriterien Nein sagen können - insbesondere Bots und wirklich unglückliche behinderte Menschen - werden während eines Bot-Angriffs abgewiesen.

BEARBEITEN : Eigentlich habe ich mir eine Möglichkeit überlegt, selbst von CAPTCHA herausgeforderte Benutzer während einer Sperrung durchzulassen: Anstelle oder als Ergänzung zum Backup-CAPTCHA-Login kann der Benutzer eine Option für die einmalige Verwendung erhalten , benutzerspezifischer Sperrcode, der an seine E-Mail gesendet wird und mit dem er dann die Drosselung umgehen kann. Dies überschreitet definitiv meine "Ärger" -Schwelle, aber da es nur als letzter Ausweg für eine winzige Untergruppe von Benutzern verwendet wird und es immer noch besser ist, von Ihrem Konto ausgeschlossen zu werden, wäre es akzeptabel.

(Beachten Sie auch, dass nichts davon passiert, wenn der Angriff weniger ausgefeilt ist als die böse verteilte Version, die ich hier beschrieben habe. Wenn der Angriff nur von wenigen IPs ausgeht oder nur wenige Benutzernamen trifft, wird er viel früher vereitelt und ohne standortweite Konsequenzen)

Das ist also die Gegenmaßnahme, die ich in meiner Authentifizierungsbibliothek implementieren werde, sobald ich überzeugt bin, dass es solide ist und dass es keine viel einfachere Lösung gibt, die ich verpasst habe. Tatsache ist, dass es so viele subtile Möglichkeiten gibt, Dinge in Bezug auf Sicherheit falsch zu machen, und ich bin nicht überfordert, falsche Annahmen oder hoffnungslos fehlerhafte Logik zu treffen. Daher sind alle Rückmeldungen, Kritik und Verbesserungen, Feinheiten usw. sehr willkommen.

Ein paar einfache Schritte:

Setzen Sie bestimmte gebräuchliche Benutzernamen auf die schwarze Liste und verwenden Sie sie als Honeypot. Administrator, Gast usw. Lassen Sie niemanden Konten mit diesen Namen erstellen. Wenn also jemand versucht, sie anzumelden, wissen Sie, dass jemand etwas tut, das er nicht tun sollte.

Stellen Sie sicher, dass jeder, der echte Macht auf der Site hat, ein sicheres Passwort hat. Admins / Moderatoren müssen längere Passwörter mit einer Mischung aus Buchstaben, Zahlen und Symbolen haben. Lehnen Sie trivial einfache Passwörter von normalen Benutzern mit einer Erklärung ab.

Eines der einfachsten Dinge, die Sie tun können, ist, den Leuten mitzuteilen, wann jemand versucht hat, sich in ihr Konto einzuloggen, und ihnen einen Link zu geben, um den Vorfall zu melden, wenn sie es nicht waren. Eine einfache Nachricht, wenn sie sich anmelden wie "Jemand hat versucht, sich um 4:20 Uhr in Ihrem Konto anzumelden. Mittwoch bla bla. Klicken Sie hier, wenn Sie es nicht waren." Hier können Sie einige Statistiken zu Angriffen aufbewahren. Sie können die Überwachungs- und Sicherheitsmaßnahmen verstärken, wenn Sie feststellen, dass die Anzahl betrügerischer Zugriffe plötzlich zunimmt.

Wenn ich das MO von Brute-Force-Angriffen richtig verstehe, werden ein oder mehrere Benutzernamen kontinuierlich ausprobiert.

Es gibt zwei Vorschläge, die ich hier noch nicht gesehen habe:

• Ich habe immer gedacht, dass die Standardpraxis darin besteht, nach jedem falschen Login für jeden Benutzer eine kurze Verzögerung (etwa eine Sekunde) zu haben. Dies verhindert Brute-Force, aber ich weiß nicht, wie lange eine Verzögerung von einer Sekunde einen Wörterbuchangriff in Schach halten würde. (Wörterbuch mit 10.000 Wörtern == 10.000 Sekunden == ungefähr 3 Stunden. Hmm. Nicht gut genug.)
• Anstelle einer Verlangsamung der gesamten Website können Sie auch eine Drosselklappe für Benutzernamen verwenden. Das Gas wird mit jedem falschen Versuch immer härter (bis zu einem gewissen Grad, denke ich, damit sich der echte Benutzer immer noch anmelden kann).

Bearbeiten : Als Antwort auf Kommentare zu einem Benutzernamen-Gas: Dies ist ein Benutzername-spezifisches Gas ohne Rücksicht auf die Quelle des Angriffs.

Wenn der Benutzername gedrosselt wird, wird sogar ein koordinierter Angriff auf den Benutzernamen (Multi-IP, einmalige Vermutung pro IP, gleicher Benutzername) abgefangen. Einzelne Benutzernamen sind durch das Gas geschützt, auch wenn die Angreifer während des Timeouts einen anderen Benutzer / Pass ausprobieren können.

Aus der Sicht eines Angreifers können Sie während des Timeouts möglicherweise zum ersten Mal 100 Kennwörter erraten und schnell ein falsches Kennwort pro Konto ermitteln. Möglicherweise können Sie für denselben Zeitraum nur 50 Sekunden lang raten.

Aus Sicht eines Benutzerkontos ist immer noch die gleiche durchschnittliche Anzahl von Vermutungen erforderlich, um das Kennwort zu brechen, selbst wenn die Vermutungen aus mehreren Quellen stammen.

Für die Angreifer ist es bestenfalls die gleiche Anstrengung, 100 Konten zu brechen wie für 1 Konto. Da Sie jedoch nicht auf einer Site-weiten Basis drosseln, können Sie die Drossel ziemlich schnell erhöhen.

Zusätzliche Verfeinerungen:

• IPs erkennen, die mehrere Konten erraten - 408 Request Timeout
• Erkennen von IPs, die dasselbe Konto erraten - 408 Anforderungszeitlimit nach einer großen Anzahl (z. B. 100) von Vermutungen.

UI-Ideen (in diesem Zusammenhang möglicherweise nicht geeignet), die möglicherweise auch Folgendes verfeinern:

• Wenn Sie die Kontrolle über die Passworteinstellung haben und den Benutzer anzeigen, wie stark sein Passwort ist , werden Sie aufgefordert, ein besseres auszuwählen.
• Wenn Sie die Kontrolle über das Login sind Seite , nach einem kleinen (etwa 10) Anzahl der Vermutungen eines einzigen Benutzernamen, bieten eine CAPTCHA.

Es gibt drei Faktoren für die Authentifizierung:

1. Ein Benutzer weiß etwas (dh ein Passwort)
2. Ein Benutzer hat etwas (dh einen Schlüsselanhänger)
3. Ein Benutzer ist etwas (dh Retina-Scan)

Normalerweise setzen Websites nur die Richtlinie 1 durch. Selbst die meisten Banken setzen nur Richtlinie 1 durch. Stattdessen verlassen sie sich bei der Zwei-Faktor-Authentifizierung auf einen "Weiß etwas anderes" -Ansatz. (IE: Ein Benutzer kennt sein Passwort und den Mädchennamen seiner Mutter.) Wenn Sie in der Lage sind, ist es nicht allzu schwierig, einen zweiten Authentifizierungsfaktor hinzuzufügen.

Wenn Sie ungefähr 256 Zufallszeichen generieren können, können Sie diese in einer 16 × 16-Tabelle strukturieren und dann den Benutzer bitten, Ihnen beispielsweise den Wert in der Tabelle von Zelle A-14 anzugeben. Wenn sich ein Benutzer anmeldet oder sein Passwort ändert, geben Sie ihm die Tabelle und fordern Sie ihn auf, sie auszudrucken und zu speichern.

Die Schwierigkeit bei diesem Ansatz besteht darin, dass Sie, wenn ein Benutzer sein Passwort wie gewünscht vergisst, nicht einfach den Standard "Beantworten Sie diese Frage und geben Sie ein neues Passwort ein" anbieten können, da dies auch für Brute-Force anfällig ist. Sie können es auch nicht zurücksetzen und ihnen eine neue E-Mail senden, da auch ihre E-Mail-Adresse gefährdet sein könnte. (Siehe: Makeuseof.com und ihre gestohlene Domain.)

Eine andere Idee (die Kätzchen betrifft) ist das, was BOA SiteKey nennt (ich glaube, sie haben den Namen als Marke eingetragen). Kurz gesagt, Sie lassen den Benutzer ein Bild hochladen, wenn er sich registriert, und wenn er versucht, sich anzumelden, bitten Sie ihn, sein Bild aus 8 oder 15 (oder mehr) zufälligen Bildern auszuwählen. Wenn ein Benutzer ein Bild seines Kätzchens hochlädt, weiß theoretisch nur er genau, welches Bild ihm von allen anderen Kätzchen (oder Blumen oder was auch immer) gehört. Die einzige wirkliche Gefahr, die dieser Ansatz hat, ist der Man-in-the-Middle-Angriff.

Eine weitere Idee (allerdings keine Kätzchen) besteht darin, IPs zu verfolgen, mit denen Benutzer auf das System zugreifen, und sie zu verpflichten, eine zusätzliche Authentifizierung durchzuführen (Captcha, Kitty auswählen, Schlüssel aus dieser Tabelle auswählen), wenn sie sich von einer Adresse aus anmelden, die sie haben nicht vorher. Ermöglichen Sie dem Benutzer ähnlich wie bei GMail auch, anzuzeigen, wo er sich kürzlich angemeldet hat.

Bearbeiten, neue Idee:

Eine andere Möglichkeit, Anmeldeversuche zu überprüfen, besteht darin, zu überprüfen, ob der Benutzer von Ihrer Anmeldeseite stammt oder nicht. Sie können Überweiser nicht überprüfen, da sie leicht gefälscht werden können. Sie müssen einen Schlüssel in der Variablen _SESSION festlegen, wenn der Benutzer die Anmeldeseite anzeigt, und dann überprüfen, ob der Schlüssel vorhanden ist, wenn er seine Anmeldeinformationen übermittelt. Wenn der Bot nicht von der Anmeldeseite sendet, kann er sich nicht anmelden. Sie können dies auch vereinfachen, indem Sie Javascript in den Prozess einbeziehen, indem Sie es entweder zum Setzen eines Cookies verwenden oder dem Formular nach dem Laden einige Informationen hinzufügen. Oder Sie können das Formular in zwei verschiedene Übermittlungen aufteilen (dh der Benutzer gibt seinen Benutzernamen ein, übermittelt, gibt dann auf einer neuen Seite sein Passwort ein und sendet es erneut.)

Der Schlüssel ist in diesem Fall der wichtigste Aspekt. Eine übliche Methode, um sie zu generieren, ist eine Kombination aus den Daten des Benutzers, seiner IP und der Zeit, zu der sie übermittelt wurden.

Ich hatte vorher eine sehr ähnliche Frage über bei beantwortet Wie kann ich Benutzer - Login - Versuche in PHP drosseln . Ich werde die vorgeschlagene Lösung hier wiederholen, da ich glaube, dass viele von Ihnen es informativ und nützlich finden werden, einen tatsächlichen Code zu sehen. Bitte beachten Sie, dass die Verwendung eines CAPTCHA aufgrund der immer genaueren Algorithmen, die heutzutage in CAPTCHA-Bustern verwendet werden, möglicherweise nicht die beste Lösung ist:

Sie können DoS-Angriffe nicht einfach verhindern, indem Sie die Drosselung auf eine einzelne IP oder einen Benutzernamen verketten. Zum Teufel, mit dieser Methode können Sie schnelle Anmeldeversuche nicht wirklich verhindern.

Warum? Weil der Angriff mehrere IPs und Benutzerkonten umfassen kann, um Ihre Drosselungsversuche zu umgehen.

Ich habe an anderer Stelle gesehen, dass Sie im Idealfall alle fehlgeschlagenen Anmeldeversuche auf der Website verfolgen und sie möglicherweise einem Zeitstempel zuordnen sollten:

CREATE TABLE failed_logins(
    id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(16) NOT NULL,
    ip_address INT(11) UNSIGNED NOT NULL,
    attempted DATETIME NOT NULL
) engine=InnoDB charset=UTF8;

Entscheiden Sie sich für bestimmte Verzögerungen basierend auf der Gesamtzahl der fehlgeschlagenen Anmeldungen in einer bestimmten Höhe der Zeit. Sie sollten dies auf statistischen Daten basieren, die aus Ihrer failed_loginsTabelle abgerufen werden, da sie sich im Laufe der Zeit ändern, basierend auf der Anzahl der Benutzer und der Anzahl der Benutzer, die ihr Kennwort abrufen (und eingeben) können.

10 failed attempts = 1 second
20 failed attempts = 2 seconds
30 failed attempts = reCaptcha

Fragen Sie die Tabelle bei jedem fehlgeschlagenen Anmeldeversuch ab, um die Anzahl der fehlgeschlagenen Anmeldungen für einen bestimmten Zeitraum zu ermitteln, z. B. 15 Minuten:

SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute);

Wenn die Anzahl der Versuche über den angegebenen Zeitraum Ihr Limit überschreitet, erzwingen Sie entweder die Drosselung oder zwingen Sie alle Benutzer, ein Captcha (dh reCaptcha) zu verwenden, bis die Anzahl der fehlgeschlagenen Versuche über den angegebenen Zeitraum unter dem Schwellenwert liegt.

// array of throttling
$throttle = array(10 => 1, 20 => 2, 30 => 'recaptcha');

// assume query result of $sql is stored in $row
$sql = 'SELECT MAX(attempted) AS attempted FROM failed_logins';
$latest_attempt = (int) date('U', strtotime($row['attempted']));
// get the number of failed attempts
$sql = 'SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute)';
// assume the number of failed attempts was stored in $failed_attempts
krsort($throttle);
foreach ($throttle as $attempts => $delay) {
    if ($failed_attempts > $attempts) {
        // we need to throttle based on delay
        if (is_numeric($delay)) {
            $remaining_delay = time() - $latest_attempt - $delay;
            // output remaining delay
            echo 'You must wait ' . $remaining_delay . ' seconds before your next login attempt';
        } else {
            // code to display recaptcha on login form goes here
        }
        break;
    }
}

Die Verwendung von reCaptcha bei einem bestimmten Schwellenwert würde sicherstellen, dass ein Angriff von mehreren Seiten minimiert wird und normale Site-Benutzer keine signifikante Verzögerung für legitime fehlgeschlagene Anmeldeversuche erfahren. Ich kann keine Prävention garantieren, da bereits erweitert wurde, dass CAPTCHAs kaputt gehen können. Es gibt alternative Lösungen, vielleicht eine Variante von "Name this animal", die als Ersatz recht gut funktionieren könnte.

Ich muss fragen, ob Sie eine Kosten-Nutzen-Analyse dieses Problems durchgeführt haben. Es hört sich so an, als würden Sie versuchen, sich vor einem Angreifer zu schützen, der über genügend Webpräsenz verfügt, um eine Reihe von Passwörtern zu erraten, und möglicherweise 3-5 Anforderungen pro IP senden (da Sie die IP-Drosselung abgelehnt haben). Wie viel (ungefähr) würde diese Art von Angriff kosten? Ist es teurer als der Wert der Konten, die Sie schützen möchten? Wie viele gigantische Botnetze wollen, was Sie haben?

Die Antwort könnte nein sein - aber wenn ja, hoffe ich, dass Sie Hilfe von einem Sicherheitsexperten erhalten. Programmierkenntnisse (und StackOverflow-Punktzahl) korrelieren nicht stark mit dem Sicherheits-Know-how.

Um Jens 'Schema in einem Pseudo-Zustandsübergangsdiagramm / einer Regelbasis zusammenzufassen:

1. Benutzer + Passwort -> Eintrag
2. Benutzer +! Passwort -> verweigert
3. Benutzer + bekanntes_IP (Benutzer) -> Haustür, // never throttle
4. user + unknown_IP (user) -> catflap
5. (#denied> n) über Catflaps (Site) -> Catflaps (Site) drosseln // slow the bots
6. Catflap + Gas + Passwort + Captcha -> Eintrag // humans still welcome
7. Catflap + Gas + Passwort +! Captcha -> verweigert // a correct guess from a bot

Beobachtungen:

• Drosseln Sie niemals die Vordertür. Die elbonische Staatspolizei hat Ihren Computer in Ihrem Haus, kann Sie jedoch nicht verhören. Brute Force ist ein praktikabler Ansatz von Ihrem Computer aus.
• Wenn Sie ein "Passwort vergessen?" Link, dann wird Ihr E-Mail-Konto Teil der Angriffsfläche.

Diese Beobachtungen decken eine andere Art von Angriff ab als die, denen Sie entgegenwirken möchten.

Sieht so aus, als würden Sie versuchen, sich gegen langsam verteilte rohe Gewalt zu verteidigen . Nicht so viel kann man dagegen tun. Wir verwenden eine PKI und keine Passwort-Logins. Es hilft, aber wenn Ihre Kunden gelegentlich zufällige Workstations haben, ist dies nicht sehr zutreffend.

Haftungsausschluss: Ich arbeite für ein Zwei-Faktor-Unternehmen, bin aber nicht hier, um es anzuschließen. Hier sind einige Beobachtungen.

Cookies können mit XSS- und Browser-Vulns gestohlen werden. Benutzer wechseln häufig den Browser oder löschen ihre Cookies.

Quell-IP-Adressen sind gleichzeitig dynamisch variabel und fälschbar.

Captcha ist nützlich, authentifiziert jedoch keinen bestimmten Menschen.

Mehrere Methoden können erfolgreich kombiniert werden, aber ein guter Geschmack ist sicherlich angebracht.

Die Komplexität der Passwörter ist gut. Alles, was auf Passwörtern basiert, hängt entscheidend von Passwörtern mit ausreichender Entropie ab. Meiner Meinung nach ist ein sicheres Passwort, das an einem sicheren physischen Ort notiert ist, besser als ein schwaches Passwort im Speicher. Menschen wissen, wie sie die Sicherheit von Papierdokumenten viel besser bewerten können, als wie sie die effektive Entropie im Namen ihres Hundes ermitteln können, wenn sie als Passwort für drei verschiedene Websites verwendet werden. Erwägen Sie, Benutzern die Möglichkeit zu geben, eine große oder kleine Seite mit einmaligen Passcodes auszudrucken.

Sicherheitsfragen wie "Was war dein Highschool-Maskottchen?" Sind meistens eine andere miese Form von "etwas, das du weißt". Die meisten von ihnen sind leicht zu erraten oder direkt öffentlich zugänglich.

Wie Sie bereits bemerkt haben, ist das Drosseln fehlgeschlagener Anmeldeversuche ein Kompromiss zwischen der Verhinderung von Brute-Force-Angriffen und der einfachen Durchführung eines Kontos. Aggressive Sperrrichtlinien können ein mangelndes Vertrauen in die Kennwortentropie widerspiegeln.

Ich persönlich sehe den Vorteil der Durchsetzung des Passwortablaufs auf einer Website sowieso nicht. Der Angreifer erhält Ihr Passwort einmal, kann es dann ändern und diese Richtlinie genauso einfach wie möglich einhalten. Möglicherweise besteht ein Vorteil darin, dass der Benutzer dies möglicherweise früher bemerkt, wenn der Angreifer das Kontokennwort ändert. Noch besser wäre es, wenn der Benutzer irgendwie benachrichtigt würde, bevor der Angreifer Zugriff erhält. Nachrichten wie "N fehlgeschlagene Versuche seit der letzten Anmeldung" sind in dieser Hinsicht nützlich.

Die beste Sicherheit ergibt sich aus einem zweiten Authentifizierungsfaktor, der im Vergleich zum ersten außerhalb des Bandes liegt. Wie Sie sagten, sind Hardware-Token in "etwas, das Sie haben" großartig, aber viele (nicht alle) haben einen echten Verwaltungsaufwand, der mit ihrer Verteilung verbunden ist. Ich kenne keine biometrischen "Something You Are" -Lösungen, die für Websites gut sind. Einige Zwei-Faktor-Lösungen funktionieren mit OpenID-Anbietern, andere verfügen über PHP / Perl / Python-SDKs.

Meine höchste Empfehlung ist es, einfach sicherzustellen, dass Sie Benutzer über schlechte Anmeldeversuche in ihren Konten auf dem Laufenden halten. Benutzer werden die Stärke ihres Passworts wahrscheinlich viel ernster nehmen, wenn ihnen Beweise dafür vorgelegt werden, dass tatsächlich jemand versucht, in ihr Konto zu gelangen .

Ich habe tatsächlich jemanden erwischt, der sich in das MySpace-Konto meines Bruders gehackt hat, weil er versucht hat, in das für ihn eingerichtete Google Mail-Konto zu gelangen, und die Funktion "Passwort per E-Mail zurücksetzen" verwendet hat, die in meinen Posteingang ging.

1. Wie wäre es, wenn Sie ein Einmalpasswort benötigen, bevor Sie Ihr normales Passwort eingeben? Das würde es sehr offensichtlich machen, dass jemand angegriffen hat, bevor er viele Möglichkeiten hatte, das Hauptpasswort zu erraten?

2. Behalten Sie eine globale Anzahl / Rate von Anmeldefehlern bei - dies ist der Indikator für einen Angriff - während eines Angriffs sollten Sie Anmeldefehler strenger behandeln, z. B. IPs schneller verbieten.

Ich glaube nicht, dass es eine perfekte Antwort gibt, aber ich würde mich gerne nähern, um zu versuchen, die Roboter zu verwirren, wenn ein Angriff wahrgenommen wird.

Aus dem Kopf:

Wechseln Sie zu einem alternativen Anmeldebildschirm. Es gibt mehrere Leerzeichen für Benutzernamen und Kennwörter, die tatsächlich angezeigt werden, aber nur eines davon befindet sich am richtigen Ort. Die Feldnamen sind RANDOM --a Sitzungsschlüssel zusammen mit dem Anmeldebildschirm gesendet wird, kann der Server dann herausfinden, welche Felder sind was. Erfolgreich oder fehlgeschlagen wird dann verworfen, sodass Sie keinen Wiederholungsangriff versuchen können. Wenn Sie das Kennwort ablehnen, erhalten sie eine neue Sitzungs-ID.

Es wird angenommen, dass jedes Formular, das mit Daten in einem falschen Feld gesendet wird, von einem Roboter stammt - die Anmeldung schlägt fehl, Punkt, und diese IP wird gedrosselt. Stellen Sie sicher, dass die zufälligen Feldnamen niemals mit den legitimen Feldnamen übereinstimmen, damit jemand, der sich Kennwörter merkt, nicht irreführt.

Als nächstes wie wäre es mit einer anderen Art von Captcha: Sie haben eine Reihe von Fragen, die für einen Menschen keine Probleme verursachen. Sie sind jedoch NICHT zufällig. Wenn der Angriff beginnt, erhält jeder die Frage Nr. 1. Nach einer Stunde wird Frage 1 verworfen, um nie wieder verwendet zu werden, und jeder erhält Frage 2 und so weiter.

Der Angreifer kann die Datenbank nicht herunterladen, um sie in seinen Roboter zu laden, da die Fragen verfügbar sind. Er muss innerhalb einer Stunde neue Anweisungen an sein Botnetz senden, um irgendetwas tun zu können.

Da einige Leute CAPTCHA als menschlichen Fallback-Mechanismus aufgenommen haben, füge ich eine frühere StackOverflow-Frage und einen Thread zur Wirksamkeit von CAPTCHA hinzu.

Wurde reCaptcha geknackt / gehackt / OCR / besiegt / gebrochen?

Die Verwendung von CAPTCHA schränkt die Verbesserungen Ihrer Drosselung und anderer Vorschläge nicht ein, aber ich denke, die Anzahl der Antworten, die CAPTCHA als Ersatz enthalten, sollte die menschenbasierten Methoden berücksichtigen, die Personen zur Verfügung stehen, die die Sicherheit verletzen möchten.

Sie können auch basierend auf der Stärke eines Benutzerkennworts drosseln.

Wenn ein Benutzer sein Passwort registriert oder ändert, berechnen Sie eine Stärkebewertung für sein Passwort, beispielsweise zwischen 1 und 10.

So etwas wie "Passwort" erhält eine 1, während "c6eqapRepe7et * Awr @ ch" eine 9 oder 10 erzielt. Je höher die Punktzahl, desto länger dauert es, bis die Drosselung einsetzt.

Die erste Antwort, die ich normalerweise gehört habe, wenn ich diese Frage stelle, ist, die Ports zu wechseln, aber vergessen Sie das und deaktivieren Sie einfach IPv4. Wenn Sie nur Clients aus IPv6-Netzwerken zulassen, beten Sie nicht mehr für einfaches Netzwerk-Scannen, und Angreifer greifen auf DNS-Lookups zurück. Laufen Sie nicht unter derselben Adresse wie Ihr Apache (AAAA) / Sendmail (MX-> AAAA) / was Sie an alle weitergegeben haben (AAAA). Stellen Sie sicher, dass Ihre Zone nicht xferd sein kann. Warten Sie, bis Ihre Zone von irgendjemandem heruntergeladen werden kann.

Wenn die Bots feststellen, dass Ihr Server neue Hostnamen eingerichtet hat, stellen Sie Ihren Hostnamen einfach etwas Kauderwelsch voran und ändern Sie Ihre Adresse. Lassen Sie die alten Namen und richten Sie sogar ** Honeypot-Namen ein, damit das Bot-Netz eine Zeitüberschreitung aufweist.

** Testen Sie Ihre Reverse (PTR) -Datensätze (unter ip6.arpa.), Um festzustellen, ob sie verwendet werden können, um Ein / 4 mit Datensätzen gegen VS / 4s auf Null zu setzen, die dies nicht tun. IE Normalerweise hat ip6.arpa ~ 32 "." S in einer Adresse, aber wenn Sie versuchen, die letzten paar fehlenden zu verwenden, können Sie sich den Netzwerkblöcken entziehen, die Datensätze enthalten, im Vergleich zu anderen, die dies nicht tun. Wenn Sie dies weiter verfolgen, können Sie große Teile des Adressraums überspringen.

Im schlimmsten Fall müssen Benutzer einen IPv6-Tunnel einrichten. Es ist jedoch nicht so, als müssten sie bis zum VPN in eine DMZ gehen ... Obwohl man sich fragt, warum dies nicht die erste Option ist.

Auch Kerberos ist cool, aber IMHO LDAP bläst (Was ist technisch falsch mit NISPlus? Ich habe gelesen, dass Sun entschieden hat, dass Benutzer LDAP wollten und aus diesem Grund NIS + fallen ließen). Kerberos funktioniert ohne LDAP oder NIS einwandfrei. Sie müssen Benutzer nur Host für Host verwalten. Mit Kerberos erhalten Sie eine einfach zu verwendende, wenn nicht automatisierte PKI.

Etwas spät hier, aber ich dachte, ich nehme einen schwierigen Fall an - der Angreifer verwendet viele zufällige IPs, zufällige Benutzernamen und ein zufälliges Passwort, das beispielsweise aus einer Liste der 10.000 beliebtesten ausgewählt wurde.

Eine Sache, die Sie tun könnten, insbesondere wenn das System angegriffen zu werden scheint, weil es viele falsche Passwortversuche auf dem System gibt, und insbesondere wenn das Passwort eine niedrige Entropie aufweist, besteht darin, eine sekundäre Frage zu stellen, wie zum Beispiel die Vornamen Ihrer Eltern . Wenn ein Angreifer eine Million Konten trifft, die das Passwort 'password1' versuchen, besteht eine gute Chance, dass er viel bekommt, aber seine Chancen, auch die Namen richtig zu machen, würden die Erfolge dramatisch reduzieren.