Ein geleaktes Passwort, das an mehreren Stellen im Einsatz war, hat gereicht, um einen Account zu übernehmen. Mit diesem Fall aus dem echten Leben beginnt die neue Folge von „Sofa Talk und IT“, in der ich mit Marcus Bohn über Zwei-Faktor- und Multifaktor-Authentifizierung spreche.
Im Podcast geht es um die Grundlagen, um Phishing und um die Methoden vom Authenticator bis zum Hardware-Token. In diesem Beitrag gehe ich einen Schritt weiter und kümmere mich um die Einführung selbst: welche Methode zu welchem Zugang passt, wie Sie MFA ausrollen und was passiert, wenn der zweite Faktor einmal ausfällt.
Die Folge gibt es auch auf Spotify.
2FA ist eine Form von MFA
Zwei-Faktor-Authentifizierung, kurz 2FA, verlangt bei der Anmeldung zwei unterschiedliche Faktoren. Multifaktor-Authentifizierung, kurz MFA, ist der Oberbegriff für jede Anmeldung mit mehr als einem Faktor.
Die Faktoren stammen aus verschiedenen Kategorien. Etwas, das eine Person weiß, ist zum Beispiel ihr Passwort. Etwas, das sie besitzt, kann ein Smartphone oder ein Security Key sein, also ein kleiner Schlüssel für den USB-Anschluss. Dazu kommen biometrische Merkmale wie der Fingerabdruck.
Ausführlicher stehen die Grundlagen im Beitrag „2FA für Unternehmen: Warum Zwei-Faktor-Authentifizierung heute Pflicht ist“. Für die Einführung zählt vor allem, dass zwei Verfahren mit dem Etikett MFA sehr unterschiedlich gut schützen können.
Nicht jede MFA schützt gleich gut vor Phishing
Ein Passwort mit zweitem Faktor schützt deutlich besser als ein Passwort allein. Zwischen den Verfahren gibt es trotzdem Unterschiede, und die zeigen sich vor allem beim Phishing. Angreifer haben es längst nicht mehr nur auf Passwörter abgesehen. Eine gefälschte Anmeldeseite kann auch den Einmalcode abfragen, den jemand gerade aus seiner App abgetippt hat, und ihn sofort beim echten Dienst eingeben.
Die US-Standardisierungsbehörde NIST trennt deshalb in ihrer Richtlinie SP 800-63B zwischen MFA und phishing-resistenter Authentifizierung. Manuell eingegebene Einmalcodes gelten dort nicht als phishing-resistent. Anders ist es bei den offenen Standards FIDO2 und WebAuthn. Dort bestätigt ein Schlüssel auf dem Gerät die Anmeldung kryptografisch, und zwar nur für die Adresse des echten Dienstes. Auf einer gefälschten Seite funktioniert er nicht.
Eine Authenticator-App bleibt trotzdem eine gute Wahl. Für die meisten Konten halte ich sie für einen praktikablen Schritt. Bei Administratorkonten und anderen kritischen Zugängen würde ich aber prüfen, ob ein stärkeres Verfahren machbar ist.
Das BSI empfiehlt ebenfalls, die Zwei-Faktor-Authentisierung zu nutzen, sobald ein Dienst sie unterstützt, und hebt das hohe Sicherheitsniveau hardwaregestützter Verfahren hervor.
Welche MFA-Methode passt, hängt vom Zugang ab
Eine Methode, die in jedem Unternehmen die beste ist, gibt es nicht. Es kommt auf den Schutzbedarf des Zugangs an und darauf, welche Geräte die Benutzer haben.
| Methode | Sicherheit | Alltagstauglichkeit | Typische Einsatzbereiche |
|---|---|---|---|
| E-Mail-Code | Basis bis mittel | sehr einfach | eher als Übergangs- oder Fallback-Lösung |
| SMS-Code | mittel | einfach | Anwendungen mit begrenzter Methodenauswahl |
| Authenticator-App (TOTP) | mittel | sehr gut | breite Nutzung bei Mitarbeitern und Standardanwendungen |
| Hardware-Token (Security Key) | hoch bis sehr hoch | gut, zusätzliche Hardware nötig | privilegierte und besonders sensible Zugänge |
| FIDO2/WebAuthn bzw. moderne kryptografische Verfahren | sehr hoch, je nach Umsetzung phishing-resistent | nach Einrichtung komfortabel | besonders schützenswerte Accounts und moderne Identity-Umgebungen |
Die Tabelle zeigt die technische Seite. Ob sich eine Methode im Unternehmen durchsetzt, hängt oft an ganz praktischen Fragen, etwa daran, ob jemand ein Diensthandy hat.
Der passende Faktor hängt auch von den Mitarbeitern ab
Nehmen wir die Authenticator-App. Hat jeder Mitarbeiter ein Firmen-Smartphone, ist sie schnell eingeführt. Stellt das Unternehmen keine Diensthandys, müsste die App auf private Geräte. Technisch geht das meistens problemlos. Wer sein privates Smartphone nicht für die Arbeit nutzen möchte, hat dafür aber gute Gründe, und das Unternehmen muss das akzeptieren.
Leichter wird es, wenn eine Anwendung mehrere MFA-Methoden unterstützt. Dann muss nicht jeder denselben Faktor verwenden. Der Großteil der Belegschaft arbeitet zum Beispiel mit der Authenticator-App, und wer kein Smartphone einsetzen will, bekommt einen Hardware-Token. So wird aus MFA keine Grundsatzdebatte über private Geräte.
Authenticator-App heißt nicht automatisch Microsoft Authenticator
Ein verbreitetes Missverständnis betrifft die App selbst. Bei zeitbasierten Einmalpasswörtern, kurz TOTP, berechnet die App aus einem hinterlegten Geheimnis und der aktuellen Uhrzeit in der Regel alle 30 Sekunden einen neuen Code. Das Verfahren ist ein offener Standard (RFC 6238). Eine Anwendung, die TOTP unterstützt, ist deshalb grundsätzlich an keine bestimmte Authenticator-App gebunden. Auch Microsoft beschreibt OATH-TOTP als offenen Standard, der sich mit Software- oder Hardware-Token umsetzen lässt.
Bei der Produktauswahl lohnt es sich, auf die unterstützten Standards zu achten und darauf, ob unterschiedliche Benutzergruppen unterschiedliche Methoden nutzen können.
Die Einführung beginnt mit den Risiken
Oft wird zuerst ein Werkzeug ausgewählt und erst danach überlegt, wo es eingesetzt werden soll. Ich empfehle die umgekehrte Reihenfolge in sechs Schritten.
1. Kritische Zugänge erfassen
Am Anfang steht die Frage, welche Accounts bei einer Übernahme den größten Schaden anrichten würden. Das sind meist E-Mail- und Microsoft-365-Konten, Cloud-Plattformen, VPN-Zugänge, der Passwortmanager, administrative Accounts und Anwendungen mit Kunden-, Mitarbeiter- oder Zahlungsdaten. Nicht jeder dieser Accounts braucht dasselbe Schutzniveau, entsprechend kann auch der zweite Faktor unterschiedlich ausfallen.
2. Benutzergruppen betrachten
Ein Administrator braucht etwas anderes als jemand im Büro. Im Außendienst sieht die Anmeldung wieder anders aus als an einem Terminal, das sich mehrere Kollegen teilen. Schreiben Sie deshalb neben den Anwendungen auch diese Benutzergruppen auf, oft Personas genannt. Daraus ergibt sich später, welcher Faktor für wen infrage kommt.
3. Verfügbare MFA-Methoden prüfen
Manche Anwendungen unterstützen nur ein Verfahren, dann ist die Entscheidung schnell getroffen. Gibt es mehrere, wägen Sie Schutz, Bedienung, Kosten und den Aufwand für die Verwaltung gegeneinander ab.
4. Mit einer Pilotgruppe starten
Ein neues Anmeldeverfahren schaltet man nicht am Freitagabend für das ganze Unternehmen scharf. Eine kleine Pilotgruppe zeigt früh, ob die Registrierung klappt, ob die Anleitungen verständlich sind und bei welchen Geräten oder Anwendungen es hakt.
5. Recovery vor dem Rollout planen
Dieser Schritt fällt am häufigsten unter den Tisch. Vor dem Rollout sollte feststehen, was bei einem verlorenen Smartphone oder einem defekten Hardware-Token passiert und wer einen Faktor zurücksetzen darf. Dazu gehört auch, wie der Helpdesk prüft, dass am Telefon die Person anruft, der das Konto gehört. Solange das offen ist, ist die Einführung nicht fertig geplant.
6. MFA verbindlich machen
Wenn der Pilot gut gelaufen ist und die Notfallwege feststehen, wird MFA für die betroffenen Anwendungen Pflicht. Solange es nur ein Angebot bleibt, sind genau die Konten ungeschützt, deren Besitzer es nicht einschalten.
Auch der zweite Faktor kann ausfallen
Der zweite Faktor soll Angreifer draußen halten. Im ungünstigen Fall sperrt er aber auch die eigenen Mitarbeiter aus. Bei zeitbasierten Codes reicht es schon, wenn die Uhren von Smartphone und Server auseinanderlaufen. Dann lehnt das System Codes ab, die völlig korrekt aussehen. Genauso kann ein Smartphone verloren gehen oder der Hardware-Token zu Hause liegen.
Zu jeder MFA-Einführung gehört deshalb ein Recovery-Konzept, also ein festgelegter Weg, wie jemand wieder an sein Konto kommt. Das BSI empfiehlt, wenn möglich mehrere zweite Faktoren oder andere Wiederherstellungswege einzurichten. Im Unternehmen sollten außerdem vier Punkte geregelt sein:
Es ist festgelegt, wer einen zweiten Faktor zurücksetzen darf und welchen Identitätsnachweis der Helpdesk dafür verlangt.
Für kritische Systeme gibt es einen kontrollierten Ersatzweg, falls der übliche Faktor ausfällt.
Administratorkonten haben den stärksten Schutz und trotzdem einen Weg, über den das Unternehmen im Notfall handlungsfähig bleibt.
Der Notfallweg wurde mindestens einmal durchgespielt. Ein Recovery-Prozess, den bisher nur die Dokumentation kennt, ist nicht erprobt.
Administratoren brauchen einen eigenen Notfallweg
Bei zentralen Anwendungen wird das besonders deutlich. Ein Beispiel: Der Passwortmanager eines Unternehmens ist für alle Benutzer mit derselben MFA-Methode geschützt, und genau diese Methode fällt aus. Jetzt kommen weder die Mitarbeiter noch der Administrator hinein. Das Konto, mit dem sich das Problem lösen ließe, hängt am selben Fehler wie alle anderen.
Für solche Systeme lohnt sich ein streng kontrollierter Notfallzugang für Administratoren, der einen anderen Authentifizierungsweg nutzt. In Identity-Umgebungen heißt das oft Emergency- oder Break-Glass-Konto, nach der Glasscheibe, die man im Notfall einschlägt.
Weniger geschützt ist der Administrator dadurch nicht. Der Notfallzugang wird besonders abgesichert und überwacht, und er ist nur für vorher festgelegte Situationen gedacht.
Zu viel Aufwand beim Login schwächt die Sicherheit
MFA kostet bei jeder Anmeldung ein paar Sekunden, das lässt sich nicht wegdiskutieren. Kritisch wird es, wenn die Anmeldung so umständlich wird, dass Mitarbeiter eigene Wege suchen.
Ist der Zugang zum Passwortmanager unnötig mühsam, steht das Passwort irgendwann wieder in einer Excel-Datei oder auf einem Zettel. Auf dem Papier gibt es dann mehr Schutz, in der Praxis weniger.
Benutzerfreundlichkeit gehört deshalb zur IT-Sicherheit dazu. Ich halte ein Schutzniveau für richtig, das zum Risiko des Zugangs passt und das die Leute auch jeden Tag benutzen. Mehr Anmeldeschritte als nötig bringen niemandem etwas.
Phishing zeigt, warum MFA nur ein Teil der Lösung ist
Im Podcast sprechen Marcus und ich auch darüber, dass Phishing-Mails deutlich professioneller geworden sind. Das beobachten wir beide. Gefälschte Rechnungen kommen mit Briefkopf, Signatur und plausiblem Absender. Die Paket-SMS trifft genau dann ein, wenn man gerade eine Lieferung erwartet. Und Rechtschreibfehler, an denen man Betrugsversuche früher schnell erkannt hat, sind längst kein verlässliches Merkmal mehr.
Kein Unternehmen sollte sich darauf verlassen, dass seine Mitarbeiter jeden Angriff erkennen. MFA legt eine zusätzliche technische Schutzschicht über das Passwort. E-Mail-Security, Security Awareness und klare Meldewege ersetzt sie nicht.
Wie moderne Phishing-Mails aussehen und wie Sie damit umgehen, beschreibt der Beitrag „Phishing-Mails erkennen: So schützen Sie sich vor digitalen Betrugsversuchen“. Dazu kommen regelmäßige Awareness-Maßnahmen, damit die Mitarbeiter wissen, woran sie einen Angriff erkennen und wem sie ihn melden.
Privilegierte Zugänge kommen zuerst an die Reihe
Sie müssen nicht alle Anwendungen an einem Tag umstellen. Fangen Sie dort an, wo eine Übernahme den größten Schaden anrichten würde:
privilegierte und administrative Zugänge
E-Mail und Microsoft 365
Passwortmanager und Identity-Systeme
VPN- und Remote-Zugänge
Cloud-Plattformen
Systeme mit Kunden-, Mitarbeiter- oder Finanzdaten
Danach weiten Sie MFA Schritt für Schritt auf die übrigen Anwendungen aus. Auf lange Sicht sollte überall dort, wo eine Anwendung einen zweiten Faktor unterstützt, dieser auch eingeschaltet sein.
Meine Empfehlung für den Start
Wenn Sie MFA einführen, würde ich mit der Liste der Zugänge beginnen, deren Übernahme am meisten Schaden anrichten würde. Legen Sie für jeden davon fest, welcher Faktor passt, und denken Sie dabei an die Mitarbeiter ohne Diensthandy.
Bevor die Pilotgruppe startet, sollte der Recovery-Prozess stehen und einmal durchgespielt sein, auch für den Notfallzugang der Administratoren. Und verlassen Sie sich nicht darauf, dass „MFA aktiviert“ vor jeder Form von Phishing schützt. Für die kritischsten Konten würde ich mir FIDO2 genauer ansehen.
Die komplette Podcastfolge ansehen oder anhören
In Folge 11 von „Sofa Talk und IT“ sprechen Marcus Bohn und ich knapp eine Stunde lang über Passwort-Leaks, Phishing und die verschiedenen zweiten Faktoren. Es geht auch um die Frage, ob die Authenticator-App auf das private Smartphone gehört, und um die praktische Umsetzung im Unternehmen.
Häufige Fragen zur Multifaktor-Authentifizierung
Bei der Zwei-Faktor-Authentifizierung werden genau zwei unterschiedliche Authentifizierungsfaktoren kombiniert. Multifaktor-Authentifizierung ist der übergeordnete Begriff für Verfahren mit mehreren Faktoren. 2FA ist damit eine Form von MFA.
Das hängt vom Schutzbedarf und vom Anwendungsfall ab. Für viele Standardanwendungen ist eine Authenticator-App ein guter Kompromiss aus Schutz und Bedienbarkeit. Für besonders sensible oder privilegierte Zugänge eignen sich phishing-resistente Verfahren wie FIDO2 mit einem passenden Security Key.
In der Regel ja. Ein Code aus einer Authenticator-App lässt sich nicht wie eine SMS über eine übernommene Rufnummer umleiten. Deshalb ist TOTP für viele Unternehmensanwendungen die bevorzugte Wahl. Gegen Echtzeit-Phishing schützen allerdings erst phishing-resistente Verfahren wie FIDO2.
Nein. Nicht jedes MFA-Verfahren ist phishing-resistent. Vor allem manuell eingegebene Einmalcodes können bei Echtzeit-Phishing abgefangen und sofort weiterverwendet werden. Verfahren auf Basis von FIDO2 und WebAuthn verhindern solche Angriffe technisch, weil sie die Anmeldung an die Adresse des echten Dienstes binden.
Dafür sollte schon vor der Einführung ein Recovery-Prozess festgelegt sein. Je nach Anwendung setzt ein Administrator den Faktor zurück, der Benutzer weicht auf einen zweiten hinterlegten Faktor aus oder nutzt einen sicher verwahrten Wiederherstellungscode. Diese Wege sollten dokumentiert und einmal durchgespielt sein.
Voraussetzen sollte ein Unternehmen das nicht. Gibt es keine Dienstgeräte oder möchten Mitarbeiter ihr privates Smartphone nicht beruflich nutzen, kommen andere Methoden wie ein Hardware-Token infrage.
Viele professionelle Anwendungen unterstützen das. So kann der Großteil der Mitarbeiter eine Authenticator-App nutzen, während einzelne Kollegen einen Hardware-Token bekommen.
Wir begleiten Sie bei der Einführung
Wenn Sie MFA einführen oder Ihre bestehende Einrichtung prüfen lassen möchten, unterstützen wir bei aconitas Sie dabei. Gemeinsam ermitteln wir die kritischen Zugänge, wählen passende Authentifizierungsmethoden aus und planen die Umsetzung so, dass sie zu den Abläufen in Ihrem Unternehmen passt.
