K\u00fcrzlich haben unsere Experten von Kaspersky Blockchain Security beim Testen einer Blockchain-Plattform auf Schwachstellen festgestellt, dass der Passwortwiederherstellungsprozess der Plattform durch einen Benutzer-Enumerationsangriff anf\u00e4llig war. Webentwickler m\u00fcssen sich dieser Art von Angriff und seiner Gefahren bewusst werden.<\/p>\n
Webanwendungen mit Kennwort- und Anmeldeauthentifizierung enthalten normalerweise mehrere Komponenten, die mit der Benutzerdatenbank interagieren: das Anmeldefenster (aus offensichtlichen Gr\u00fcnden), das Registrierungsformular (um doppelte Benutzernamen zu vermeiden) und die Seite zur Passwortzur\u00fccksetzung (um sicherzustellen, dass das entsprechende Konto existiert). Wenn Webentwickler diese Funktionen nicht sicher genug implementieren, k\u00f6nnen Angreifer sie m\u00f6glicherweise verwenden, um festzustellen, ob ein bestimmter Benutzername in der Datenbank vorhanden ist.<\/p>\n
In der Vergangenheit war es \u00fcblich, dass Entwickler all diese Funktionen ohne Schutz implementierten, und Angreifer konnten eine Liste von Benutzernamen und ein Programm verwenden, das die Benutzernamen einzeln nacheinander eingab. Um potenzielle Hacker fernzuhalten, begannen die Entwickler im Laufe der Zeit, Schutztricks wie Captcha, Begrenzung der Anzahl der Anmeldeversuche und die Verwendung von Sternchen oder anderen Mitteln anzuwenden, um bestimmte Antwortdetails zu verbergen.<\/p>\n
In modernen Webanwendungen bietet das Anmeldefenster normalerweise diesen Schutz. Bei Registrierungsformularen und bei Passw\u00f6rtzur\u00fccksetzungseiten fehlt es jedoch manchmal. Dar\u00fcber hinaus ber\u00fccksichtigen Webentwickler nicht immer, dass die Anwesenheit oder Abwesenheit eines Benutzers in der Datenbank durch die Schnelligkeit der Serverantwort bestimmt werden kann. Wenn der Benutzername beispielsweise in der Datenbank angezeigt wird, dauert die Antwort des Servers 2 Millisekunden. Wenn nicht, dauert die Antwort doppelt so lange \u2013 4 Millisekunden. F\u00fcr einen Menschen ist der Unterschied nicht erkennbar, aber f\u00fcr automatisierte Enumerationstools ist er leicht zu erkennen.<\/p>\n
Bei einem Enumerationsangriff kann ein Hacker \u00fcberpr\u00fcfen, ob ein Nutzername in der Datenbank vorhanden ist. Dadurch kann sich der Hacker nicht sofort anmelden, aber er erh\u00e4lt die H\u00e4lfte der erforderlichen Informationen. Um beispielsweise einen Brute-Force-Angriff auszuf\u00fchren, anstatt Anmelde- und Kennwortpaare zu durchsuchen, ben\u00f6tigt man lediglich ein passendes Kennwort f\u00fcr einen verifizierten Benutzernamen, was Zeit und M\u00fche spart.<\/p>\n
Au\u00dferdem nutzt fast jeder Dienst E-Mail-Adressen als Benutzernamen. Daher hat der durchschnittliche Benutzer ein Login f\u00fcr viele Websites, und nicht alle Websites nehmen die Sicherheit gleich ernst. Nachrichten \u00fcber Datenleaks von Login und Passw\u00f6rtern sind bedr\u00fcckend h\u00e4ufig. Konsolidierte Sammlungen von Daten aus diesen Lecks sind in Hackerforen verf\u00fcgbar. Au\u00dferdem verwenden Benutzer in der Regel dieselben Kennw\u00f6rter auf verschiedenen Websites. Nachdem ein Angreifer sichergestellt hat, dass auf einer Website ein spezifischer Benutzername vorhanden ist, kann er auf eine solche Sammlung zur\u00fcckgreifen, um festzustellen, ob auf anderen Websites Kennw\u00f6rter f\u00fcr denselben Benutzer vorhanden sind, um sie dann zu verwenden.<\/p>\n
Dar\u00fcber hinaus setzen Spear-Phishing-Angreifer w\u00e4hrend der Sp\u00e4hphase h\u00e4ufig Enumerationsangriffe ein. Nachdem sie festgestellt haben, dass ihr Zielobjekt \u00fcber ein Konto bei Ihrem Dienst verf\u00fcgt, k\u00f6nnen sie eine E-Mail senden, die anscheinend von Ihnen stammt, den Benutzer auffordern, sein Kennwort zu \u00e4ndern, und auf eine Phishing-Seite verlinken, die Ihrer Website \u00e4hnelt. Wenn der ahnungslose Kunde ein neues Passwort eingibt, muss er auch das alte best\u00e4tigen und damit den Betr\u00fcgern alles zur Verf\u00fcgung stellen, was sie brauchen.<\/p>\n
Haben Sie jemals bemerkt, wie moderne Websites auf die \u00dcbermittlung eines Formulars zum Zur\u00fccksetzen von Passw\u00f6rtern reagieren? Sie sagen n\u00e4mlich nicht: \u201eEin Link zum Zur\u00fccksetzen Ihres Passworts wurde an Sie gesendet\u201c oder \u201eDie angegebene E-Mail-Adresse befindet sich nicht in unserer Datenbank\u201c, wie es Websites gewohnt sind. Stattdessen nutzen sie: \u201eWenn diese E-Mail in unserer Datenbank vorhanden ist, senden wir Ihnen eine Nachricht mit einem Link.\u201c Mit anderen Worten, Websites best\u00e4tigen oder leugnen die Existenz des Benutzernamens nicht ausdr\u00fccklich. Sie haben die \u00c4nderung speziell zum Schutz vor Benutzernamen-Enumerationsangriffe vorgenommen.<\/p>\n
Ebenso m\u00fcssen Sie im Anmeldefenster nicht detailliert erkl\u00e4ren, dass der Benutzer ein falsches Kennwort eingegeben hat oder dass kein solcher Benutzername im System vorhanden ist. Sagen Sie einfach, dass die Login \/ Passwort-Kombination nicht gefunden wurde. Unter UX-Gesichtspunkten ist es nicht ideal. Zum einen \u00e4rgere ich mich, wenn ich vergesse, welche E-Mail ich f\u00fcr die Registrierung verwendet habe, aber ich bin mir ziemlich sicher \u00fcber das Passwort oder umgekehrt, aber die Website gibt mir keine Ahnung, in welchem Feld Ich habe mich geirrt Sicherheit geht jedoch praktisch immer zu Lasten des Komforts, und bei Authentifizierungsdiensten ist eine geringf\u00fcgige Sicherheitsabweichung gerechtfertigt.<\/p>\n