Eines der Probleme, die vor WEB-Ressourcen mit persönlichen Konten auftreten, ist ein Brute-Force-Angriff. Ja, eine einfache Aufzählung aller Kennwortoptionen für ein bestimmtes Konto. Dumm? Vielleicht, aber ein solcher Angriff kann die Ressource stark belasten. Wenn während der Registrierung keine Kontrolle über die Komplexität des Benutzerpassworts besteht, kann dies ebenfalls erfolgreich sein.
Meistens wird das Problem relativ einfach gelöst. Wenn der Benutzer das Passwort mehrmals falsch eingegeben hat, wird sein Konto für einige Zeit gesperrt. Eine alternative Lösung besteht darin, Captcha anzuzeigen. Sofort oder nach mehreren erfolglosen Versuchen. Vergessen wir nicht die 2F-Autorisierung, die fast unverwundbar ist. Es scheint - Gewinn! Aber nicht alles ist so rosig ...
Schauen wir uns einige der beschriebenen Probleme an:
Vorübergehende Sperrung - Das Benutzerkonto wird vorübergehend gesperrt und er kann nicht in das System gelangen. Der reale Benutzer während des Angriffs erfährt Herzschmerz und Qual. Er kann nicht in das System gelangen. Und höchstwahrscheinlich lädt es Ihre Unterstützung. Und das Interessanteste ist, dass dies vielleicht das Ziel des Angreifers ist.
Captcha ist eine relativ gute und effektive Lösung. Die Wahrheit ist für den Benutzer unpraktisch und erfordert, dass Sie dort zusätzlich etwas eingeben. Genug „unangenehm“, um in das Design eingebettet zu werden. Oh ja ... dennoch kann dieses Ding je nach Implementierung einem DoS-Angriff ausgesetzt sein.
2F-Autorisierung - Alles ist großartig. Richtig ... meistens ist dies eine optionale Sache. Schalten Sie es ein, um dem Angriff entgegenzuwirken, der nicht funktioniert. Sie ist entweder da oder nicht. Und geben Sie bei einigen Ressourcen die 2F-Berechtigung ein, sagen wir, schießen Sie Spatzen aus dem Tank.
Ich versuche, bequeme und zuverlässige Dienste zu schaffen. Deshalb habe ich mich entschlossen, mein Gehirn ein wenig zu belasten. Und genau das ist passiert.
Wenn Sie mail verwenden, z. B. mail.ru, und die 2F-Autorisierung installiert ist, haben Sie möglicherweise bereits bemerkt, dass die 2F-Autorisierung beim ersten Anmelden nur für ein neues „Gerät“ angefordert wird. Ferner wird das Gerät als vertrauenswürdig angesehen. Und Sie müssen nur Ihren Login und Ihr Passwort eingeben.
Bequeme Sache. Sozusagen benutzerfreundlich. Dies wird durch zwei Token implementiert. Die erste Kennung ist "Gerät" (definiert als devid) und die zweite ist eine Sitzungskennung (definiert als Sitzung). Im Gegensatz zu einer Sitzung verliert Devid auch nach Beendigung einer Sitzung nicht an Relevanz. Es wird beim nächsten Anmeldeversuch übertragen. Wenn der Benutzername / das Kennwort korrekt und nicht vertrauenswürdig ist, wird 2F nicht mehr angefordert. Wenn der nächste Anmeldeversuch jedoch nicht erfolgreich war, wird das Devid-Token sofort gelöscht. Und jetzt müssen Sie den vollständigen Weg der Autorisierung gehen.
Dieses Paradigma wurde als Grundlage genommen. Das heißt, Geben Sie das Devid-Token ein, das ständig ausgegeben wird, natürlich mit einer Antwort von der WEB-Ressource, wenn es nicht in der Anfrage enthalten war.
Für den Berechtigungsfall 2F wurde der obige Algorithmus tatsächlich implementiert. Und sofort wurden alle glücklich. T.ch. es macht keinen Sinn, es im Detail zu untersuchen. Aber die "Schnickschnack", es ist besser, das Diagramm mit Erklärungen zu betrachten:
Auch wenn die 2F-Autorisierung nicht installiert ist, die Anmeldung jedoch erfolgreich war, wird das Devid-Token als vertrauenswürdig markiert. Es scheint wenig sinnvoll zu sein, dies ohne 2F-Genehmigung zu tun. Aber alles ist etwas kniffliger. Wenn wir wissen, dass devid vertrauenswürdig ist, d.h. Er hatte ein erfolgreiches Login, wir gehen zumindest davon aus, dass der echte Benutzer von diesem Gerät hereingekommen ist. Dies sind sehr wichtige Informationen, die der beschriebene Algorithmus in seiner Arbeit im Angriffsreflexionsmodus verwendet.
Es wurde eine Strategie angenommen: Eine Autorisierung kann nur erfolgen, wenn ein gültiges Devid-Token vorhanden ist. Ein gültiger Devid unterscheidet sich von einem vertrauenswürdigen darin, dass er noch nicht vertrauenswürdig ist, d. H. Es gab keine erfolgreichen Anmeldungen, aber das System ist bereit, Autorisierungsanforderungen damit zu verarbeiten. Die Anzahl der Versuche ist auf das N-fache pro gültigem Token begrenzt. Wenn ein Autorisierungsfehler mehr als N Mal hintereinander auftritt, wird das Token als "gefährdet" markiert. Es wird in ein separates Journal mit Statistiken zur Auswahl übertragen. Anfragen mit seiner Teilnahme werden weiterhin bearbeitet, aber ... es ist nicht mehr möglich, sich bei ihm anzumelden. Alles, was passiert, ist die Anhäufung von Aktivitätsstatistiken.
Die dümmsten Angriffe wehren sich also. Wenn beispielsweise ein Angreifer, der devid ignoriert, versucht, sich beim System anzumelden, oder wenn er die Logik von devid nicht verstehen kann (woher weiß er, wie viele Anmeldeversuche mit demselben devid durchgeführt werden?), Werden seine Anforderungen beendet.
Eigene Front weiß, dass nach N-mal erfolglosen Anmeldeversuchen von einem Devid es bereits "faul" ist. Jetzt müssen Sie vor dem nächsten Anmeldeversuch ein neues Token erhalten.
Es scheint, was für eine Dummheit? Die Front, um den Versuch zu erfüllen, einzutreten ... aber wie ich oben sagte, ist alles schwieriger. Wenn ein Benutzer eine Standardfront durcharbeitet, ist die Wahrscheinlichkeit, dass er wirklich versucht, das System anzugreifen, vernachlässigbar. In Verbindung mit einem Kennwortkomplexitätskontrollsystem während der Benutzerregistrierung ist dies völlig zwecklos. Höchstwahrscheinlich versucht der echte Benutzer wirklich, sich an sein Passwort zu erinnern.
Also, was ist der Trick? In der Tatsache, dass wir auf der Rückseite den sehr gültigen Devid mit einem bestimmten Zeitlimit generieren. Zum Beispiel nicht mehr als 1000 Stück pro Minute. Wenn diese Grenze plötzlich überschritten wird, wird der Angriffsmodus unterbrochen. Und hier können Sie entweder radikal vorgehen und die Emission von Devids für einige Zeit stoppen, was die Begeisterung des Angreifers abkühlt, oder die Erzeugung von gültigen Devids reduzieren. Und Sie können das gleiche Captcha für alle gültigen, aber nicht vertrauenswürdigen Devids aktivieren.
Somit wird ein flexibles System zum Steuern und Verwalten von Angriffen erhalten. Es werden zuverlässige Metriken generiert, mit denen eine Überwachung ausgelöst werden kann, die einen Alarm auslöst. Akkumulierte Statistiken können in Sperrregeln usw. konvertiert werden.
Ein benutzerfreundliches System ist, weil diejenigen Benutzer, die sich zuvor angemeldet haben, d. H. Ich habe darauf vertraut, dass Devid den Angriff nicht einmal bemerkt hat. Sie werden vom System problemlos übersprungen.
Jetzt profitieren. Dieser Algorithmus ist für Ressourcen mit einer sehr hohen Last sehr gut etabliert. Es gab unter anderem DoS-Versuche am Algorithmus selbst, aber auch hier erwies es sich als würdig.