Was ist Multi-Faktor-Authentifizierung (MFA)?

Multi-Faktor-Authentifizierung ist eine Anmeldeprüfung, die zwei oder mehr Nachweise unterschiedlicher Art verlangt – Wissen, Besitz oder Eigenschaft. Das Wort unterschiedlich trägt die ganze Last und wird ständig übergangen: Passwort plus Sicherheitsfrage sind zwei Nachweise aus einer Kategorie – Wissen – und damit überhaupt keine MFA. Der Sinn ist kombinatorisch: Ein abgephishtes Passwort hält nicht Ihr Telefon in der Hand; ein gestohlenes Telefon kennt nicht Ihre PIN; jeder gestohlene Faktor lässt den Angreifer eine Kategorie zu kurz kommen.

Das Wichtigste in Kürze

Wie TOTP tatsächlich funktioniert

Die Authenticator-App, entzaubert – keine Rangliste erklärt die Mechanik (RFC 6238):

Registrierung  QR-Code = otpauth://totp/app:ada?secret=JBSWY3DP…
               → die App teilt nun ein Base32-SECRET mit dem Server

Alle 30 s      beide Seiten berechnen unabhängig und offline:
               code = truncate( HMAC-SHA1( secret, floor(unix_time / 30) ) ) % 10⁶

Anmeldung      Sie tippen die 6 Ziffern der App; der Server berechnet seine eigenen,
               akzeptiert ±1 Zeitfenster für Uhrendrift → Treffer = Besitz bewiesen

So wird das in den Anmeldeablauf einer App verdrahtet:

// JavaScript / Node.js — Back4app JS SDK
// TOTP step-up with the Parse Server mfa auth adapter
// Enroll: prove possession by sending one valid code with the secret
await currentUser.save({
  authData: { mfa: { secret: totpSecret, token: codeFromApp } },
});
// server returns single-use recovery codes — show once, store nowhere

// Log in afterwards: password + the current 6-digit code
const user = await Parse.User.logIn('ada', password, {
  authData: { mfa: { token: codeFromApp } },
});

// Flutter / Dart — Back4app Flutter SDK
// TOTP step-up with the Parse Server mfa auth adapter
// Enroll: prove possession by sending one valid code with the secret
currentUser.set('authData', {
  'mfa': {'secret': totpSecret, 'token': codeFromApp},
});
await currentUser.save();
// server returns single-use recovery codes — show once, store nowhere

// Log in afterwards: password + the current 6-digit code
final user = ParseUser('ada', password, null)
  ..set('authData', {'mfa': {'token': codeFromApp}});
await user.login();

// iOS / Swift — Back4app Swift SDK
// TOTP step-up with the Parse Server mfa auth adapter
// Enroll: prove possession by sending one valid code with the secret
let enrolled = try await currentUser.link("mfa",
    authData: ["secret": totpSecret, "token": codeFromApp])
// server returns single-use recovery codes — show once, store nowhere

// Log in afterwards: password + the current 6-digit code
let user = try await User.login("ada", password: password,
    authData: ["mfa": ["token": codeFromApp]])

// Android / Kotlin — Back4app Android SDK
// TOTP step-up with the Parse Server mfa auth adapter
// Enroll: prove possession by sending one valid code with the secret
val enroll = mapOf("secret" to totpSecret, "token" to codeFromApp)
ParseUser.getCurrentUser().linkWithInBackground("mfa", enroll)
// server returns single-use recovery codes — show once, store nowhere

// Log in afterwards: password + the current 6-digit code
val authData = mapOf("token" to codeFromApp)
ParseUser.logInWithInBackground("mfa", authData) // paired with the password check

MFA vs. 2FA

Eine Tabelle klärt das; die schärfere Frage lautet, welche Faktoren – denn die Sicherheitsobergrenze setzt nicht die Zahl der gestapelten Nachweise, sondern ob sich einer davon abphishen lässt.

Die Rangfolge der Methoden, ehrlich betrachtet

Der Vergleich, den die CISA-Empfehlung veröffentlicht und Anbietertexte nicht ziehen – welcher Angriff welche Methode überwindet:

Das Muster in der linken Spalte ist die moderne Geschichte: Jeder Code und jede Freigabe lässt sich über einen Phishing-Proxy weiterreichen; nur an den Ursprung gebundene Kryptografie übersteht den Kontakt mit einer gefälschten Anmeldeseite.

Die Angriffe, in einfachen Worten

Adversary-in-the-Middle-Phishing: Quelloffene Proxy-Kits setzen sich zwischen Opfer und echte Seite, reichen Passwort und Einmalcode live weiter und behalten anschließend das entstandene Session-Cookie – MFA “bestanden”, Konto verloren. Push Bombing: Mit einem gestohlenen Passwort so lange Freigabeaufforderungen schicken, bis die Erschöpfung einen Tipper gewinnt; der Zahlenabgleich (die auf dem Bildschirm gezeigten Ziffern eintippen) beseitigt den Weg des gedankenlosen Zustimmens. SIM-Swapping: einen Mobilfunkanbieter dazu bringen, die Nummer des Opfers zu übertragen, und danach dessen SMS-Codes empfangen – der Angriff, der SMS an das Ende der Tabelle gesetzt hat. Die gemeinsame Linie: Sie überwinden Faktoren, die sich jemandem mitteilen lassen; sie alle scheitern an Faktoren, die ausschließlich kryptografisch mit dem echten Ursprung sprechen.

Das Problem der Wiederherstellung

Jede MFA-Einführung schafft eine zweite Tür: Was passiert, wenn das Telefon verloren geht? Wiederherstellungscodes – einmalig verwendbar, bei der Registrierung erzeugt, offline aufbewahrt – sind die übliche Antwort; Abläufe zur Kontowiederherstellung sind die gefährliche. Wenn ein Anruf beim Helpdesk oder ein Zurücksetzen per E-Mail die MFA entfernen kann, ruft der Angreifer beim Helpdesk an – die Technik hinter Vorfällen mit Schlagzeilen – und Ihre stärkste Kontrolle wird von Ihrem schwächsten Prozess ausgehebelt. Die Regel: Die Wiederherstellung muss dieselbe oder eine höhere Sicherheit verlangen als die Anmeldung, die sie ersetzt – mehrere registrierte Methoden, Step-up-Verifizierung beim Zurücksetzen und das Entfernen der MFA als privilegiertes, protokolliertes, alarmierendes Ereignis behandelt.

Wie wirksam ist MFA wirklich?

Zwei wahre Aussagen, die oft verwechselt werden. Gegen automatisierte Angriffe – Credential Stuffing, Password Spraying – ist MFA nahezu vollständig wirksam: Die viel zitierten Neunundneunzig-Prozent-Zahlen stammen aus groß angelegter Anmeldetelemetrie, die genau diese gemessen hat, und eine begutachtete Folgearbeit fand im selben Rahmen rund 99 % weniger Kompromittierungen. Gegen gezieltes Phishing mit Echtzeit-Proxys sind code- und push-basierte MFA nachweislich umgehbar, weshalb Kritiker die Wirksamkeit über alle Angriffe hinweg weit niedriger ansetzen und Behörden heute gezielt phishing-resistente Methoden fordern. Die ehrliche Synthese: Jede MFA beendet die Ära, in der das Passwort genügte; nur MFA der Passkey-Klasse beendet das Phishing. Führen Sie irgendeine MFA überall ein und phishing-resistente MFA überall dort, wo der Einsatz die Reibung bei der Registrierung rechtfertigt.

Typische Anwendungsfälle

• Die Ausgabe von Konten schützen – MFA bewacht den Moment, in dem Sessions und Tokens geprägt werden; alles dahinter vertraut diesem Tor.
• Step-up für sensible Aktionen – erneut nachfragen bei Zahlung, Löschung oder Schlüsselexport, nicht nur bei der Anmeldung.
• Administrations- und privilegierte Konten – hier sollte MFA verpflichtend und phishing-resistent sein, ohne Ausnahmen.
• Regulatorische Vorgaben – Rahmenwerke für Zahlungsverkehr, Gesundheit und Verwaltung schreiben MFA zunehmend rundheraus vor.
• Ergänzung zu Social Login – vom Identity Provider geerbt oder lokal erzwungen für hochwertige Aktionen.

Welche MFA-Methode sollten Sie anbieten? Eine Entscheidungsmatrix

Grenzen und Trade-offs

• Die Reibung ist real und messbar. Jede Aufforderung kostet Conversion und Support-Tickets; adaptive, risikobasierte Abfragen setzen die Reibung dort ein, wo das Risiko sitzt.
• Phishbare MFA kauft weniger, als es scheint. Gegen einen gezielten Proxy-Angriff fallen Codes und Push-Freigaben; behandeln Sie sie als Bremse für Automatisierung, nicht als Phishing-Panzerung.
• Das Telefon ist ein Single Point of Failure. Geräteverlust ohne geplante Wiederherstellung wird zur Aussperrung im großen Stil – die Registrierungs-UX muss am ersten Tag Rückfallmethoden anlegen.
• Wiederherstellungsabläufe drehen die Rechnung um. Ein schwacher Weg zum Zurücksetzen deckelt Ihr gesamtes Verfahren stillschweigend auf seine eigene Stärke.
• Die Registrierung ist die Klippe der Akzeptanz. Vorgaben ohne reibungslose QR-Abläufe und klare Rückfallwege erzeugen Widerstand; das beste Verfahren ist das, das Nutzer tatsächlich zu Ende bringen.

MFA mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. TOTP kommt als Konfiguration, nicht als Bauprojekt: Der mfa-Auth-Adapter von Back4app schaltet zeitbasierte Codes über einen Konfigurationsblock frei – Stellenzahl, Periode und Algorithmus einstellbar – und die Code-Tabs zeigen die ganze Client-Geschichte: Die Registrierung beweist den Besitz, indem sie das gemeinsame Geheimnis mit einem gültigen Code paart, der Server stellt einmalig verwendbare Wiederherstellungscodes aus, und spätere Anmeldungen paaren das Passwort mit den aktuellen sechs Ziffern. Weil die Sessions der Plattform serverseitig widerrufbar sind, hält auch die umgebende Hygiene: Eine MFA-Änderung kann andere Sessions sofort beenden, und Cloud-Code-Trigger sind der natürliche Ort, um Registrierungsereignisse zu protokollieren und das Entfernen der MFA hinter Step-up-Prüfungen zu stellen – die Disziplin bei der Wiederherstellung, für die dieser Artikel plädiert, ausgedrückt in wenigen Funktionen.