Ist Google Authenticator ersetzbar?

Viele Online-Dienste ermöglichen (und erfordern manchmal) die Einrichtung einer Zwei-Faktor-Authentifizierung (2FA), bei der Einmalcodes für den Identitätsnachweis erzeugt werden. Google Authenticator ist die bekannteste und am weitesten verbreitete Authentifizierungs-App, die solche Codes generiert. Nahezu alle Dienste sind mit ihr kompatibel, einige stellen beim Einrichten der Zwei-Faktor-Authentifizierung sogar einen Link zur App bereit. Aber ist Google Authenticator die einzige Option? Oder sollten Sie eventuell auf eine der Alternativen wie Microsoft Authenticator oder Twilio Authy umsteigen?

Da es diese Alternativen gibt und sie eindeutig Anklang unter Nutzer finden, könnte man meinen, dass sie einen vollwertigen Ersatz für Google Authenticator darstellen (könnten). Aber bergen diese Alternativen eventuell sogar Risiken? Für diejenigen, die keine Zeit haben, den Artikel bis zum Ende zu lesen, hier gleich die Antwort: Keine Sorge, Google Authenticator ist durchaus ersetzbar. Aber wenn Sie mehr über das Wieso, Weshalb, Warum erfahren möchten – lesen Sie weiter…

So funktionieren Authentifikatoren

Beginnen wir damit, wie Apps zur Authentifizierung im Allgemeinen funktionieren. Unter dem Dach der Initiative for Open Authentication (OATH) wurden mehrere offene Standards zur starken Authentifizierung geschaffen. Authenticator-Apps basieren auf diesen Standards (ebenso wie einige andere Dinge, die aber nicht das Thema dieses Beitrags sind).

OATH HOTP

Bereits 2005 erschien der Authentifizierungsstandard OATH HOTP (hash-based one-time password) und mit ihm die Grundlagen der Authentifizierung per Einmalcode, der synchron auf Client- und Serverseite generiert wird.

Die Grundidee ist, dass sich sowohl die App als auch der von Ihnen genutzte Dienst denselben geheimen Schlüssel merken. Anschließend wird ein kryptografischer Algorithmus angewandt, um auf der Grundlage dieses Schlüssels und eines Zählerwerts einen Einmalcode zu generieren. Ein Zähler ist im Grunde eine Zahl, die jedes Mal erhöht wird, wenn ein neuer einmaliger Code erzeugt wird. Die Daten zur Codeberechnung sind auf beiden Seiten gleich und beide Codes im Idealfall somit identisch. An dieser Stelle müssen sie nur noch verglichen werden: Wenn der von Ihnen eingegebene Code mit dem vom Server generierten übereinstimmt, ist die Authentifizierung erfolgreich.

Nach jeder Anfrage für eine Generierungssitzung ändert sich der Zählerwert, was einen einmaligen und eindeutigen Code zur Folge hat. Dabei wird ein Algorithmus verwendet, der Rückrechnungen verhindert, damit keine geheimen Schlüssel aus dem Code extrahiert werden können. Selbst wenn jemand den Einmalcode abfangen würde, wäre er nicht in der Lage, den geheimen Schlüssel zu berechnen, den Authenticator zu reproduzieren und seine eigenen neuen Codes zu generieren.

Dennoch gibt es zwei Probleme mit HOTP. Zum einen geraten die Zählerwerte leicht aus dem Gleichgewicht. Wenn Sie z. B. den Authenticator auffordern, einen Code zu generieren, ihn aber nicht verwenden, ändert der Authenticator auf Kunden-Seite den Zählerwert, während er auf Dienst-Seite gleichbleibt. Das Ergebnis sind Codes, die nicht mehr übereinstimmen. Zum anderen bleibt der Code so lange gültig, bis sich der Zählerwert ändert – was einem Angreifer möglicherweise Zeit gibt, den abgefangenen Code zu verwenden, wenn er es irgendwie schafft, das Opfer abzulenken.

OATH TOTP

Im Jahr 2011 wurde ein neuer Standard vorgestellt – OATH TOTP (time-based one-time password), der die aktuelle Uhrzeit als Zählerwert verwendet. Das Prinzip bleibt dasselbe: Ein geheimer Schlüssel, der beiden Parteien bekannt ist, wird verwendet, um einen Einmalcode mit demselben kryptografischen Algorithmus zu berechnen. Da der Zähler auf der Unixzeit basiert, ändert sich der Code automatisch in regelmäßigen Abständen, ganz egal, ob er benutzt wird oder nicht.

Alle mit dem Internet verbundenen Geräte kennen die korrekte Uhrzeit, sodass Sie sich keine Sorgen machen müssen, dass einmalige Codes nicht mehr synchron sind. Außerdem ist das Intervall zwischen Codeänderungen sehr kurz (standardmäßig 30 Sekunden), sodass der Angreifer nicht viel Zeit hat, ihn zu verwenden, wenn der Code abgefangen werden sollte.

Grundprinzipien von Authentifikatoren

Die beiden erwähnten Standards werden von Authenticator-Apps verwendet. TOTP ist natürlich der gebräuchlichere, weil er in jeder Hinsicht besser ist; HOTP findet man dennoch weiterhin in einigen prähistorischen Implementierungen.

Bei der Entwicklung eines Authenticator müssen der Client und der Server einen gemeinsamen Standard festlegen und den Schlüssel gemeinsam nutzen – dies ist das absolute Minimum, damit die App funktioniert. Darüber hinaus können zusätzliche Parameter für die Erstellung von Token festgelegt werden. Doch wie kommen die App und der Dienst auf einen gemeinsamen Nenner? In den meisten Fällen mit Hilfe eines QR-Codes, was uns zur nächsten Frage führt: Wie funktionieren diese Codes?

Inhalte von QR-Codes

Meines Wissens nach gehören QR-Codes nicht zu den von der OATH entwickelten Standards, sondern sind vielmehr eine freiwillige Anpassung an das von Google Authenticator festgelegte Format. Wie auch immer, App-basierte Authentifizierungssysteme verwenden in der Regel QR-Codes, in denen ein Link (oder genauer gesagt ein Uniform Resource Identifier, kurz URI) mit allen erforderlichen Informationen kodiert ist. Dies könnte folgendermaßen aussehen

otpauth://totp/Google:alanna@gmail.com?secret=IN2XE2LPOVZSYIDBOJSW4J3UEB4W65J7&issuer=Google&algorithm=SHA1&digits=6&period=30

Wie Sie sehen können, werden im QR-Code eine ganze Reihe von Parametern übertragen, die Folgendes angeben:

• Den URI-Zweck – Erstellung eines Authentifizierungs-Tokens (dafür steht otpauth am Anfang)
• Den Authentifizierungsstandard, HOTP oder TOTP; in diesem Fall TOTP
• Die Bezeichnung des Tokens, die in der App angezeigt werden soll – in unserem Beispiel Google
• Den Benutzernamen – in diesem Fall alanna@gmail.com
• Den geheimen Schlüssel, aus dem die Codes generiert werden (im Base32-Format) – der wichtigste Teil, eine lange Kette von Zufallszeichen
• Den Namen des Dienstes, der den URI erstellt hat – in unserem Beispiel wieder Google
• Den Algorithmus, der zur Codegenerierung verwendet wird – in diesem Fall SHA1
• Die Länge der generierten Codes – normalerweise sechs Zeichen, wie hier gezeigt, aber auch andere Varianten sind akzeptabel
• Die Zeitspanne, nach der der Code abläuft – normalerweise 30 Sekunden, aber es können auch andere Intervalle festgelegt werden.

So sieht der dazugehörige QR-Code aus:

QR-Codes können es in sich haben: beispielsweise in Form zahlreicher Parameter von Authentifizierungstoken

Wie wir bereits wähnt haben, können viele dieser Parameter weggelassen werden. Das Token-Label und der Benutzername können beliebig sein, während der Name des Dienstes überhaupt nicht erforderlich ist – keine dieser Informationen beeinflussen die Codegenerierung und dienen hauptsächlich der Bequemlichkeit. Auch einige andere Parameter sind nicht zwingend erforderlich. Der Authenticator verwendet den Standardalgorithmus zur Codegenerierung (SHA1) und erzeugt einen sechsstelligen Code mit einer Aktualisierungszeit von 30 Sekunden, sofern im URI nicht anders angegeben.

Im Grunde müssen Dienst und Authenticator lediglich den Standard (HOTP oder TOTP) festlegen und den geheimen Schlüssel austauschen. Somit würden der folgende URI und der QR-Code funktionell genau dasselbe Authentifizierungstoken ergeben wie das vorherige Paar:

otpauth://totp/Whenever:Wherever?secret=IN2XE2LPOVZSYIDBOJSW4J3UEB4W65J7

Viele QR-Code-Parameter können weggelassen oder auf beliebig gesetzt werden; die Hauptsache ist, dass der geheime Schlüssel gemeinsam genutzt und ein Standard festgelegt wird (HOTP oder TOTP)

Im Endeffekt arbeiten die meisten Dienste, die mit App-generierten Codes zur Authentifizierung arbeiten, mit solchen QR-Codes. Jede Authenticator-App wiederum unterstützt das Lesen solcher QR-Codes und ihre Umwandlung in Authentifizierungstoken, die dann die Einmalcodes erzeugen. Anstelle von Google Authenticator können Sie also selbstverständlich eine der zahlreichen Alternativen wählen.

Ausnahmen: Dienste, die nicht mit regulären Authenticator-Apps kompatibel sind

Aus unbekannten Gründen hält sich nicht jeder in der IT-Branche an die oben genannten Standards. Einige ziehen es vor, sich eigene Standards auszudenken. Im Anschluss folgen einige Unternehmen, die Dienste und Programme anbieten, die mit Authenticator-Apps von Drittanbietern (einschließlich Google Authenticator) nicht kompatibel sind.

• Apple. Die Jungs aus Cupertino haben ein eigenes Zwei-Faktor-Authentifizierungssystem, das keine Anwendungen von Drittanbietern verwendet. Stattdessen wird der Einmalcode vom Betriebssystem gleichzeitig auf allen Geräten generiert, die mit Ihrer Apple-ID verknüpft sind.
• Valve und Blizzard. Für die Sicherheit von Steam und Battle.net bieten die Entwickler eine eigens designte Zwei-Faktor-Authentifizierung an: Steam Guard (integriert in die Steam-App für Android und iOS) und Battle.net Authenticator. Meines Wissens nach gibt es nur eine Authenticator-App eines Drittanbieters, die diese Systeme unterstützt: WinAuth.
• Microsoft. Um Ihr Microsoft-Konto zu authentifizieren, müssen Sie Microsoft Authenticator installieren. Das Gute hier ist, dass Sie keinen Code eingeben müssen. Einfach den Button in der Anwendung drücken und die Eingabe bestätigen. Als Bonus generiert Microsoft Authenticator auch Standard-Authentifizierungstoken, was es zu einer soliden Alternative zu Google Authenticator macht. Für die Nutzung der App benötigen Sie übrigens kein Microsoft-Konto.
• Adobe. Der Entwickler von Grafiksoftware bietet eine eigene 2FA-App an – Adobe Account Access – die nach einer ähnlichen Logik wie Microsoft Authenticator funktioniert: Die Anmeldung bei Ihrem Adobe-Konto wird durch Antippen einer Schaltfläche authentifiziert, nicht durch einen Code. Theoretisch unterstützt die App auch die Erstellung von Token für die Authentifizierung bei Diensten von Drittanbietern. Damit Adobe Account Access funktioniert, müssen Sie die App jedoch zunächst mit Ihrem Adobe-Konto verknüpfen, was den Bewertungen im App Store und bei Google Play zufolge nicht sonderlich empfehlenswert ist.

Muss ich nun Google Authenticator verwenden?

Nicht zwangsläufig. Bei allen Diensten, die mit Google Authenticator funktionieren, können Sie die Zwei-Faktor-Authentifizierung mit einer beliebigen anderen App einrichten. Darüber hinaus haben viele von ihnen erhebliche Vorteile gegenüber der Google-Lösung.

Wir haben übrigens bereits einen Beitrag über die interessantesten Authenticator-Apps für Android, iOS, Windows und macOS verfasst. Und wenn Sie diesen Text tatsächlich bis zum Ende gelesen haben, dann sagt uns unser Bauchgefühl, dass Sie eventuell an andOTP (für Android-Nutzer) oder OTP auth (für iOS-Nutzer) interessiert sein könnten.