Zwei-Faktor-Authentisierung

Zwei-Faktor-Authentisierung (2FA) bzw. Multi-Faktor-Authentisierung (MFA) ist in aller Munde und längst nicht mehr nur ein Thema für “Geeks und Nerds”. Die Stiftung Warentest empfiehlt¹ ihren Lesern 2FA/MFA zu aktivieren, falls es angeboten wird, ebenso das BSI². Auch diverse Computerspiele-Publisher winken mit extra In-Game-Belohnungen^{3, 4}, wenn man seinen Account mit 2FA/MFA extra absichert.

Ergänzend zum letzten Blogbeitrag vom 16. Juni wollen wir daher einige der verschiedenen gängigen Formen von Zwei-Faktor-Authentisierung bzw. Multi-Faktor-Authentisierung etwas genauer beleuchten und auch auf mögliche Probleme bei der Verwendung hinweisen. Dabei orientieren wir uns in Teilen grob an den Ergebnissen eines Proof-of-Concepts an der Julius-Maximilians-Universität Würzburg, der mit dem Ziel, für die Absicherung hochprivilegierter administrativer Konten eine möglichst sichere und trotzdem nutzerfreundliche Kombination zu finden, durchgeführt wurde. Der Fokus, mit dem diverse Verfahren und Tokentypen getestet wurden, lag dabei auf Einmalpasswörten in Verbindung mit privacyIDEA⁵ als Backend.

Kurze Rekapitulation

Insgesamt unterscheidet man drei Faktoren, die zur Authentisierung an z.B. einem Computersystem genutzt werden können:

• über Wissen, z.B. die Kenntnis des richtigen Passworts
• über Besitz, z.B. der Besitz einer notwendigen Smartcard
• über ein körperliches Merkmal, z.B. der eigene, im System hinterlegte Fingerabdruck

Die meisten von uns werden sicherlich bereits jeden dieser drei Faktoren genutzt haben. Ein Passwort zu verwenden ist alltäglich, an die TAN-Liste für das Online-Banking werden sich auch noch die meisten erinnern können und nicht wenige entsperren ihre mobilen Geräte wie Handys und Tablets mittels Fingerabdruck oder Face-ID.

Durch die Kombination von zwei oder auch mehr dieser Faktoren wird die Anmeldung an einem System oder Dienst zusätzlich abgesichert und man spricht dann von Zwei- bzw. Multi-Faktor-Authentisierung. Damit durch Zwei-Faktor-Authentisierung ein Sicherheitsgewinn erzielt werden kann, ist es unabdingbar, unterschiedliche Faktoren und Übertragungskanäle miteinander zu kombinieren. Dadurch erschwert man es einem potentiellen Angreifer, alle Faktoren in seinen Besitz zu bringen.

Teilweise wird der zweite Faktor während des Anmeldevorgangs vom Diensteanbieter über eine separaten Übertragungskanal an den Benutzer gesendet, z.B. als SMS, oder aber der zweite Faktor wird basierend auf zuvor zwischen Sender und Empfänger vereinbarten und geheimen Schlüsseln beim Benutzer selbst berechnet. Zum Erzeugen der jeweiligen zusätzlichen Faktoren auf Seite der Benutzer gibt es eine Vielzahl an Lösungen, sowohl software- als auch hardwarebasiert. Jeder Lösungsansatz bringt dabei unterschiedliche Vorteile, Nachteile und auch Angriffspotentiale mit.
Der Mehraufwand durch Zwei-Faktor-Authentisierung, der auf Seiten der Anwender sowie bei den Dienst- und Systembetreibern oder dem IT-Support entsteht, sollte ebenfalls nicht unterschätzt werden. Die beste Maßnahme bringt nichts, wenn sie zu unbequem ist und nicht angenommen wird.

Letztendlich muss man sich daher immer im Klaren darüber sein, dass Zwei-Faktor-Authentisierung neben dem reinen Sicherheitsgewinn auch die Komplexität des Authentifizierungsvorgangs erhöht und, wie uns die Vergangenheit gelehrt hat, durchaus ausgehebelt bzw. umgangen werden kann. Darauf gehen wir bei den jeweiligen Methoden und Token bzw. in einem extra Abschnitt näher ein.

Einmalpasswörter / One-Time-Password

Das Einmalpasswort, oder auch One-Time-Password (OTP), ist die am weitesten verbreitete Methode zur Absicherung von Zugängen mit einem zweiten Faktor. Sie begegnen uns in diversen Formen, Komplexitäten und Längen. Auch bei der Auswahl des Kanals über den der zweite Faktor bereitgestellt wird, gibt es mehrere Optionen.

Damals™: Transaktionsnummern

Die oben bereits erwähnte TAN-Liste enthält vorgefertigte Transaktionsnummern, also Einmalpasswörter, die einmalig gültig sind, nach Benutzung nicht erneut verwendet werden können und zusätzlich zur PIN genutzt werden müssen. Somit stellen die TANs einer TAN-Liste einen zweiten Faktor dar.

TAN-Listen untereinander lassen sich wiederum unterscheiden zwischen den klassischen Listen bei der TANs in beliebiger Reihenfolge genutzt werden konnten, Listen mit TANs die der Reihe nach genutzt werden müssen und solchen, bei denen die authentifizierende Gegenstelle (z.B. die Bank) vorgibt, welche der durchnummerierten TANs eingegeben werden muss, den sogenannten indizierten TAN Listen (iTAN). Diese iTANs wurden eingeführt, um Phishing-Angriffen zu begegnen, bei denen ein Angreifer sein Opfer dazu verleiten wollte, eine oder gleich mehrere TANs der Liste einzugeben, um diese anschließend selber nutzen zu können. Zusätzlich erleichterten iTANs auch den Umgang mit TAN-Listen, da man sich nicht mehr selber um das Markieren bereits genutzter TANs kümmern musste, den Überblick darüber behielt die Bank.

Der große Nachteil besonders der iTAN-Listen ist, dass sie immer eine relativ große Anzahl potentiell gültiger Einmalpasswörter enthält, die für jeden Authentifizierungsvorgang mitgeführt werden muss und damit auch als Ganzes verloren oder, noch schlimmer, ausgespäht bzw. kopiert werden kann. Somit haben wir hiermit schon die ersten Beispiele für das Ausspähen und Umgehen von 2FA als auch die erhöhten Komplexität durch 2FA vor uns.

Mit Einführung der SMS-TAN bzw. mTAN wurde das Verfahren in der Handhabung für die Nutzer etwas vereinfacht und sicherer gestaltet. Zum einen musste keine TAN-Liste mitgeführt und angemessen geschützt werden und zum anderen wurden beim Übermitteln der nur zeitlich begrenzt gültigen TAN in der SMS auch weitere Informationen der geplanten Transaktion mitgeschickt, die der Anwender kontrollieren konnte. Man benötigte also lediglich Zugriff auf sein Mobilgerät und Mobilfunkempfang. Letzteres kann in Deutschland natürlich bisweilen immer noch problematisch sein.

Seit der generellen Verfügbarkeit von Smartphones, die im Gegensatz zu Mobiltelefonen ohne Netzwerk- bzw. Internetzugang anfälliger für Schadsoftware und Angriffe sind, verlor die mTAN zumindest im Banking-Bereich immer mehr an Bedeutung. Viele Banken nutzen für den zweiten Faktor mittlerweile chipTAN, eigene Apps mit pushTAN oder auch spezielle Hardware-Token. Die mTAN wird hingegen oft nur noch beim erstmaligen Registrieren eines zweiten Faktors einmalig genutzt.
Weit verbreitet ist das Zusenden einer TAN per SMS allerdings immer noch z.B. bei der Registrierung eines Online-Kontos bei diversen Dienstbetreibern oder bei der Anmeldung an einem bestehenden Onlinekonto von einer neuen IP, einem neuen Ort bzw. mit einem neuen Browser.

HMAC-based One-Time Password (HOTP) und Time-based One-Time Password (TOTP)

HMAC-based One-Time Password (HOTP) bzw. Time-based One-Time Password (TOTP) sind heutzutage die de-facto Standards wenn es um 2FA geht. Eine Vielzahl von Dienst- und Webseitenbetreibern unterstützen diese OTP-Verfahren. Der Benutzer benötigt ein entsprechendes Token, welches die Einmalpasswörter erzeugt. Solche Token gibt es entweder als extra Hardware oder als Software-Token für jedes erdenkliche Betriebssystem. Durchsuchbare Verzeichnisse unterstützter Dienste, Verfahren und Tokentypen werden u.a. von Yubico⁶ und Nitrokey⁷, zwei Herstellern von Hardware-Token, bereitgestellt.

Bei HOTP, beschrieben in RFC 4226⁸, wird mittels einer kryptografischen Hashfunktion (HMAC-SHA-1) ein in der Regel sechsstelliges OTP anhand eines shared secrets, des Seeds, und eines moving factors, dem Counter, erzeugt. Der Counter wird nach jeder Authentifizierung sowohl beim Sender als auch beim Empfänger um eins inkrementiert und so auch ein neues OTP generiert. Man spricht bei HOTP daher auch von einem ereignisbasierten Verfahren, da der Anwender zum Hochzählen des Counters und Erzeugen eines neuen OTPs in der Regel einen Knopf drücken muss.

TOTP, beschrieben in RFC 6238⁹, ist im Wesentlichen eine Erweiterung von HOTP. Statt eines inkrementellen Counters werden als moving factor ein Zeitstempel in Sekunden (Unixzeit) und eine Schrittweite, ebenfalls in Sekunden, genutzt. So generieren Sender und Empfänger üblicherweise alle 30 Sekunden (Schrittweite) ein neues, auch hier in den meisten Fällen sechsstelliges, OTP. Optional kann statt des für HOTP definierten HMAC-SHA-1 bei TOTP auch eine auf SHA2 basierende Hashfunktion, in der Regel HMAC-SHA-256 bzw. HMAC-SHA-512, genutzt werden.

Der Austausch des Seeds sowie der weiteren Parameter erfolgt in der Regel per QR-Code. Der authentisierende Server bzw. das dahinterliegende Backend für die Mehrfaktorauthentisierung generiert einen zufälligen Seed und erzeugt den QR-Code, der vom Anwender eingescannt wird.

Wenn Dienstbetreiber ihren Benutzern Zwei-Faktor-Authentisierung anbieten, wird heutzutage in den allermeisten Fällen TOTP genutzt. Im folgenden Beispiel wird der Account “alice” in einem Gitea mit Zwei-Faktor-Authentisierung abgesichert. Als Verfahren kommt TOTP zum Einsatz und zum Erzeugen der Einmalpasswörter auf Benutzerseite wird die App “andOTP” unter Android benutzt.

Nachdem in den Sicherheitseinstellungen des Accounts “Zwei-Faktor-Authentisierung aktivieren” ausgewählt wurde, wird vom Server der Seed erzeugt und zusammen mit weiteren Parametern als QR-Code zum Einscannen angezeigt.

Hier wird für den Fall, dass man z.B. einen manuell einzurichtenden Hardware-Token ohne Kamera nutzt, zusätzlich zum QR-Code, noch der Base32 codierte Seed angezeigt. Nachdem der QR-Code eingescannt wurde, soll als abschließender Test direkt ein generiertes Einmalpasswort eingegeben werden. So will man verhindern, dass Zwei-Faktor-Authentisierung aktiviert wird ohne sicher zu sein, dass der Import des Seeds auch erfolgreich war.

Nach erfolgreichem Test wird noch ein Einmalpasswort angezeigt, mit dem sich ein Benutzer einloggen kann, falls er sein eigentliches Token nicht zur Hand hat. Dies wird allerdings von Dienst zu Dienst unterschiedlich gehandhabt. Manche Dienste erzeugen direkt mehrere Einmalpasswörter, ähnlich einer kurzen TAN-Liste, und hinterlegen diese ebenfalls auf dem validierenden Server als zusätzlichen zweiter Faktor, andere hingegen erzeugen schlicht keinerlei Notfallcodes. Erstellte Notfallcodes sollten natürlich möglichst sicher und getrennt von Username und Passwort aufbewahrt werden.

Die generierten QR-Codes sind nach folgendem Muster aufgebaut: otpauth://type/label?parameters. Im oben abgebildeten QR-Code sind folgende Informationen enthalten:

otpauth://totp/Gitea%20%28git.jmu-cert.de%29:alice?algorithm=SHA1&digits=6&issuer=Gitea+%28git.jmu-cert.de%29&period=30&secret=HWTFLMZF4Y6DXTA3AVZDK66BNVXG6JUSHNP6S3IBCRWYXIUVRKSG37XFQ2SBD6ON

Als type wird wie erwartet totp angegeben. Das darauf folgende Gitea%20%28git.jmu-cert.de%29:alice ist das label, dient der Zuordnung zu einem Account und wird im andOTP-Screnshot entsprechend angezeigt. Die nun folgenden Parameter sind, bis auf secret, welcher den Seed enthält, alle optional. Werden algorithm, digits und period weggelassen, wird automatisch der Standard HMAC-SHA-1 mit 6 Stellen und 30 Sekunden Schrittweite angenommen. Der issuer definiert zusätzlich noch einmal den Dienst, zu dem der Seed gehört.

Sowohl bei HOTP als auch bei TOTP besteht die Gefahr, dass der jeweilige moving factor, also der Counter bzw. die Zeit, bei Sender und Empfänger auseinanderlaufen. Dies geschieht z.B. wenn auf einem HOTP-Token der Knopf zum Erzeugen eines neuen OTPs und Hochsetzen des Counters gedrückt wird, ohne die erzeugten OTPs zu nutzen. Bei einem TOTP-Token ohne Zeitsynchronisation wird früher oder später die Systemzeit nicht mehr mit der des validierenden Servers übereinstimmen. In engem Rahmen sind solche Abweichungen bei HOTP und TOTP bereits einkalkuliert, so dass der Empfänger in der Regel auch benachbarte OTPs zusätzlich zu dem von ihm erwarteten OTP akzeptiert. Beispielsweise wäre eine um 89 Sekunden abweichende Uhrzeit zwischen Sender und Empfänger noch im Rahmen, wenn der Empfänger ± zwei Schrittweiten akzeptieren würde: 29 Sekunden aus dem aktuellen Zyklus und 2x 30 Sekunden Toleranz. Bei Abweichungen über den konfigurierten Toleranzbereich hinaus müssen Sender und Empfänger neu synchronisiert werden. Sollte dies nicht möglich sein, muss dem Benutzer ein neues Token ausgegeben werden.

Yubico OTP

Yubico, der Hersteller der YubiKeys, auf die wir später noch zu sprechen kommen, hat mit Yubico OTP¹⁰ ein eigenes auf AES basierendes OTP-Verfahren entwickelt. Im Zusammenspiel mit einem YubiKey als Hardware-Token wird hierbei ein 44 Stellen langes Einmalpasswort generiert. Zur Nutzung von Yubico OTP muss die abzusichernde Applikation über eine extra einzubindende Softwarebibliothek mit der YubiCloud verbunden werden. Man hat allerdings auch die Möglichkeit, selber und somit autark und ohne Beteiligung einer Cloud, einen “YubiKey OTP Validation Server” zu betreiben.

Interessant wird Yubico OTP letztendlich dadurch, dass außer einem YubiKey als Token keinerlei zusätzliche Software oder Hardware mehr benötigt wird, wodurch die Zwei-Faktor-Authentisierung für die Anwender einfacher und schneller vonstatten geht. Ein YubiKey gibt sich, wenn er mit einem Gerät verbunden wird, u.a. auch als Tastatur aus. Dadurch wird das 44-stellige Yubico OTP automatisch eingegeben und bestätigt, sobald man den Kontakt am Token berührt, während sich der Cursor im entsprechenden Eingabefeld befindet. Zusätzlich lassen sich dadurch auch Restriktionen beim Zugriff über USB auf den Token umgehen, wie sie derzeit bei einigen iPads und Chrome-Books bestehen. Auf diesen Plattformen ist es momentan nicht möglich TOTP als zweiten Faktor in Kombination mit über USB angeschlossenen Hardware-Token, welcher den geheimen Seed beherbergt, zu nutzen.

Token? Token!

Sollte der zweite Faktor nicht über einen separaten Kanal wie beispielsweise eine SMS vom Anbieter zum Benutzer kommen, muss dieser in der Regel auf Seiten des Benutzers generiert werden. Dafür stehen sowohl softwarebasierte Lösungen als auch dedizierte Hardwarelösungen bereit. Welche von beiden zum Einsatz kommt hängt von verschiedenen Faktoren ab, wie z.B. der zu erwartenden Schadenshöhe durch einen kompromittierten Account, des Schutzbedarfs der abzusichernden Systeme, der “IT-Affinität” und Bereitschaft der Benutzer 2FA zu nutzen sowie der Kosten der Einführung von 2FA.

Software-Token

Am weitesten verbreitet sind sicherlich Software-Token, in der Regel als App auf dem Mobiltelefon. Der Google-Authenticator ist, wenn es sich um HOTP oder TOTP handelt, oftmals die erste Option, die genannt wird. Darüber hinaus gibt es viele Weitere wie FreeOTP, andOTP, Authy, Microsoft Authenticator oder die Nitrokey App bzw. den Yubico Authenticator im Zusammenspiel mit TOTP und Nitrokeys bzw. YubiKeys. Einige Anbieter setzen statt auf HOTP/TOTP auf Push-Nachrichten und eine User-Interaktion und stellen dafür eigene Apps bereit. Manche Apps beherrschen sowohl das eine (TOTP) als auch das andere (Push mit Interaktion).
Viele Password Manager bieten mittlerweile auch an, TOTP Seeds zu speichern um neben dem eigentlichen Passwort auch gleich das passende OTP vorhalten zu können. Ob das eine gute Idee ist, muss jedoch jeder für sich selber entscheiden.

Oftmals scheint der Sicherheitsgedanke bei Software-Apps aus Anwendersicht aber ignoriert oder zumindest nicht näher bedacht zu werden. So werden beim Google Authenticator die Seeds immer noch unverschlüsselt in einer SQLite Datenbank gespeichert. Dies freut bis heute Angreifer und Nutzer gleichermaßen, denn dadurch kann trotz fehlender offizieller Backupfunktion der App eben doch ein Backup der Seeds angelegt werden¹¹. Voraussetzung hierfür ist allerdings ein Vollzugriff auf das Handy, also ein gerootetes Endgerät¹², entweder durch den Anwender selber oder durch eine von einem Angreifer ausgenutzte Sicherheitslücke. Das letzte Release der für Android und iOS verfügbaren App FreeOTP liegt bereits über 5 1/2 Jahre zurück und unter aktuellen Android bzw. iOS Versionen hat freeOTP bereits mit Problemen zu kämpfen¹³. Nichtsdestotrotz werden beide Apps regelmäßig empfohlen.

Auch die Kompatibilität betreffend können Software-Token bisweilen überraschen. Die Microsoft Authenticator App liest z.B. klaglos einen HOTP QR-Code ein und legt einen entsprechenden Eintrag an. Leider behandelt die App den Eintrag dann allerdings nicht als HOTP sondern als TOTP mit einem Zeitintervall vom 30 Sekunden. Während der validierende Server also von einem inkrementellen Counter ausgeht, erzeugt die App fröhlich alle 30 Sekunden ein neues OTP.
Der Google-Authenticator hingegen versteht HOTP, dafür aber außer SHA-1 keine weiteren Hashfunktionen. Auch er liest ohne zu murren einen QR-Code mit „algorithm=sha256“ ein, rechnet aber still und heimlich mit SHA-1.

Software-Token sollten nur so weit als sicher betrachtet werden, wie man auch das darunterliegende Betriebssystem als sicher ansieht. Ab einem gewissen Punkt ist ein Gerät mit Android, vereinfacht gesagt, auch nur noch ein ungepatchtes Linux-System. Ebenso sollte beim Einsatz von Software-Token das zu erwartende Ausmaß des Schadens, wenn ein Account inklusive seines zweiten Faktors kompromittiert wurde, mitbetrachtet werden. Regelmäßig wird als Argument für die generelle Freigabe von Apps ein Vergleich zum Online-Banking gezogen, für das Apps ja als sicher gelten würden. Zum einem kann vermutlich die bereits 2012 von der ENISA herausgegebene Empfehlung¹⁴, alle PCs der Nutzer grundsätzlich als infiziert zu betrachten, auch 1:1 auf Mobilgeräte übertragen werden und zum anderen ist der Schaden eines kompromittierten AD-Domänen-Adminkontos ungleich höher¹⁵ und im Gegensatz zu einem geknackten, privaten Sparkassenkonto nicht versichert.

Hardware-Token

Für besonders schützenswerte Konten empfiehlt sich der Einsatz von dedizierten Hardware-Token um die Angriffsfläche weiter zu minimieren. Diese gibt es in den verschiedensten Ausprägungen und Größen und mittlerweile auch sehr günstig.

Die einfachsten Token verwenden oft HOTP bzw. TOTP, besitzen ein eigenes Display und sind bereits für wenige Euro erhältlich. Problematisch bei diesen “Key-fob” genannten Token ist, dass sie in der Regel nur ein Konto schützen können und im Fall von TOTP keinerlei Möglichkeit bieten, die Echtzeituhr auf dem Token neu zu stellen, um einem Time-Drift entgegenzuwirken. Außerdem bekommt man sie in der Regel nur preseeded, also bereits fest vorprogrammiert. Zum eigentlichen Token wird der einprogrammierte Seed auf Papier oder in einem Textfile mitgeliefert. Dieser muss dann auf dem validierenden Server eingepflegt werden und ist nicht mehr änderbar. Hier sollte man dem Anbieter der Token natürlich viel Vertrauen entgegenbringen, dass dieser zu jeder Zeit entsprechend sorgsam mit den Seeds umgeht¹⁶.

Etwas komfortablere Token können selber mit einem Seed versehen werden. Oft bieten sie auch die Möglichkeit der Zeitsynchronisation über eine spezielle Software. Dabei sollte man im Blick behalten, dass diese Funktion möglichst durch eine extra PIN geschützt wird. Ansonsten wäre es einem Angreifer, der nur kurz in den Besitz eines solchen Token kommt, möglich, die Uhr des Tokens vorzustellen, sich einige OTPs zur zukünftigen Nutzung erzeugen zu lassen, und anschließend die Zeit wieder zurückzudrehen bevor das Token zurückgelegt wird. Als Beispiel seien hier die programmierbaren Token der Schweizer Firma Token2 genannt.

Je mehr Features ein Token besitzt, um so größer und damit unhandlicher wird es in der Regel auch. Soll das Token z.B. selber durch eine PIN geschützt werden, ist zusätzlich zum Display eine kleine numerische Tastatur notwendig. Um völlig unabhängig von einer extra Software programmiert werden zu können, gibt es sogar Token wie den Reiner SCT Authenticator mit eingebauter Kamera zum Einlesen von QR-Codes. Je nach Anwendungsfall bedeutet dieses Mehr an Features und Komplexität in der Bedienung auch einen Verlust an Sicherheit und Alltagstauglichkeit. Das Token kann z.B. nicht mehr am Schlüsselbund mitgeführt werden und liegt schlimmstenfalls im unverschlossenen Büro oder Anwender boykottieren schlicht und ergreifend die Maßnahme, weil sie im täglichen Gebrauch zu sehr stört.

Eine Alternative dazu sind Token ohne Display, die per USB oder NFC angesprochen werden können und in der Regel klein und leicht genug sind, um jederzeit am Schlüsselbund mitgeführt werden zu können. Die bekanntesten Vertreter aus dieser Gruppe sind vermutlich die YubiKeys¹⁷ oder Nitrokeys¹⁸. Je nach genutztem 2FA Verfahren ist der Benutzer allerdings immer auf eine extra Software angewiesen, die die Kommunikation mit dem Token übernimmt und mit dem auf dem Token gespeicherten Seed ein Einmalpasswort erzeugt. Im Fall des Nitrokeys, der außer mehreren Speicherplätzen für TOPT und HOTP Seeds auch einen Password Store mitbringt, sowie zur Verschlüsselung mittels OpenPGP und S/MIME genutzt werden kann, gibt es diese jedoch leider nur für Desktop Betriebssysteme und nicht für mobile Endgeräte. Yubico stellt für seine YubiKeys verschiedene Softwarepakete für alle gängigen Plattformen bereit und unterstützt ebenfalls OpenPGP und S/MIME sowie zusätzlich noch FIDO U2F, FIDO2 und das oben kurz beschriebene Yubico OTP. Leider wird durch Herstellerrestriktionen (iPadOS, iOS, ChromeOS) die Nutzung von YubiKeys bei einigen Geräten nicht über USB sondern nur per NFC unterstützt.

Hardware-Token bieten oft auch zusätzliche Features, um die Sicherheit der generierten OTP zu gewährleisten. Eine PIN, die eingegeben werden muss bevor man an das OTP gelangt, hatten wir oben schon erwähnt. Dieses Feature bieten auch einige der Software-Token. Die YubiKeys können so konfiguriert werden, dass zum Anzeigen z.B. der OTPs in der Software erst der Key berührt werden muss. Dadurch wird verhindert, dass ein Angreifer mit Zugriff auf das System, an dem der Hardware-Token eingesteckt ist, unbemerkt OTPs auslesen kann. Er müsste dazu erst den Anwender dazu bringen, den Key im richtigen Moment zu berühren.

Jenseits von Einmalpasswörtern wie wir sie bisher beschrieben haben, haben sich vor allem im Enterprise-Umfeld Personal Identity Verification (PIV) Smartcards in Verbindung mit Zertifikaten durchgesetzt. Einige der USB-Token verfügen ebenfalls über die Möglichkeit als Smart Card genutzt zu werden. Dadurch entfällt die Notwendigkeit, für alle Nutzer Smartcard-Lesegeräte bereitzustellen.

Angriffsszenarien

Widmen wir uns nun einigen der möglichen Angriffsszenarien auf Zwei-Faktor-Authentisierung. Dabei muss es sich nicht zwangsläufig um einen Angriff auf das dem zweiten Faktor zugrundeliegende kryptografische Verfahren handeln. Tatsächlich geht es in der Regel darum, den zweiten Faktor, also z.B. ein Einmalpasswort, zu erbeuten und direkt zu nutzen bzw. darum, den zweiten Faktor schlicht zu umgehen. Daher lassen sich die meisten Szenarien auch in dieselbe, übergeordnete Kategorie einordnen: Diebstahl.

“Klassischer” Diebstahl

Ein Angreifer kann versuchen, das für die Zwei-Faktor-Authentisierung genutzten Token zu entwenden. Sei es nun eine TAN-Liste, ein mobiles Endgerät oder ein dediziertes Hardware-Token. Dabei ist es durchaus denkbar, dass der Anwender dies erst nach mehreren Tagen bemerkt. Am ehesten würde sicherlich der Verlust des Handys auffallen. Ein Hardware-Token könnte der Angreifer schlicht durch ein identisches Modell ersetzen, um zu erreichen, dass der Diebstahl erst bei den nächsten Benutzung des Tokens auffällt. Selbst dann wird der Anwender womöglich nicht direkt an Diebstahl sondern eher an ein defektes Token denken, wodurch der Angreifer erneut Zeit gewinnt. Soweit möglich und sinnvoll sollten daher Token genutzt werden, deren Verwendung auch noch einmal extra abgesichert sind. Sollte ein Token nicht immer mitgeführt werden können, ist es entsprechend gesichert zu verwahren und ein Verlust des Tokens sollte natürlich unmittelbar vom Benutzer gemeldet werden.
Unter Umständen ist ein Diebstahl oder Austausch gar nicht notwendig und dem Angreifer reicht es bereits, ein Endgerät kurz unbeaufsichtigt vorzufinden, um es zu klonen oder zu kompromittieren: der sogenannte „Evil Maid“-Angriff¹⁹.

Man-in-the-Middle und Man-in-the-Browser Angriffe

Bei einem Man-in-the-Middle²⁰ Angriff bzw. einer Sonderform davon, dem Man-in-the-Browser²¹ Angriff, zielt der Angreifer darauf ab, sich zwischen dem Anwender und dessen Zielanwendung zu platzieren, um so die Kommunikation mitlesen zu können. Dies erfolgt beim Man-in-the-Middle Angriff auf Netzwerkebene, wenn es dem Angreifer gelingt z.B. einen Rogue-Proxy oder Rogue-Access-Point zu platzieren und vollständige Kontrolle über den Netzwerkverkehr zwischen den beiden Kommunikationspartner zu erlangen. Erschwert wird dies zum Beispiel durch die serverseitige Verwendung von HTTPS mit Zertifikaten einer vertrauenswürdigen Certificate Authority. Ein Angreifer der sich zwischen Anwender und Dienst platziert, muss dem Benutzer bzw. dessen Browser ein Zertifikat präsentieren, welches von einer CA unterschrieben wurde, der der Browser vertraut, um keinen Verdacht durch eine Zertifikatswarnung zu erwecken.

Bei einem Man-in-the-Browser Angriff wird der vom Benutzer verwendete Browser mit einer entsprechenden Malware infiziert. Dem Angreifer ist es dadurch möglich für den Anwender unbemerkt Inhalte und Datenverkehr zu modifizieren und mitzulesen. Viele der bekannteren Trojaner arbeiten mit Man-in-the-Browser Angriffen, so z.B. auch Emotet.

Lohnenswertes Ziel solcher Angriffe sind die sogenannten Access-Token, die nach einem erfolgreichen Login für den Benutzer ausgestellt werden. Bei Web-Diensten werden sie beispielsweise regelmäßig als Cookie auf dem Endgerät des Benutzers abgelegt. Mit Hilfe eines solchen ausgelesenen Cookies kann sich ein Angreifer bequem selber am Zielsystem anmelden und so Zwei-Faktor-Authentisierung umgehen. Kevin Mitnick zeigt in einem Video²² anschaulich einen erfolgreichen Man-in-the-Middle Angriff mit vorausgegangenem Phishing bei dem ein abgefangenes Access-Token in einem Cookie Verwendung findet.
In jüngerer Vergangenheit haben Angreifer solche gestohlenen Cookies für $10 gekauft, um damit Zugriff auf den internen Instant Messenger Dienst des Spielepublishers Electronic Arts zu erlangen²³.

Kompromittierte Endgeräte

Abgesehen vom eben beschriebenen Man-in-the-Browser Angriff, der natürlich ebenfalls in die Kategorie kompromittiertes Endgerät fällt, gibt es weitere Angriffsvektoren, wenn ein Endgerät erst einmal unter der Kontrolle eines Angreifers steht. Am bequemsten für den Angreifer ist hier natürlich auch die Nutzung eines vorhandenen Access-Tokens. Ein installierter Keylogger kann Zugangskennungen und PINs, z.B. von Smartcards, abfangen. Eingegebene OTPs können direkt, z.B. mittels eines Replay Angriffs, vom Angreifer genutzt werden, um sich an einem Dienst anzumelden und in der Folge einen weiteren zweiten Faktor zu registrieren²⁴.

Unter Umständen ist es für einen Angreifer auch möglich, den geheimen Seed auszulesen, um selber in der Lage zu sein, gültige OTPs zu erzeugen. Solche Angriffe wurden in der Vergangenheit bereits beobachtet²⁵. Besonders einfach macht man es einem Angreifer, wenn man unverschlüsselte Backups der OTP Seeds, z.B. einen Screenshot des QR-Codes, speichert oder die Seeds gemeinsam mit den sonstigen Account-Daten in einem Password-Manager hinterlegt.

Ein kompromittiertes Endgerät, beispielsweise der PC des Benutzers, kann ebenfalls genutzt werden, um ein weiteres an der Zweit-Faktor-Authentisierung beteiligtes Gerät zu kompromittieren. Solch ein Angriff wurde bereits 2014 erfolgreich getestet und beschrieben²⁶.

Social Engineering

Eine weiterhin große Rolle, nicht zur bei Angriffen auf Zwei-Faktor-Authentisierung, spielt Social Engineering. Dabei sind keineswegs nur unbedarfte Nutzer Opfer von Social Engineering. Im etwas weiter oben beschriebenen Fall des Spielepublishers Electronic Arts gelang es den Angreifern ja, mittels eines gestohlenen Access-Tokens Zugriff auf den firmeninternen Messengerdienst Slack zuzugreifen. Dort konnten sie einem Mitarbeiter des IT-Supports glaubhaft vermitteln, sie seinen ein Angestellter der letzte Nacht sein Handy verloren habe und bekamen daraufhin vom Support Einmalpasswörter ausgestellt. Auch beim Angriff auf Twitter im Juli 2020²⁷, bei dem schlussendlich 130 prominente Twitter Accounts kurzfristig übernommen wurden, gelang es den Angreifern, unter anderem durch Social Engineering, Zugriff auf Admin-Tools zu bekommen mit deren Hilfe sie die Zwei-Faktor-Authentisierung umgehen konnten.

Zu Social Engineering im weiteren Sinn gehört auch das Ausnutzen einer vom Dienstbetreiber angeboteten Accountwiederherstellungs-Funktion durch den Angreifer. Wenn dieser Prozess ungenügend gesichert ist und z.B. nur aus den typischen Frage-Antwort-Kombinationen wie “Mädchenname der Mutter?” besteht, kann ein Angreifer durch Kenntnis dieser Informationen die Zwei-Faktor-Authentisierung deaktivieren. Es ist daher generell ratsam zu erwägen, solche Fragen für eine Accountwiederherstellung nicht wahrheitsgemäß zu beantworten, besonders dann nicht, wenn die Antworten für einen Angreifer leicht zu ermitteln sind. Stattdessen könnte man die Antworten z.B. durch einen Passwortsatz ergänzen, wie er auch schon im letzten Blog-Post²⁸ im Abschnitt “Passwortauthentifizierung verbessern” vorgeschlagen wurde. Manche Dinstbetreiber verzichten daher komplett auf die Möglichkeit, aktive Zwei-Faktor-Authentisierung ohne Zugriff auf den zweiten Faktor zu deaktivieren. Bei Verlust des zweiten Faktors ist damit allerdings der komplette Account verloren.

Fazit, Empfehlung und Ausblick

Zwei-Faktor-Authentisierung ist eine empfehlenswerte und für den Anwender zumeist aufwandsarme bzw. günstige Maßnahme, um seine Accounts zusätzlich zu einem starken Passwort abzusichern. Dies wird auch durch Auswertungen kompromittierter Accounts deutlich. So waren im Januar 2020 von 1,2 Millionen kompromittierten Accounts von Microsoft Enterprise Kunden 99,9% ohne aktivierte Zwei-Faktor-Authentisierung²⁹. Sofern also die Möglichkeit besteht Zwei-Faktor-Authentisierung zu aktivieren, sollte man dies unbedingt ins Auge fassen, sowohl im privaten als auch im beruflichen Bereich. Der zweite Faktor muss sich in seiner Art natürlich vom ersten Faktor unterscheiden und möglichst einen separaten Übertragungskanal nutzen, falls er nicht auf Nutzerseite generiert wird.

Allerdings muss einem dabei auch immer klar sein, dass Zwei-Faktor-Authentisierung mehr Komplexität mit sich bringt und kein Allheilmittel gegen gehackte Accounts ist. Besonders dieser letzte Punkt wird oftmals ignoriert. Sicherlich können viele großflächig durchgeführte Angriffe, wie z.B. ein Password-Spray-Angriff³⁰, bei dem sehr viele Accounts mit wenigen bekannten und gängigen Passwörtern durchprobiert werden, mittels aktivierter Zwei-Faktor-Authentisierung mitigiert werden. Wie wir aber ebenfalls gesehen haben, kann 2FA gegen zielgerichtete Angriffe wie Advanced Persistent Threats³¹ nicht umfassend schützen und verkommt dann nur noch zu einem Häkchen auf einer Compliance-Checkliste.

Bei der Auswahl der Faktoren, Verfahren und Tokentypen sollte man die abzuwendenden Schadensszenarien sowie den Schutzbedarf der Systeme ebenso mit einbeziehen, wie steigende Kosten durch größeren Arbeitsaufwand bei der Implementierung und dem Betrieb der Lösung. Ein wesentlicher Faktor hierbei sind die zu erwartenden Beratungsleistungen, die im IT-Support erbracht werden müssen. Je größer die sogenannte User-friction, also hier das Ausbremsen des Benutzers im Anmeldevorgang durch die Zwei-Faktor-Authentisierung, um so schwieriger wird es, die Maßnahme erfolgreich einzuführen. Im schlimmsten Fall verweigern sich Benutzer und/oder IT-Support.
Ebenso müssen vorab diverse Prozesse definiert werden, wie mit kompromittierten Seeds, dem Verlust oder Vergessen eines Tokens oder dem Ausfall der Infrastruktur, welche die Zwei-Faktor-Authentisierung im Hintergrund abstützt, umgegangen werden soll.

In unserem Proof-of-Concept haben sich letztendlich zur Absicherung administrativer Konten Hardware-Token durchgesetzt. Zum einem aufgrund der geringeren Angriffsfläche bei trotzdem sehr geringem Mehraufwand für die Benutzer. Zum anderen werden durch die Vielzahl an unterstützten Verfahren, wie z.B. der Einsatz als Smart-Card, zum Speichern von OpenPGP-Keys oder als FIDO2-Token für passwortlose Authentisierung³², auch zukünftige Hardening Maßnahmen gegebenenfalls leichter durchführbar. Für nichtprivilegierte Zugänge zu Standarddiensten wie Mail oder VPN ist an der Julius-Maximilians-Universität aktuell noch kein 2FA-Verfahren festgelegt. Hier gilt es insbesondere zwischen dem Schutzbedarf und den entstehenden Kosten und erhöhten Beratungsaufwand für ca. 35.000 Nutzer abzuwägen. Ein Selfservice mit Software-Token anstelle zentral gemanagter Hardware-Token könnte dafür ein gangbarer Weg sein. Besonders sicherheitsbewussten Nutzern steht es natürlich frei, trotzdem auf ein privates Hardware-Token zu setzen.

Es ist denkbar, dass FIDO2³³ zukünftig weiter an Bedeutung gewinnen wird und sich gegen die für den Endanwender im direkten Vergleich oft komplexeren Alternativen durchsetzen kann. So können beispielsweise SSH Zugänge mit public-key-Authentisierung ab OpenSSH Version 8.2 durch FIDO2 zusätzlich abgesichert werden³⁴. Auch die Anmeldung mittels FIDO2 an Windows 10 Systemen^{35, 36}, Microsoft Azure³⁷ oder Linux³⁸ ist bereits möglich.

Jens Roesen, JMU-CERT, Julius-Maximilians-Universität Würzburg