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:
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:
Geheimer Schlüssel
: Der geheime Schlüssel wird zu Beginn erzeugt und ausgegeben. Dieser Schlüssel ist eine zufällige Zeichenfolge, die inBase32
kodiert ist, einer Kodierung, die mit den meistenTOTP
-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.TOTP-Instanz
: Nach der Erzeugung des geheimen Schlüssels wird eineTOTP-Instanz
mit diesem Schlüssel initialisiert. Diese Instanz wird dann für die Generierung und Verifikation derTOTP-Codes
verwendet.Provisioning URI
: Der Code erzeugt zunächst mitprovisioning_uri()
einen Provisioning URI, der den Benutzernamen und den Aussteller enthält. Diese URI wird dann verwendet, um einenQR-Code
zu erzeugen.QR-Code Generierung
: Die Funktionqrcode.make()
erzeugt den QR-Code, der dann mitshow()
angezeigt wird.TOTP Generierung
: Um das aktuelleTOTP
zu erzeugen, wird die Methodenow()
derTOTP-Instanz
aufgerufen. Dieser Wert ändert sich in einem Standardintervall von 30 Sekunden.Überprüfung des TOTP
: Der Benutzer wird aufgefordert, das soeben generierteTOTP
einzugeben. Der Code überprüft dann, ob der eingegebene Wert mit dem aktuellenTOTP
übereinstimmt. Ist die Überprüfung erfolgreich, wird eine Bestätigungsmeldung ausgegeben, andernfalls eine Fehlermeldung.
Ausgabe des Programms
Output:
Geheimer Schlüssel: I7KG2BGF33U5V4AJC4J762Y5CNLCKHVC Aktueller TOTP-Code: 422595 Geben Sie den TOTP-Code ein: 422595 Verifikation erfolgreich!
Der generierte Provisioning URI
enthält die im Code eingegebenen Daten label
und issuer_name
sowie den generierten geheimen Schlüssel: