Multi-Faktor-Authentifizierung (MFA)

Bei der Multi-Faktor-Authentifizierung (MFA) werden zusätzliche Nachweise in den Anmeldeprozess integriert, um die Identität eines Benutzers beim Zugriff auf ein System oder eine Anwendung zu bestätigen. Die Idee dahinter ist, die Wahrscheinlichkeit eines unberechtigten Zugriffs bei einem kompromittierten Zugangsfaktor zu verringern.

MFA basiert auf der Kombination von mindestens zwei der folgenden drei Authentifizierungsfaktoren:

• Wissen (etwas, das nur der Benutzer kennt): Zum Beispiel ein Passwort, eine PIN oder die Antwort auf eine Sicherheitsfrage.
• Besitz (etwas, das der Benutzer besitzt): Dies kann ein Hardware-Token, eine Smartcard oder ein Smartphone mit einer Authenticator-App sein.
• Inhärenz (etwas, das der Benutzer ist): Dazu gehören biometrische Verfahren wie Fingerabdruck-, Gesichts- oder Iriserkennung.

Es gibt verschiedene Implementierungen und Technologien für MFA. Die gebräuchlichsten Methoden sind die Verwendung eines SMS-Codes, der eine PIN an das Mobiltelefon des Benutzers sendet, die Verwendung biometrischer Daten wie Fingerabdrücke oder Iris-Scans, die Verwendung von Hardware-Tokens, bei denen physische Geräte einen Authentifizierungscode erzeugen oder speichern, oder die Verwendung von Authenticator-Apps, die zeitlich begrenzte Einmalpasswörter (TOTP) erzeugen.

Zeitlich begrenzte Einmalpasswörter (TOTP)

TOTP steht für Time-based One-Time Password und ist ein Algorithmus für die Zwei-Faktor-Authentifizierung. Die TOTP-Spezifikation ist in RFC6238 definiert. TOTP erzeugt ein temporäres Passwort, das nur für einen kurzen Zeitraum gültig ist. Typischerweise 30 Sekunden. Nach Ablauf der Zeit wird ein neues Passwort generiert. Dieses Verfahren erhöht die Sicherheit, indem es das Risiko minimiert, dass ein gestohlenes oder abgefangenes Benutzer Passwort später verwendet werden kann. TOTP wird von vielen Online-Diensten und -Anwendungen unterstützt, da es eine robuste Methode bietet, um die Identität von Benutzern zu bestätigen und unberechtigten Zugriff zu verhindern.

Der TOTP-Algorithmus zur Erzeugung von zeitbasierten Einmalpasswörtern verwendet den HMAC-Algorithmus (Hash-based Message Authentication Code) mit einem geheimen Schlüssel und dem aktuellen Zeitwert als Eingabe. Dieser geheime Schlüssel wird sowohl auf dem Server als auch auf dem Benutzergerät gespeichert und ist in der Regel 160-256 Bit lang. Bei der Einrichtung wird dieser Schlüssel mittels QR-Code oder manueller Eingabe sicher übertragen. Der aktuelle Zeitwert wird berechnet, indem die Sekunden seit einem definierten Startdatum ( typischerweise der 1. Januar 1970) durch die Länge des gewünschten Zeitintervalls ( typischerweise 30 Sekunden) dividiert wird. Anschließend wird mit dem HMAC-Algorithmus, der in der Regel SHA-1, SHA-256 oder SHA-512 verwendet, ein Hashwert aus dem geheimen Schlüssel und dem Zeitwert gebildet. Der erzeugte Hashwert wird dann weiter verarbeitet, um einen kürzeren, für den Benutzer handhabbaren Code zu erzeugen, der in der Regel aus 6 bis 8 Ziffern besteht. Zur Authentifizierung gibt der Benutzer das generierte Passwort ein, und der Server prüft, ob das eingegebene Passwort mit dem selbst generierten übereinstimmt und innerhalb des gültigen Zeitfensters liegt, um den Zugriff zu bestätigen.

Fehlerquelle Zeit

Wenn die Systemuhr auf dem Gerät eines Benutzers oder auf dem Server, der TOTP verwendet, nicht korrekt eingestellt ist, kann dies zu Authentifizierungsproblemen führen. Da TOTP bei der Generierung von Einmalpasswörtern stark von der aktuellen Uhrzeit abhängt, ist es wichtig, dass die Uhrzeit zwischen Client und Server synchronisiert ist. In den meisten Betriebssystemen gibt es Einstellungen, die eine automatische Zeitsynchronisation mit Zeitservern im Internet ermöglichen, z. B. mit denen des Network Time Protocol (NTP). Unterschiedliche Zeitzonen stellen in der Regel kein Problem dar, da die TOTP-Implementierung UTC als Standardzeitzone verwendet.

Server können so konfiguriert werden, dass sie eine gewisse Toleranz gegenüber Zeitabweichungen bieten. Dies bedeutet, dass der Server die TOTP nicht nur für das aktuelle Zeitintervall prüft, sondern auch für ein oder zwei vorhergehende und zukünftige Intervalle. Dies kann helfen, kleinere Zeitabweichungen auszugleichen, ohne die Sicherheit wesentlich zu beeinträchtigen.

Sicherheitsbedenken

Nobody is perfect, auch TOTP nicht. Eine Schwachstelle bei der Implementierung von TOTP ist das Prinzip des geheimen Schlüssels. Wenn dieser Schlüssel kompromittiert wird oder in falsche Hände gerät, kann der Angreifer seinerseits TOTPs generieren. Es sollte darauf geachtet werden, dass der geheime Schlüssel direkt auf dem Server generiert und kein nachgelagerter Dienst wie z.B. chart.googleapis.com verwendet wird. Es lohnt sich, etwas Zeit in die Auswahl der Implementierung zu investieren. Dienste wie Azure Active Directory, Google Cloud Identity oder Amazon Cognito bieten beispielsweise integrierte Cloud-Lösungen für das Management von Zwei-Faktor-Authentifizierung. Damit wird der geheime Schlüssel, wenn auch verschlüsselt, in die Hände Dritter gelegt. Über deren Vertrauenswürdigkeit muss jeder selbst entscheiden. Hier ist eine Risikobewertung notwendig, die das Risiko eines kompromittierten geheimen Schlüssels den zu erwartenden Auswirkungen eines Sicherheitsvorfalls gegenüberstellt.

Eine ähnliche Auswirkung auf die Sicherheit des geheimen Schlüssels kann z.B. auch bei Providern bestehen, die das Hosting von Webseiten auf Managed Servern anbieten. Bei korrekter Implementierung und Konfiguration des Servers, der unter vollständiger Kontrolle des Providers steht, sollten sensible Daten wie die Provisioning-URI nicht gespeichert oder gecacht werden. Theoretisch ist es jedoch möglich, dass der Provider Zugriff auf diese Daten hat. Zudem kann ein Sicherheitsvorfall in der Infrastruktur des Providers die Integrität der Managed Server beinträchtigen. Achten Sie hier bei der Auswahl Ihres Hosting Providers auf die Seriosität des Anbieters und überprüfen Sie die korrekte Umsetzung von Datenschutz und Datensicherheit. Eine Alternative zu einem Managed Hosting Paket wäre der Betrieb eines eigenen Root Servers, da hier auch das Betriebssystem unter der vollen Kontrolle des Kunden steht. Diese Server erfordern jedoch einen höheren Wartungsaufwand und sind in der Regel auch etwas teurer in der Miete. Zudem ist der Betreiber für die Sicherheit des Root-Servers vollumfänglich selbst verantwortlich.

Ein weiteres Argument, das den Anwendern immer wieder Kopfzerbrechen bereitet, ist die Integrität und Vertraulichkeit der verwendeten Authenticator App. Bei Closed Source Apps mit proprietärem Code ist es schwer nachzuvollziehen, ob der geheime Schlüssel wirklich so geheim ist oder vielleicht sogar in der Cloud des Anbieters gespeichert wird. Microsoft Authenticator, Authy oder LastPass Authenticator sind Anbieter, die eine Synchronisation des geheimen Schlüssels über eine Cloud oder eine Backup-Funktion anbieten. Wägen Sie auch hier Ihr Sicherheitsbedürfnis sorgfältig ab und nutzen Sie Open Source Lösungen, bei denen die Funktionsweise bekannt und nachvollziehbar ist.

Last but not least ist auch TOTP nicht immun gegen Phishing-Angriffe. Mit dem Modlishka-Framework hat der Sicherheitsforscher Piotr Duszyński gezeigt, wie ein Man-in-the-Middle-Angriff auf eine 2FA-Infrastruktur durchgeführt werden kann. Modlishka vermittelt als Reverse Proxy zwischen dem Phishing-Opfer und der Zielwebseite. Der gesamte Traffic und alle Benutzereingaben werden über den Modlishka-Reverse-Proxy-Server geleitet und aufgezeichnet. Auf diese Weise können nicht nur die Zugangsdaten des Opfers abgefangen, sondern auch die Zwei-Faktor-Authentifizierung umgangen werden. Der Angreifer kann das TOTP in Echtzeit abfangen und zum Login benutzen.

Praxisbeispiel und Backup

Ich benutze z.B. das WordPress Plugin Wordfence, um den Login meines Blogs zu sichern. Es generiert den geheimen Schlüssel, den QR-Code und implementiert die Eingabe des zweiten Faktors in den Anmeldeprozess. Bei Wordfence muss z.B. darauf geachtet werden, dass der QR-Code und der geheime Schlüssel nur bei der Initialisierung des Prozesses angezeigt werden. Nach Abschluss des 2FA-Aktivierungsprozesses sind diese Daten nicht mehr abrufbar.

Best Practice, auch im Hinblick auf ein Backup der 2FA, ist die Integration des geheimen Schlüssels in einen Passwort-Safe, der TOTP unterstützt, z.B. KeePassXC. KeePassXC bietet die Möglichkeit, den QR-Code beliebig oft anzuzeigen, was die Integration in eine oder mehrere Authenticator Apps auf Mobiltelefonen erleichtert. Es gibt auch Authenticator Apps auf Mobiltelefonen, die den geheimen Schlüssel anzeigen können, aber aus Sicherheitsgründen wird dies nicht von allen Apps unterstützt.

Darüber hinaus erzeugt Wordfence eine Reihe von Recovery Codes mit denen man sich anmelden kann, wenn keine Möglichkeit mehr vorhanden ist ein gültiges TOTP zu erzeugen:

Two-Factor Authentication Recovery Codes - https://www.domain.de (admin)
Each line of 16 letters and numbers is a single recovery code, with optional spaces for readability. To use a recovery code, after entering your username and password, enter the code like "1234 5678 90AB CDEF" at the 2FA prompt. If your site has a custom login prompt and does not show a 2FA prompt, you can use the single-step method by entering your password and the code together in the Password field, like "mypassword1234 5678 90AB CDEF". Your recovery codes are:

Implementierung

Die Funktionsweise von TOTP kann anhand eines kleinen Python-Programms nachvollzogen werden. Python bietet sich für diesen Zweck an, da es mit pyotp eine Bibliothek implementiert, die eine Reihe von Funktionen zur Verwaltung von One-Time Passwords (OTP) sowohl in ihrer zeitbasierten (TOTP) als auch in ihrer zählerbasierten Form (HOTP) zur Verfügung stellt.

import pyotp
import qrcode
from PIL import Image

# Erzeugen eines zufälligen geheimen Schlüssels
secret = pyotp.random_base32()
print("Geheimer Schlüssel:", secret)

# Initialisieren einer TOTP-Instanz mit dem geheimen Schlüssel
totp = pyotp.TOTP(secret)

# Generieren des Provisioning URI für die Einrichtung in Google Authenticator
label = "pronto@testlab"
issuer_name = "Prontosystems"
uri = totp.provisioning_uri(name=label, issuer_name=issuer_name)

# Erzeugen des QR-Codes
qr_img = qrcode.make(uri)
qr_img.show()

# Generieren eines TOTP-Codes
print("Aktueller TOTP-Code:", totp.now())

# Überprüfen des Codes
user_input = input("Geben Sie den TOTP-Code ein: ")
if totp.verify(user_input):
    print("Verifikation erfolgreich!")
else:
    print("Verifikation fehlgeschlagen.")

Beschreibung des Code:

1. Geheimer Schlüssel: Der geheime Schlüssel wird zu Beginn erzeugt und ausgegeben. Dieser Schlüssel ist eine zufällige Zeichenfolge, die in Base32 kodiert ist, einer Kodierung, die mit den meisten TOTP-Anwendungen kompatibel ist. Der Schlüssel sollte sicher gespeichert und geschützt werden, da er die Grundlage für die Generierung der Einmalpasswörter bildet.
2. TOTP-Instanz: Nach der Erzeugung des geheimen Schlüssels wird eine TOTP-Instanz mit diesem Schlüssel initialisiert. Diese Instanz wird dann für die Generierung und Verifikation der TOTP-Codes verwendet.
3. Provisioning URI: Der Code erzeugt zunächst mit provisioning_uri() einen Provisioning URI, der den Benutzernamen und den Aussteller enthält. Diese URI wird dann verwendet, um einen QR-Code zu erzeugen.
4. QR-Code Generierung: Die Funktion qrcode.make() erzeugt den QR-Code, der dann mit show() angezeigt wird.
5. TOTP Generierung: Um das aktuelle TOTP zu erzeugen, wird die Methode now() der TOTP-Instanz aufgerufen. Dieser Wert ändert sich in einem Standardintervall von 30 Sekunden.
6. Überprüfung des TOTP: Der Benutzer wird aufgefordert, das soeben generierte TOTP einzugeben. Der Code überprüft dann, ob der eingegebene Wert mit dem aktuellen TOTP übereinstimmt. Ist die Überprüfung erfolgreich, wird eine Bestätigungsmeldung ausgegeben, andernfalls eine Fehlermeldung.

In der pyotp-Bibliothek ist das Zeitintervall für die TOTP-Generierung standardmäßig auf 30 Sekunden eingestellt. Dies ist eine übliche Einstellung für TOTP, die in vielen Implementierungen verwendet wird.

Ausgabe des Programms