Testen der Zwei-Faktor-Authentifizierung und mögliche Problemumgehungen



Noch bevor ich mich mit der komplexen Wissenschaft der Informationssicherheit auseinandergesetzt habe, schien mir die 2FA-Authentifizierung eine garantierte Methode zum Schutz Ihres Kontos zu sein, und keine "Ihre Hacker" können beispielsweise meine interne Währung abheben, um Kleidung für Charaktere auf dem Spielkonto zu kaufen. Im Laufe der Zeit wurde jedoch experimentell nachgewiesen, dass ein Zwei-Faktor-Authentifizierungssystem eine große Anzahl von Schwachstellen aufweisen kann.

Mit einfachen Worten, die Zwei-Faktor-Authentifizierung ist eine Bestätigung der Aktion, indem der generierte Code eingegeben wird, um die Sicherheit zu erhöhen, und während der Bewegung oder vor dem Start Stöcke in die Räder bedingter Hacker geworfen werden.

Das Code-Bestätigungssystem ist weit verbreitet, es wird überall an verschiedenen Standorten verwendet und kann sowohl für primäre als auch für sekundäre Anmeldungen verbunden werden. Die Anwendung ist jedoch nicht darauf beschränkt - die Entwickler fügen eine Bestätigung über die Funktionalität der Passwortwiederherstellung, Bestätigung der Registrierung / des Abonnements, zusätzliche Bestätigung der Finanztransaktionen, Passwortänderung, Änderung der persönlichen Daten bei. Außerdem wird 2FA von Zeit zu Zeit nach dem Abmelden als Pinnwand verwendet und nicht als Kennwort oder andere Art der Bestätigung.

In diesem Artikel habe ich Möglichkeiten zum Testen von 2FA auf Sicherheitsanfälligkeiten, deren Ausnutzung sowie mögliche Optionen zum Umgehen des vorhandenen Schutzes vor bestimmten Arten von Angriffen zusammengefasst. Sehen wir uns die Liste der Schwachstellenüberprüfungen an, die für 2FA gelten:

1. Keine Rate Limit


Der Ratenlimit-Algorithmus wird verwendet, um zu testen, ob eine Benutzersitzung (oder IP-Adresse) in Versuchen oder in der Geschwindigkeit begrenzt werden kann und unter welchen Umständen dies geschieht. Wenn der Benutzer innerhalb eines bestimmten Zeitraums zu viele Anforderungen abgeschlossen hat, kann die Webanwendung mit einem 429-Code (viele Anforderungen) antworten oder ein Ratenlimit anwenden, ohne Fehler anzuzeigen. Das Fehlen eines Ratenlimits impliziert, dass es während der normalen Aufzählung keine Einschränkungen hinsichtlich der Anzahl der Versuche und / oder der Geschwindigkeit gibt. Innerhalb des Gültigkeitszeitraums der Sitzung / des Tokens kann der Code beliebig oft (mit beliebiger Geschwindigkeit) durchlaufen werden.

Sehr oft müssen Sie sich mit einem „noiseless“ -Ratenlimit auseinandersetzen. Wenn Sie feststellen, dass keine Fehler vorliegen und sich der HTTP-Body / Code bei nachfolgenden Anforderungen nicht ändert, sollten Sie zu früh glücklich sein und zuerst das Endergebnis des Angriffs mit einem gültigen Code überprüfen.

2. Ratenlimit existiert, kann aber umgangen werden


Fälle, die ich vorher treffen musste:

1) Begrenzung der Strömungsgeschwindigkeit ohne Verstopfung nach Erreichen einer bestimmten Geschwindigkeit


Häufig versuchen Sicherheitsforscher, Code mit 5 oder mehr Threads abzurufen, um einen Angriff zu beschleunigen (in Burp Intruder beträgt die Standardanzahl der Threads 5 ohne Verzögerung). Aber manchmal kann ein Sicherheitssystem, das nicht mehr funktioniert, oder ein normaler Load Balancer nur auf diesen einen Faktor reagieren. Wenn Sie versuchen, mit 5 Threads Gewalt anzuwenden, sollten Sie die Zahl auf 1 und dann mit einer Verzögerung von einer Sekunde auf 1 reduzieren. Früher hatte ich das Glück, ein solches Verhalten zu beobachten, und mithilfe solcher Manipulationen kam es zu einer erfolgreichen Code-Auswahl, die zur Übernahme des Kontos führte. Wenn der 2FA-Code kein bestimmtes Ablaufdatum hat, haben wir viel Zeit zum Sortieren. Wenn die Gültigkeitsdauer vorliegt, verringert sich der Erfolg des Angriffs, die potenzielle Gefahr einer Sicherheitsanfälligkeit besteht jedoch weiterhin, da immer noch die Möglichkeit besteht, in den gewünschten Code einzudringen.

2) Der generierte OTP-Code ändert sich nicht


Dies gilt nicht für sich ständig ändernde Codes wie in Google Authenticator, sondern nur für statische Codes, die per SMS, E-Mail oder persönlich per Messenger eingehen.

Das Wesentliche dieser Umgehung ist, dass derselbe OTP-Code ständig oder für einige Zeit, beispielsweise 5 Minuten, gesendet wird, was während dieser gesamten Zeit gültig ist. Es lohnt sich auch, darauf zu achten, dass keine stille Frequenzbegrenzung erfolgt.

Beispiel für einen Bericht: hackerone.com/reports/420163

Angenommen, die Anwendung generiert einen Zufallscode von 001 bis 999 und sendet ihn innerhalb von 10 Minuten an das Telefon. Wenn die Funktion "Erneut senden" aktiviert ist, erhalten wir denselben Code. Das Ratenlimit ist jedoch an die Anforderung gebunden, wodurch die Anzahl der Versuche pro Anforderungstoken begrenzt wird. Wir können ständig einen neuen Code anfordern, ein neues Anforderungstoken generieren, es auf eine nachfolgende Anforderung anwenden (mithilfe von grep-match in einer Burp-Suite oder mithilfe unseres eigenen Skripts) und Bruteforce mit einem Zahlenbereich von 001 bis 999 ausführen. So können wir ständig ein neues Anforderungstoken verwenden Wir werden den richtigen Code erfolgreich auswählen, da er sich nicht ändert und für einen bestimmten Zeitraum statisch ist. Die Einschränkungen dieses Angriffs sind eine lange Zahl oder das Mischen von Buchstaben mit Zahlen als Bestätigungscode.

Diese Situation sollte nicht gefördert werden. Sie sollten versuchen, mindestens einen Teil unserer Liste zu sortieren, da die Möglichkeit besteht, dass der generierte Code in diesem Teil der Liste enthalten ist, da er zufällig generiert wird. Wenn Sie es versuchen, müssen Sie sich auf Zufall verlassen, aber es besteht immer noch die Möglichkeit, die richtige Kombination zu finden, was eine Schwachstelle darstellt, die definitiv behoben werden muss.

3) Setzen Sie das Ratenlimit-a zurück, wenn Sie den Code aktualisieren.


In der Codeüberprüfungsanforderung ist das Ratenlimit vorhanden. Nach Aktivierung der Funktion zum erneuten Senden des Codes wird der Code zurückgesetzt und Sie können den Brute-Force-Code fortsetzen.
Beispiele für Berichte:

https://hackerone.com/reports/149598 , - Theorie;
hackerone.com/reports/205000 , ein praktischer Exploit, der auf einem früheren Bericht basiert.

4) Umgehen des Ratenlimits durch Ändern der IP-Adresse


Viele Sperren basieren auf der Einschränkung des Empfangs von Anforderungen von IP, das beim Ausführen einer Anforderung den Schwellenwert einer bestimmten Anzahl von Versuchen erreicht hat. Wenn die IP-Adresse geändert wird, besteht die Möglichkeit, diese Einschränkung zu umgehen. Um diese Methode zu überprüfen, ändern Sie einfach Ihre IP-Adresse über den Proxyserver / VPN und prüfen Sie, ob die Blockierung von der IP-Adresse abhängt.

Möglichkeiten, die IP zu ändern:

  • Proxies können bei einem Angriff mit dem IP Rotator-Add-On für Burp Suite verwendet werden. Github.com/RhinoSecurityLabs/IPRotate_Burp_Extension. Meiner Meinung nach ist dies die beste Wahl, da es uns ~ unbegrenzte Brute-Force-Versuche und IP-Adressen gibt, mit denen Sie einen Brute-Force-Angriff ohne 42-fache Fehler und Unterbrechungen durchführen können.
  • Eine gute Option könnte ein Python-Skript mit einem Proxy-Anforderungsmodul sein, aber zuerst müssen Sie eine große Anzahl gültiger Proxys irgendwo abrufen.

Da das IP-Rotationstool Anforderungen unter Verwendung von AWS-IP-Adressen sendet, werden alle Anforderungen blockiert, wenn sich die Webanwendung hinter der CloudFlare-Firewall befindet.



In diesem Fall müssen Sie zusätzlich die IP des ursprünglichen Webservers ermitteln oder eine Methode finden, die keine AWS-IP-Adressen betrifft.

5) Die Site enthält Unterstützung für X-Forwarded-For


Der integrierte X-Forwarded-For-Header kann zum Ändern der IP-Adresse verwendet werden. Wenn die Anwendung über eine integrierte Verarbeitung für diesen Header verfügt, senden Sie einfach X-Forwarded-For: desired_IP, um die IP zu ersetzen und die Einschränkung ohne die Verwendung zusätzlicher Proxys zu umgehen. Jedes Mal, wenn eine Anfrage von X-Forwarded-For gesendet wird, geht der Webserver davon aus, dass unsere IP-Adresse mit dem über den Header übertragenen Wert übereinstimmt.
Materialien zu diesem Thema:
hackerone.com/reports/225897
medium.com/@arbazhussain/bypassing-rate-limit-protection-by-spoofing-originating-ip-ff06adf34157

3. Umgehen Sie 2fa, indem Sie einen Teil der Anforderung durch eine Sitzung eines anderen Kontos ersetzen


Wenn ein Parameter mit einem bestimmten Wert gesendet wird, um den Code in der Anforderung zu überprüfen, versuchen Sie, den Wert aus der Anforderung an ein anderes Konto zu senden.

Wenn Sie beispielsweise einen OTP-Code senden, wird die Formular-ID, Benutzer-ID oder das Cookie überprüft, die bzw. das mit dem Senden des Codes verknüpft ist. Wenn wir die Daten aus den Parametern des Kontos, für das Sie die Codeüberprüfung umgehen möchten (Konto 1), auf eine Sitzung eines völlig anderen Kontos (Konto 2) anwenden, erhalten wir den Code und geben ihn auf dem zweiten Konto ein. Dann können wir den Schutz für das erste Konto umgehen. Nach dem Neuladen der Seite sollte 2FA verschwinden.

4. Bypass 2FA mit der "Memorization-Funktion"


Viele Sites, die die 2FA-Autorisierung unterstützen, verfügen über die Funktion "An mich erinnern". Dies ist nützlich, wenn der Benutzer bei nachfolgenden Anmeldungen keinen 2FA-Code eingeben möchte. Es ist wichtig, die Art und Weise zu identifizieren, in der 2FA „erinnert“ wird. Dies kann ein Cookie sein, ein Wert im Sitzungs- / lokalen Speicher oder einfach das Anhängen von 2FA an eine IP-Adresse.

1) Wenn 2FA mithilfe eines Cookies angehängt wird, muss der Cookie-Wert nicht ermittelbar sein


Das heißt, wenn ein Cookie aus einer Reihe von Zahlen besteht, die sich für jedes Konto erhöhen, ist es durchaus möglich, einen Brute-Force-Angriff auf den Cookie-Wert durchzuführen und 2FA zu umgehen. Entwickler sollten das Cookie (zusammen mit dem Schlüsselsitzungscookie und dem CSRF-Token) mit dem Attribut HttpOnly versehen, damit es nicht mit XSS gestohlen und zur Umgehung von 2FA verwendet werden kann.

2) Wenn 2FA an die IP-Adresse angehängt ist, können Sie versuchen, sie zu ersetzen


Um diese Methode zu identifizieren, melden Sie sich mit der 2FA-Speicherfunktion bei Ihrem Konto an, wechseln Sie dann zu einem anderen Browser oder Inkognito-Modus des aktuellen Browsers und versuchen Sie erneut, sich anzumelden. Wenn 2FA überhaupt nicht angefordert wird, wurde 2FA an die IP-Adresse angehängt.
Um die IP-Adresse zu ersetzen, können Sie den X-Forwarded-For-Header bei der Eingabe des Anmeldenamens und des Kennworts verwenden, sofern die Webanwendung dies unterstützt.

Mit diesem Header können Sie auch die Whitelist-Funktion für IP-Adressen umgehen, sofern in den Kontoeinstellungen eine vorhanden ist. Es kann in Verbindung mit 2FA als zusätzlicher Kontoschutz verwendet werden oder 2FA kann nicht einmal angefordert werden, wenn die IP-Adresse mit der Whitelist übereinstimmt (mit Zustimmung des Benutzers). Selbst ohne das Anhängen des 2FA an die IP-Adresse kann das 2FA in einigen Fällen umgangen werden, indem die zugehörigen Schutzmethoden umgangen werden.
Im Allgemeinen ist das Anhängen von 2FA an eine IP-Adresse kein völlig sicherer Schutz, da 2FA umgangen werden kann, wenn Sie sich im selben Netzwerk befinden und mit demselben VPN- / Internetdienstanbieter mit einer statischen IP-Adresse verbunden sind.

Der sicherste Weg, sich zu schützen, besteht darin, sich überhaupt nicht an 2FA zu erinnern, was sich nachteilig auf die Benutzerfreundlichkeit auswirkt.

5. Fehler bei der Zugriffskontrolle auf der 2FA-Eingabeseite


Manchmal wird eine Dialogseite zur Eingabe von 2FA als URL mit Parametern angezeigt. Der Zugriff auf eine solche Seite mit Parametern in der URL mit Cookies, die nicht mit denen übereinstimmen, die zum Generieren der Seite verwendet wurden, oder ohne Cookies ist nicht sicher. Wenn sich die Entwickler jedoch dazu entschlossen haben, die Risiken zu akzeptieren, müssen Sie einige wichtige Punkte durchgehen:

  1. Läuft der Link für 2FA-Eingaben ab?
  2. ob der Link in Suchmaschinen indiziert ist.

Wenn der Link eine lange Lebensdauer hat und / oder die Suchmaschinen funktionierende Links für 2FA-Eingaben enthalten / Links indiziert werden können (es gibt keine Regeln in robots.txt / meta-Tags), besteht die Möglichkeit, auf der 2FA-Eingabeseite einen 2FA-Bypass-Mechanismus zu verwenden Umgehen Sie Login und Passwort vollständig und greifen Sie auf das Konto einer anderen Person zu.

6. Unzureichende Zensur personenbezogener Daten auf Seite 2FA


Beim Senden eines OTP-Codes auf einer Seite wird die Zensur verwendet, um persönliche Daten wie E-Mail, Telefonnummer, Spitzname usw. zu schützen. Diese Daten können jedoch vollständig in den API-Endpunkten und anderen Anfragen offengelegt werden, für die wir im 2FA-Stadium über ausreichende Rechte verfügen. Wenn diese Daten anfangs nicht bekannt waren, wir beispielsweise nur ein Login eingegeben haben, ohne die Telefonnummer zu kennen, wird dies als Sicherheitslücke in Bezug auf die Offenlegung von Informationen angesehen. Die Kenntnis der Telefonnummer / E-Mail-Adresse kann für nachfolgende Phishing- und Brute-Force-Angriffe verwendet werden.

Ein Beispiel für die Ausnutzung einer Sicherheitsanfälligkeit mit Credentials Stuffing. Angenommen, es gibt eine öffentlich zugängliche Datenbank mit Anmeldungen und Kennwörtern für Site A. Angreifer können die Daten aus dieser Datenbank auf Site B verwenden:

  • Zuerst prüfen sie, ob der Benutzer in der Datenbank von Standort B vorhanden ist, indem sie den Fehler „Accounts Enumeration“ beim Registrieren / Wiederherstellen des Kennworts verwenden. In der Regel betrachten viele Websites dies nicht als Sicherheitsanfälligkeit und gehen Risiken ein. "Sicherheitslücke" liegt im Vorliegen eines Fehlers über die Tatsache der Benutzerregistrierung auf der Website. Im Idealfall lautet eine sichere Nachricht auf der Seite zur Kennwortwiederherstellung wie folgt:



  • Nachdem die Datenbank der vorhandenen Benutzer abgerufen wurde, wenden Angreifer Kennwörter auf diese Konten an.
  • Wenn sie auf 2FA stoßen, bleiben sie stecken. Im Falle einer unzureichenden Zensur von Benutzerdaten können sie ihre Datenbank jedoch durch ihre persönlichen Daten ergänzen (sofern sie nicht in der ursprünglichen Datenbank enthalten sind).

7. Ignorieren von 2FA unter bestimmten Umständen


Bei der Ausführung einiger Aktionen, die zur automatischen Anmeldung bei Ihrem Konto führen, wird 2FA möglicherweise nicht angefordert.

1) Ignorieren Sie 2FA, wenn Sie ein Passwort wiederherstellen


Viele Dienste melden sich automatisch bei Ihrem Konto an, nachdem die Passwortwiederherstellung abgeschlossen wurde. Da der Zugriff auf das Konto sofort gewährt wird, kann es beim Anmelden bei Ihrem 2FA-Konto ignoriert und vollständig ignoriert werden.

Auswirkungen eines ähnlichen Hackerone-Berichts, den ich kürzlich gesendet habe:
Wenn ein Angreifer Zugriff auf die E-Mail des Opfers erhält (er kann das Konto mit Phishing, Brute-Force-Angriffen, Stuffing von Anmeldeinformationen usw. hacken), kann er 2FA umgehen, obwohl 2FA in diesem Fall das Konto schützen sollte. Derzeit wird für 2FA der Google Authenticator-Code oder der Sicherungscode überprüft, nicht jedoch der Code aus der E-Mail. Daher ist diese Umgehung sinnvoll.

2) Ignoriere 2FA, wenn du dich über ein soziales Netzwerk anmeldest


Sie können Ihrem Benutzerkonto ein soziales Netzwerk hinzufügen, um sich schnell bei Ihrem Konto anzumelden und gleichzeitig 2FA einzurichten. Wenn Sie sich über soziale Netzwerke in Ihrem Konto anmelden, kann 2FA ignoriert werden. Wenn die E-Mail des Opfers gehackt wird, kann das Kennwort für das Konto des sozialen Netzwerks wiederhergestellt werden (sofern dies zulässig ist) und der Dienst ohne Eingabe von 2FA aufgerufen werden.

Auswirkungen eines der Berichte:
  1. Eine Reihe anderer Sicherheitsanfälligkeiten, z. B. die zuvor gesendete OAuth-Fehlkonfiguration # 577468, um das Konto vollständig zu erfassen und 2FA zu beschädigen.
  2. Wenn ein Angreifer die E-Mail-Adresse des Benutzers gehackt hat, kann er versuchen, den Zugriff auf das Konto des sozialen Netzwerks wiederherzustellen und sich ohne weitere Überprüfung in das Konto einzuloggen.
  3. Wenn sich ein Angreifer einmal in das Konto eines Opfers gehackt hat, kann er dem Konto ein soziales Netzwerk zuordnen und sich in Zukunft in das Konto einloggen, 2FA vollständig ignorieren und den Benutzernamen / das Passwort eingeben.

3) Ignorieren von 2FA in einer älteren Version der Anwendung


Entwickler fügen Domänen / Unterdomänen häufig Staging-Versionen einer Webanwendung hinzu, um bestimmte Funktionen zu testen. Interessanterweise wird 2FA nicht angefordert, wenn Sie sich mit Ihrem Benutzernamen und Kennwort anmelden. Möglicherweise verwenden die Entwickler eine ältere Version der Anwendung, in der es keinen Schutz für 2FA gibt, 2FA selbst deaktiviert ist oder die absichtlich zum Testen deaktiviert wurde.

Sie können auch gleichzeitig andere Sicherheitslücken überprüfen. - Wenn Sie einen neuen Benutzer auf einem Staging-Server registrieren, dessen E-Mail in der Datenbank der Produktionsversion vorhanden ist, können Sie uns personenbezogene Daten aus der Produktion übermitteln. das Fehlen eines Ratenlimits bei wichtigen Funktionen, z. B. der Passwortwiederherstellung. Ein Beispiel für die jüngste Sicherheitsanfälligkeit ist ein Facebook-Fehler in Höhe von 15.000 US-Dollar, der das Hacken eines Kontos mithilfe des Wiederherstellungscodes für Bruteforce-Kennwörter unter beta.facebook.com ermöglichte. facebook-accounts-f47c0252ae4d .

4) Ignorieren von 2FA bei Cross-Plattform


2FA-Implementierungen in der Mobil- oder Desktopversion können von der Webversion der Anwendung abweichen. 2FA ist möglicherweise schwächer als in der Webversion oder fehlt vollständig.

7. Beim Deaktivieren von 2FA wird der aktuelle Code nicht angefordert.

Wenn beim Deaktivieren von 2FA keine zusätzliche Bestätigung angefordert wird, z. B. der aktuelle Code aus der Google-Authentifizierungsanwendung oder der Code aus E-Mail / Telefon, bestehen in diesem Fall bestimmte Risiken. Bei einer sauberen Anfrage besteht die Möglichkeit eines CSRF-Angriffs. Wenn ein Bypassvektor mit CSRF-Schutz gefunden wird (falls vorhanden), kann 2FA deaktiviert werden. Eine Clickjacking-Sicherheitsanfälligkeit kann ebenfalls ausgenutzt werden. Nach einigen Klicks eines ahnungslosen Benutzers wird die Verbindung zu 2FA getrennt. Durch die Validierung des vorherigen Codes wird ein zusätzlicher 2FA-Schutz hinzugefügt, wenn potenzielle CSRF / XSS / Clickjacking-Angriffe sowie CORS-Fehlkonfigurationen vorliegen.

Ich gebe Ihnen ein Beispiel für hackerone.com. - Wenn Sie 2FA in einem Formular deaktivieren, müssen Sie gleichzeitig zwei Variablen eingeben. - Den aktuellen Code mit Google Authenticator-Anwendung und Passwort. Dies ist der beste und empfohlene Schutz.



8. Bereits erstellte Sitzungen bleiben nach Aktivierung von 2FA gültig


Wenn 2FA aktiviert ist, ist es wünschenswert, dass parallele Sitzungen auf demselben Konto enden und der 2FA-Eingabedialog angezeigt wird, ebenso wie bei einer Kennwortänderung. Wenn das Konto kompromittiert wurde und die erste Reaktion des Opfers die Einbeziehung von 2FA ist, wird die Sitzung des Angreifers deaktiviert und der nächste Login und das nächste Passwort erfordern 2FA. Alles in allem ist dies die beste Vorgehensweise, die befolgt werden muss. Ich stelle oft fest, dass Kryptowährungsaustausche einen ähnlichen Schutz bieten. Beispiel für einen HackerOne-Bericht, -
https://hackerone.com/reports/534450.

9. Das Fehlen eines Tariflimits in Ihrem Konto


2FA kann in verschiedenen Funktionen des persönlichen Benutzerkontos implementiert werden, um die Sicherheit zu erhöhen. Dies kann eine Änderung der E-Mail-Adresse, des Passworts, die Bestätigung einer Codeänderung für Finanztransaktionen usw. sein. Das Vorhandensein von rate-limit-a in Ihrem Konto kann sich von dem Vorhandensein von rate-limit-a in 2FA bei der Eingabe Ihres Kontos unterscheiden. Ich bin oft auf ähnliche Fälle gestoßen, in denen es möglich war, einen 2FA-Code in meinem Konto frei zu wählen, während am Eingang ein „strenges“ Tariflimit festgelegt wurde.

Wenn die Entwickler ursprünglich Schutz vor nicht autorisierten Datenänderungen hinzugefügt haben, muss dieser Schutz von allen möglichen Bypass-s unterstützt und korrigiert werden. Wenn die Umgehung gefunden wird, wird dies als Sicherheitsanfälligkeit in Bezug auf die Umgehung von Sicherheitsfunktionen angesehen, die von den Entwicklern implementiert wurde.

10. API-Versionierung


Wenn Sie in der Anforderung der Webanwendung etwas wie / v * / sehen, wobei * eine Zahl ist, können Sie wahrscheinlich zu einer älteren Version der API wechseln. API . , API production/staging .
, /endpoint/api/v4/login , . 2FA , /endpoint/api/v4/2fa_check, . API 2FA, , , . /endpoint/api/v3/login /endpoint/v3/login_successful?code=RANDOM, 2fa_check , API, 2FA .

, — /endpoint/api/v4/2fa_check rate-limit, /endpoint/api/v3/2fa_check - .

11. Improper Access Control


2FA . ( ). CORS /XSS , «» , 2FA, .

, 2 , , , 2FA web , — . , 2FA ( Salesforce, Valve) 2FA. 2FA , 2FA bypass-.

, , bug bounty , , . Stay safe!

Source: https://habr.com/ru/post/de483134/


All Articles