Digitale Identität

MFA: Warum Ihre Google-Authenticator-App Sie verrät

Nicht alle MFA-Lösungen sind gleichwertig. Anatomie der Angriffe, die TOTP überwinden, und der Migrationspfad zu FIDO2.

Veröffentlicht am 30. Januar 2025 14 Min. Lesezeit Exponiert

Zuletzt überprüft: 28. Februar 2026

USB-Sicherheitsschlüssel vor dunklem Hintergrund

Ein Kunde zeigt mir stolz sein Handy. Google Authenticator, rund zwanzig Konten darin, Backup synchronisiert. „Ich bin abgesichert.” Drei Wochen zuvor hatte sein Google-Konto als Einfallstor gedient: eine gefälschte E-Mail zum Teilen eines Dokuments, eine Login-Seite, die der von Google zum Verwechseln ähnlich sah, ein sechsstelliger Code, gedankenlos abgetippt. Der Angreifer hat nichts geknackt. Der Kunde hat ihm den Code gereicht, in Echtzeit, wie man dem Parkservice seinen Schlüssel reicht. Und seine „Absicherung” war auf das Konto synchronisiert, das gerade gefallen war.

Angle de lecture

Particulier RSSI / DSI CEO

Die übliche Falle

„Ich habe 2FA aktiviert, ich bin geschützt.” Das ist der Satz, den ich im Audit am häufigsten höre, und der gefährlichste im Vokabular der persönlichen Sicherheit. Nicht weil er im strengen Sinne falsch wäre — MFA reduziert das Risiko gegenüber einem bloßen Passwort tatsächlich. Sondern weil er in ein einziges Kästchen „geschützt / nicht geschützt” Mechanismen einordnet, die in puncto Robustheit nichts miteinander zu tun haben.

MFA ist keine einheitliche Kategorie, es ist ein Spektrum. An einem Ende der Code per SMS, der beim erstbesten SIM-Swapping fällt. In der Mitte das TOTP — jene sechsstelligen Codes, die sich alle dreißig Sekunden ändern, der berühmte Google Authenticator. Am anderen Ende das FIDO2, ein Hardwareschlüssel oder ein Passkey, der sich physisch weigert, sich auf der falschen Domain zu authentifizieren. Zwischen SMS und FIDO2 liegen zwei Größenordnungen Unterschied bei der Phishing-Resistenz. All das in denselben Topf „2FA” zu werfen, heißt zu sagen „ich habe ein Schloss”, ohne anzugeben, ob es ein Badezimmerriegel oder ein zertifizierter Schließzylinder ist.

Die praktische Konsequenz ist doppelt, und beide Seiten sind schlecht. Einerseits Menschen, die sich für geschützt halten und nicht in echten Schutz investieren, weil sie meinen, das Kästchen bereits abgehakt zu haben. Andererseits die Illusion, die im schlimmsten Moment zusammenbricht — während eines gezielten Angriffs, unterwegs, auf dem Konto, das ihr gesamtes digitales Leben steuert. TOTP ist nicht nutzlos. Aber es als Endspiel zu verkaufen, ist die Wurzel des Problems.

Das wahre Bedrohungsmodell: was TOTP überwindet

Das grundlegende Missverständnis ist der Glaube, TOTP schütze gegen Phishing. Tut es nicht. Es schützt gegen eine bestimmte Sache — den Passwortdiebstahl ohne Echtzeit-Interaktion mit dem Opfer — und das war’s. Gegen einen Angreifer, der mit Ihnen spricht, während Sie sich anmelden, ist der sechsstellige Code ein weiterer abzutippender Faktor, keine Mauer.

Hier die konkrete Mechanik, die ich in den Akten sehe. Der Angreifer baut keine statische Fake-Seite, die Ihr Passwort sammelt, um es später abzuspielen. Er stellt einen Reverse-Proxy zwischen Sie und den echten Dienst — das ist ein sogenannter Adversary-in-the-Middle-Angriff (AiTM). Sie landen auf einer Seite, die Byte für Byte die echte Login-Seite ist: Es ist keine Kopie, es ist die echte Seite, in Echtzeit weitergeleitet. Sie tippen Ihren Benutzernamen, der Proxy leitet ihn an Microsoft oder Google weiter. Der echte Dienst verlangt den TOTP-Code. Sie tippen ihn. Der Proxy leitet auch ihn weiter. Der Dienst validiert und schickt ein authentifiziertes Session-Cookie zurück — und genau dieses Cookie fängt der Angreifer ab. Er hat jetzt Ihre aktive Sitzung. Der sechsstellige Code war bereits verbraucht; das ist ihm egal, er hat etwas Besseres: Er ist als Sie angemeldet, ohne erneut durch die MFA zu müssen.

Dieses Werkzeug ist nicht Nationalstaaten vorbehalten. Open-Source-Frameworks wie Evilginx tun genau das, schlüsselfertig, mit vorkonfigurierten „Phishlets” für Office 365, Google Workspace, Okta, die wichtigsten Anbieter. Das AiTM-Phishing-Kit wird in kriminellen Foren im Abo vermietet — „Phishing-as-a-Service”, mit Hosting, gültigem TLS-Zertifikat für die Köderdomain und Dashboard zum Einsammeln der gestohlenen Sitzungen. Die technische Hürde, um Ihr TOTP zu umgehen, ist auf das Niveau eines motivierten Script-Kiddies gesunken. Microsoft hat AiTM-Kampagnen dokumentiert, die zehntausende Organisationen betrafen. Das ist weder theoretisch noch selten.

Das Detail, das in diesem Szenario weh tut: Alle Reflexe, die man Ihnen zum Erkennen von Phishing beigebracht hat, versagen hier. Das TLS-Schloss in der Adressleiste? Vorhanden — der Angreifer hat ein echtes Zertifikat für seine Köderdomain. Die Seite, die „echt aussieht”? Sie ist echt, Pixel für Pixel weitergeleitet. Der TOTP-Code, den Sie tippen, „weil es ja die richtige Seite ist”? Er wird durchgeschleust. Und selbst die Push-Bestätigungsbenachrichtigung, die angeblich „sicherer” als TOTP ist, löst nichts: Der Angreifer löst die legitime Anmeldung genau in dem Moment aus, in dem Sie bestätigen, also genehmigen Sie seine Sitzung im Glauben, Ihre eigene zu genehmigen. Das ist die „MFA-Müdigkeit” in ihrer chirurgischen Variante. Alles, was auf einem Menschen beruht, der ein Geheimnis im richtigen Moment abtippt oder genehmigt, ist verwundbar, weil der Mensch den richtigen vom falschen Moment nicht unterscheiden kann, wenn der Proxy perfekt ist.

Man muss auch eine hartnäckige Fehlannahme töten: „TOTP ist mathematisch solide, also ist die TOTP-App solide”. Die beiden Aussagen haben nichts miteinander zu tun. Ja, der Algorithmus der RFC 6238 ist bombenfest — ein HMAC über einen Zeitzähler, nichts auszusetzen. Aber die Robustheit eines Authentifizierungsfaktors bemisst sich nicht an der Stärke seines Algorithmus; sie bemisst sich daran, was nötig ist, um ihn unter realen Bedingungen zu umgehen. Und unter realen Bedingungen knackt man nicht den HMAC: Man fängt den Code im Transit ab oder stiehlt die Seeds im Ruhezustand. Der perfekte Algorithmus schützt nichts, wenn das Geheimnis, das er handhabt, seitlich ausläuft.

Und das ist nur der Online-Vektor. TOTP hat eine zweite Achillesferse, banaler: das Cloud-Backup. Das ist die Falle meines Kunden in der Eröffnung. Wenn Sie Google Authenticator mit Ihrem Google-Konto synchronisieren oder Authy mit Ihrem Authy-Konto, verlassen Ihre TOTP-Seeds — die Geheimnisse, die die Codes erzeugen — Ihr Handy, um in einer Cloud zu leben. Von da an ist Ihr „zweiter Faktor” nicht mehr unabhängig vom ersten: das Cloud-Konto zu kompromittieren kompromittiert die Gesamtheit Ihrer Codes in einem einzigen Zug. Sie haben einen Besitzfaktor in eine Erweiterung Ihres E-Mail-Kontos verwandelt. An dem Tag, an dem dieses Konto fällt — Phishing, wiederverwendetes Passwort, Leak — holt sich der Angreifer den gesamten Tresor.

Der Tresor, der seinen eigenen Schlüssel enthält

Realer Fall, Geschäftsführer eines mittelständischen Industriebetriebs. Google-Konto kompromittiert durch ein wiederverwendetes Passwort, das in einem alten Leak auftauchte. Der Angreifer aktiviert die Authenticator-Synchronisierung von seiner eigenen Maschine aus und holt sich im Klartext die TOTP-Seeds von vierzehn Konten: Geschäftsbank, Mailbox, Webhoster, Cloud-Konsole, administrative Konten. Verstrichene Zeit zwischen der ersten betrügerischen Anmeldung und dem Zugriff auf das vierzehnte Konto: weniger als vierzig Minuten. Die „2FA” hat niemanden gebremst, weil sie in dem Konto lag, das gerade gefallen war. Das einzige Konto, das an jenem Tag widerstand, nutzte einen FIDO2-Hardwareschlüssel — der Angreifer hatte das physische Objekt nicht, Ende der Geschichte.

Der richtige Ansatz: hierarchisieren, dann das Kritische auf FIDO2 umstellen

Die Lösung ist nicht „löschen Sie TOTP”. Sie lautet „hören Sie auf, alle Ihre Konten gleich zu behandeln, und setzen Sie den echten Schutz dorthin, wo es zählt”. Legen Sie zuerst die Robustheitshierarchie fest, vom Schlechtesten zum Besten: SMS, dann Cloud-TOTP, dann lokales TOTP, dann Hardware-FIDO2. Jede Stufe hebt die Phishing-Resistenz um eine Sprosse. SMS fällt beim SIM-Swapping. Cloud-TOTP fällt mit dem Cloud-Konto. Lokales TOTP widersteht dem Fernabgriff der Seeds, bleibt aber in Echtzeit per AiTM „phishbar”. FIDO2 hingegen bricht den AiTM-Angriff konstruktionsbedingt.

Warum FIDO2 anders und nicht nur „besser” ist: Die Kryptografie von WebAuthn bindet die Authentifizierung an die Domain. Der Schlüssel signiert eine Antwort, die den exakten Ursprung der anfragenden Seite enthält. Sind Sie auf login-microsoft.angreifer.com statt auf login.microsoftonline.com, passt die Signatur nicht, und der Schlüssel verweigert — ohne dass Sie irgendetwas erkennen müssten, ohne menschliches Urteil, ohne „ist diese URL komisch?”. Das Geheimnis verlässt nie das Hardware-Element: Es gibt keinen Code zum Abtippen, also nichts im Proxy abzufangen. Das nennen CISA und das NIST eine „phishing-resistente” MFA, im Gegensatz zu allem Übrigen. Die Unterscheidung ist nicht Marketing, sie ist strukturell.

Die pragmatische Umstellung hält sich an eine Regel: Alles, was den Rest zurücksetzen kann, kommt zuerst dran. Ihre Haupt-E-Mail ist die Wurzel — über sie laufen alle Passwort-Zurücksetzungen. Setzen Sie sie vor allem anderen unter FIDO2. Dann die Finanzkonten, dann der Passwortmanager, dann die Administrationskonsolen, falls Sie welche haben. Für den Rest — die Hunderte von Nebenkonten, bei denen FIDO2 nicht angeboten oder nicht gerechtfertigt ist — behalten Sie TOTP, aber lokal, in einer App, die Ihre Seeds nicht in eine mit Ihrer Identität verknüpfte Cloud synchronisiert. Aegis auf Android, Raivo oder Ente Auth auf iOS: verschlüsselte Seeds auf dem Gerät, manueller verschlüsselter Export für das Backup, kein automatisches Backup in dem Konto, das das TOTP eigentlich schützen soll. Und niemals, niemals das TOTP im selben Cloud-Passwortmanager wie die Passwörter: sonst gibt eine einzige Kompromittierung Faktor 1 und Faktor 2.

Konkret zählt die Reihenfolge der Schritte ebenso wie das Ziel, denn die Migration ist der Moment, in dem man sich aus Ungeschicklichkeit selbst aussperrt. Die Sequenz, die ich anwenden lasse: Zuerst registriere ich beide FIDO2-Schlüssel auf dem Zielkonto, während die alte Methode noch aktiv ist — man fügt nie einen starken Faktor hinzu, indem man im selben Zug den alten löscht. Dann teste ich eine vollständige Ab- und Anmeldung mit jedem der beiden Schlüssel, getrennt, um zu prüfen, dass keiner halb registriert wurde. Dann hole und speichere ich offline die Wiederherstellungscodes, die der Dienst generiert — auf Papier, nicht im Manager, der selbst von diesem Konto abhängt. Und erst dann entferne ich die schwachen Methoden: SMS, E-Mail-OTP und gegebenenfalls das redundant gewordene TOTP. Einen dieser Schritte zu überspringen, heißt entweder sich auszusperren oder eine schwache Tür „vorübergehend” offen zu lassen — und das Vorübergehende bleibt.

Der lokale TOTP-Teil verdient dieselbe Disziplin, denn seine Schwachstelle ist nicht der Angriff, sondern der Verlust. Eine lokale App, die nichts synchronisiert, ist genau das, was man sicherheitsseitig will — und genau das, was Sie verdammt an dem Tag, an dem das Handy in der Kloschüssel landet, falls Sie kein Backup haben. Die Abhilfe besteht aus zwei Handgriffen: ein verschlüsselter Export der Seeds (Aegis macht das in AES, geschützt durch eine starke Passphrase), gelagert auf einem Offline-Medium, und die Aufbewahrung der Wiederherstellungscodes jedes Dienstes zum Zeitpunkt der Einrichtung. Sie brauchen keine Cloud, um den Verlust eines Geräts zu überleben; Sie brauchen einen verschlüsselten Export, den Sie kontrollieren, und eine Passphrase, die nur Sie kennen.

Bleibt die Frage der Passkeys, denn man wird sie Ihnen als die universelle Antwort verkaufen. Ein Passkey ist FIDO2 unter einem Massenmarkt-Namen: dieselbe Phishing-Resistenz durch Domain-Bindung, dieselbe WebAuthn-Kryptografie. Die Nuance liegt im Speicher. Ein in iCloud oder Ihrem Google-Konto synchronisierter Passkey erbt die Sicherheit dieses Kontos — was für Ihre gewöhnlichen Konten sehr gut ist und für die Handvoll Konten fragwürdig, deren Kompromittierung genau das Szenario ist, das Sie ausschließen wollen. Für diese Konten bevorzugen Sie einen nicht synchronisierten Passkey, der auf dem Hardwareschlüssel selbst gespeichert ist, oder behalten Sie zwei physische FIDO2-Schlüssel. Für alles Übrige ist der synchronisierte Passkey ein ausgezeichneter Kompromiss aus Robustheit und Praktikabilität und dem TOTP weit überlegen.

Ein letzter Punkt, der nicht optional ist: mindestens zwei FIDO2-Schlüssel. Einer, den Sie bei sich tragen, einer als Backup an einem sicheren Ort, beide auf jedem kritischen Konto registriert. Der klassische Ausfallmodus von FIDO2 ist nicht der Angriff, es ist der Verlust des einzigen Schlüssels, der Sie aussperrt. Ein einzelner Schlüssel ist ein Single Point of Failure. Zwei Schlüssel sind Resilienz.

Was das konkret bedeutet

Für Sie als Privatperson

Kaufen Sie zwei FIDO2-Schlüssel und stellen Sie zuerst Ihre Haupt-E-Mail um — Zwei YubiKey 5 oder zwei Solo-/Token2-Schlüssel (~50–110 € das Paar je nach Modell), beide auf Ihrem Google-/Microsoft-/Proton-Konto registriert. Das ist das Root-Konto: Solange es unter „phishbarem” TOTP steht, ist alles Übrige für einen Angreifer wiederherstellbar, der Ihre MFA überwindet. Einen Schlüssel bei sich, einen zu Hause verstaut.
Kappen Sie das Cloud-Backup Ihrer TOTP-App und migrieren Sie zu lokal — Wenn Sie auf synchronisiertem Google Authenticator oder Authy sind, liegen Ihre Seeds in einer mit Ihrer Identität verknüpften Cloud. Wechseln Sie zu Aegis (Android) oder Raivo / Ente Auth (iOS), deaktivieren Sie jede automatische Synchronisierung, machen Sie ein manuelles verschlüsseltes Backup, gelagert außerhalb dieser Cloud. Kosten: null, eine Stunde Ihrer Zeit.
Legen Sie Ihre TOTP-Codes niemals in denselben Manager wie Ihre Passwörter — Wenn Ihr Cloud-Passwortmanager auch Ihre TOTP beherbergt, gibt ein einziges Leck beide Faktoren. Halten Sie sie getrennt, auf zwei Medien, die nicht zusammen fallen.

Für Sie als CISO / IT-Leitung / Geschäftsführung

1. Stellen Sie das AiTM-Kriterium als binäre Frage. Fragen Sie für jede Nutzergruppe und jede sensible Anwendung: „Widersteht diese MFA einem Adversary-in-the-Middle-Angriff in Echtzeit?” Lautet die Antwort nicht „ja, weil FIDO2 / domaingebundener Passkey”, dann ist sie nein — TOTP und genehmigbare Push fallen gegen ein im Abo gemietetes Evilginx-Kit. Direkte Konsequenz: Jedes privilegierte Konto (IAM-Admin, Finanzzugriffe, Break-Glass-Konten), das noch unter TOTP läuft, ist eine Lücke, die in Ihrem Risikoregister zu dokumentieren ist, datiert, mit einem Remediationsplan.

2. Rollen Sie FIDO2 in konzentrischen Kreisen aus, nicht per Big Bang. Beginnen Sie mit den Administratoren und den hochprivilegierten Konten, dann die exponierten Funktionen (Geschäftsführung, Finanzen, HR, Recht), dann der Rest. Stellen Sie zwei Authentifikatoren pro kritischem Nutzer bereit und deaktivieren Sie die schwachen Methoden (SMS, E-Mail-OTP) auf diesen Gruppen, sobald die Umstellung erfolgt ist. Direkte Konsequenz: Sie reduzieren die AiTM-Angriffsfläche dort, wo die Wirkung maximal ist, ohne die gesamte Organisation auf eine einzige Baustelle zu blockieren, und Sie eliminieren das Umgehen „ich falle auf die SMS zurück”, das den ganzen Nutzen annulliert.

3. Behandeln Sie die Kontowiederherstellung als das schwache Glied. Eine phishing-resistente MFA nützt nichts, wenn der Zurücksetzungsprozess seinerseits einen Anruf beim Helpdesk mit drei öffentlichen Infos akzeptiert. Dokumentieren und härten Sie die Wiederherstellungswege (starke Identitätsprüfung, zweiter Kanal, Alarm bei MFA-Zurücksetzung). Direkte Konsequenz: Sie schließen die Hintertür, durch die ein Angreifer FIDO2 umgeht, ohne es jemals anzugreifen — das ist heute der bevorzugte Vektor gegen Organisationen, die alles Übrige gut gemacht haben.

Für Sie als Geschäftsführung

Ihr CISO hat Ihnen gesagt, dass MFA überall aktiviert sei. Er hat wahrscheinlich recht. Aber „aktiviert” beantwortet nicht die einzige Frage, die zählt, und genau hier kostet das Missverständnis teuer.

Nicht alle MFA sind gleichwertig. Bei Weitem nicht. In den meisten Organisationen ist das, was ausgerollt ist, ein Code per SMS oder eine App, die sechs Ziffern anzeigt. Nicht weil es besser schützt. Weil es billiger ist, schneller zu verallgemeinern, und weil es das Audit-Kästchen abhakt. Die echte Sicherheit ist nicht in die Abwägung eingegangen. Die Kosten schon.

Hier ist, was diese beiden Methoden nicht halten. Die SMS fällt, wenn ein Angreifer Ihren Mobilfunkanbieter überzeugt, Ihre Nummer auf seine SIM-Karte zu übertragen. Eine Stunde Manipulation, und Ihre Codes landen bei ihm. Die App, die sechs Ziffern anzeigt, fällt, wenn der Angreifer mit Ihnen genau in dem Moment spricht, in dem Sie sich anmelden: Er leitet Ihren Code in Echtzeit an den echten Dienst weiter, ohne dass Sie etwas sehen. Keine dieser beiden Methoden widersteht jemandem, der es wirklich auf Sie abgesehen hat.

Der physische Schlüssel hingegen weigert sich, sich auf der falschen Seite zu authentifizieren. Nicht durch menschliches Urteil. Konstruktionsbedingt. Das ist der einzige Unterschied, der gegen einen entschlossenen Gegner hält.

Die Frage, die Sie bei Ihrem nächsten Sicherheitstermin stellen sollten: „Unsere MFA, ist das SMS, eine App oder ein physischer Schlüssel?” Und wenn die Antwort die drei mischt, fragen Sie, welche Ihre eigenen kritischen Konten schützen und die Ihrer Finanzleitung.

Der Test ist nicht, ob MFA aktiviert ist. Jeder antwortet ja auf diese Frage, und jeder liegt falsch damit, sich darauf zu verlassen. Der Test ist, ob sie jemandem standhält, der wirklich hineinwill.

Fehler, die man ständig sieht

Seine TOTP-Seeds in der Cloud des Kontos synchronisieren, das sie schützen. Google Authenticator auf Drive gesichert, Authy per SMS verriegelt: Der zweite Faktor ist nicht mehr unabhängig vom ersten. Eine Kompromittierung, alles fällt.
Glauben, TOTP stoppe Phishing. Es stoppt den später abgespielten Passwortdiebstahl. Es tut nichts gegen einen AiTM-Reverse-Proxy, der Ihren Code in Echtzeit weiterleitet. Die Unterscheidung ist der ganze Unterschied.
Passwörter und TOTP im selben Cloud-Manager mischen. Praktisch, und genau das ist das Problem: Faktor 1 und Faktor 2 im selben Korb, ein einziges Leck gibt beide.
Ein einziger FIDO2-Schlüssel, ohne Backup. An dem Tag, an dem Sie ihn verlieren, sind Sie ausgesperrt — oder schlimmer, Sie öffnen im Notfall „für die Übergangszeit” eine schwache Methode wieder und schließen sie nie wieder.
FIDO2 auf den kritischen Konten aktivieren, aber die SMS als Rückfall lassen. Ein Angreifer greift nicht Ihren Schlüssel an: Er nimmt die schwächste noch verfügbare Option. Solange der schwache Rückfall existiert, nützt FIDO2 nichts.
Den Wiederherstellungsweg vergessen. Sie haben die Anmeldung gehärtet, nicht das Zurücksetzen. Der Helpdesk, der eine MFA auf drei öffentliche Infos hin neu umstellt, annulliert die ganze Arbeit.

Umsetzbare Checkliste

N1 Die kritischen Konten auflisten (Haupt-E-Mail, Bank, Passwortmanager, Admin-Konsolen)
N1 Das Cloud-Backup/die Synchronisierung der bestehenden TOTP-App deaktivieren
N1 Das TOTP zu einer lokalen App ohne Cloud-Sync migrieren (Aegis, Raivo, Ente Auth)
N2 Zwei FIDO2-Schlüssel kaufen und beide auf der Haupt-E-Mail registrieren
N2 Passwörter und TOTP-Seeds physisch trennen (verschiedene Medien)
N2 Bank und Passwortmanager auf FIDO2 umstellen, sobald verfügbar
N3 SMS und E-Mail-OTP als Rückfall auf den auf FIDO2 umgestellten Konten deaktivieren
N3 Einen FIDO2-Ersatzschlüssel bereitstellen, gelagert außerhalb des Hauptwohnsitzes
N3 Die Kontowiederherstellungswege auditieren und härten (starke Identitätsprüfung)

Zum Weiterlesen

Die Unterscheidung zwischen „phishbarer” MFA und phishing-resistenter MFA ist keine Meinung: Sie ist schwarz auf weiß vom NIST (SP 800-63B) festgehalten und vom CISA in seinem Implementierungsleitfaden für phishing-resistente MFA detailliert beschrieben — die beiden Referenzen, die zu lesen sind, wenn Sie eine Migration intern begründen müssen. In Deutschland liefert das BSI mit seinen Empfehlungen zur Zwei-Faktor-Authentisierung den nationalen Bezugsrahmen. Um zu verstehen, was FIDO2 kryptografisch garantiert, sehen Sie sich die Spezifikationen der FIDO Alliance an; für die genaue Funktionsweise von TOTP und seine Grenzen ist die RFC 6238 kurz und lesbar. Und wenn Sie noch daran zweifeln, dass der AiTM-Angriff für einen gewöhnlichen Angreifer erreichbar ist, genügt die öffentliche Dokumentation von Evilginx, um sich ein Bild vom realen Aufwandsniveau zu machen — das heißt: gering.

Quellen und weiterführende Literatur

FIDO Alliance — Specifications [official]
RFC 6238 — TOTP: Time-Based One-Time Password Algorithm [rfc]
NIST SP 800-63B — Digital Identity Guidelines [official]
CISA — Implementing Phishing-Resistant MFA [official]
Evilginx — Reverse-Proxy für AiTM-Angriffe (öffentliche Dokumentation) [report]
BSI — Zwei-Faktor-Authentisierung [official]