16. November 2015

Das Problem mit dem Google Authenticator

funkmast

Gute Netzabdeckung, ein großes Angebot von preiswerten Smartphones und der Trend “bring your own device” führten zu einem Paradigmenwechsel beim Thema Mehr-Faktor-Authentisierung.

Während vor einigen Jahre Mehr-Faktor- oder Zwei-Faktor-Authentisierung nur von großen Unternehmen angegangen wurde und solchen die einen hohen Schutzbedarf haben, wurde nun doch erkannt, dass Daten zu schützen, die Aufgabe eines jeden Geschäftsführers ist.

Gleichzeitig wird immer öfters auf die einfachereren und preiswerteren Varianten mit einem Smartphone-App, Email oder SMS zurückgegriffen. Doch muss man sich klarmachen, wieviel Sicherheit bei dem Einsatz solch schwacher Faktoren noch übrig bleibt.

Der Google Authenticator

Der Google Authenticator war eine der ersten Apps, die die OTP-Funktionalität bisheriger Hardware-Token in Software auf einem Smartphone abbildete. Der Google Authenticator unterstützt HOTP und TOTP Algorithmen. Alternative Apps sind FreeOTP (TOTP) oder HDE OTP (TOTP).

Die Nutztung des Smartphones als Authentisierungsdevice hat durchaus seine Berechtigung. Denn ein wichtiger Aspekt eines Besitztums zur Anmeldung ist, dass der Benutzer diesen mit sich trägt und nicht auf dem Schreibtisch liegen oder im Computer stecken lässt.

Das Seed (1)

Die OTP Algorithmen HOTP und TOTP arbeiten auf der Basis eines symmetrischen geheimen Schlüssels oder auch Seed, anhand dessen die Einmalpassworte berechnet werden. Das bedeutet aber auch, dass dieses Seed sicher geschützet werden muss. Ob dieses im Smartphone jeweils immer gegeben ist, darf – da das Smartphone auch nur ein leistungsstarker Computer mit veralteter Software und schlechtem Virenschutz ist – berechtigter Weise bezweifelt werden.

Das Seed (2)

Doch ein viel einfacherer Missbrauch ergibt sich aus dem bequemen Konzept zur Initialisierung der Smartphone App.

QrCode-TOTP

Dies geschieht über den QRCode, in dem das oben genannte Seed im Klartext enthalten ist. Der hier gezeigte QRCode enthält den folgenden Inhalt:

otpauth://totp/TOTP00017410?secret=O6LVCAVTS2IJ25NKXKOOGCNTJIOFNUXA&counter=1&digits=6&issuer=privacyIDEA

Dabei ist O6LVCAVTS2IJ25NKXKOOGCNTJIOFNUXA der geheime Schlüssel in sogenannter “Base32” Schreibweise. Das mag für das menschliche Auge zwar merkwürdig und kompliziert aussehen, ist für den Computer oder das Smartphone aber tatsächlich Klartext.

Da dies ein zeibasierter OTP Token ist, wird jedes Gerät, das diesen QRCode scannt, immer den gleichen OTP-Wert anzeigen.

Ein Selbstversuch

Ich lade ein zum Selbstversuch: Haben Sie zwei Smartphones zur Hand? Installieren Sie auf beiden Smartphones den Google Authenitcator, HDE OTP oder FreeOTP. Einzige Voraussetzung für das Gelingen dieses Versuchs ist es, dass die Uhren der beiden Smartphones genau gehen.

Versuch 1

Scannen Sie den QRCode mit Ihrem Smartphone A und mit ihrem Smartphone B.

Starten Sie den Google Authenticator und beobachten Sie, dass auf beiden Smartphones jeweils das gleiche Einmalpasswort angezeigt wird. Zwei Mal das gleiche Einmalpasswort? Da stimmt doch was mit der Namensgebung nicht!

Versuch 2

Dieser Versuch verdeutlicht das Problem noch etwas mehr. Löschen Sie den Token von Smartphone B. Drucken Sie diese Seite mit dem QRCode aus und legen sie sie eine Woche in die Schublade.

Nach einer Woche gehen Sie zur Schublade und Scannen mit Smartphone B den QRCode. Smartphone B wird sofort die gleichen Einmalpassworte wie das Smartphone A anzeigen.

Das Problem im Unternehmen

Aufgrund der Struktur des TOTP-Algorithmus und des Rollout-Prinzips des Google Authenticators können Sie identische Kopien des Tokens erstellen. Auch noch nach Wochen und Monaten.

Ein Unternehmen, das die Passwortweitergabe unter Mitarbeitern verhindern will, darf sich bei der Einführung einer Zwei-Faktor-Lösung nicht blind auf diesen Algorithmus verlassen. Denn derselbe QRCode kann von allen Kollegen gescannt werden, so dass jeder Mitarbeiter den Token des anderen Kollegens hat. Schon wieder ist es dem Unternehmen nicht möglich, sicherzustellen, welcher Mitarbeiter denn nun wirklich hinter dem Account steckt. Die Idee des zweiten Faktors ist ausgehebelt.

Eine mögliche Lösung

Das Problem liegt hier im Rollout-Prozess, bei dem der geheime Schlüssel im Klartext übertragen wird. Ein besseres Rollout-Konzept weist der TiQR-Token auf. Dabei erzeugt das Smartphone den Schlüssel und scannt einen QRCode, in dem aber nur ein Registrierungslink enthalten ist, wohin der Schlüssel (über einen verschlüsselten Kanal) gesendet werden muss.

Doch dieser Rollout-Prozess erfordert auch eine aufwändigere Infrastruktur. Das Smartphone muss online sein und für den Registrierungslink muss ein verstrauenswürdiges Zertifikat vorhanden sein.

Gerade die Leichtigkeit des Rollouts im Falle des Google Authenticators haben gewiss zu seinem Erfolg beigetragen. Doch es bleibt nicht aus, dass man bei der Einführung einer Zwei-Faktor-Lösung sich Gedanken machen muss, wie die diversen Prozesse am besten umzusetzen sind. Schwächen in der Sicherheit sind nur dann tragbar, wenn man sich bewusst für diese entschieden hat und das Restrisiko akzeptieren und damit leben kann.

 

Aktuellste Beiträge
18. November 2024
privacyIDEA in Ohio
Die NetKnights war als Aussteller und Sponsor auf der OLF Conference 2024 in Ohio. Dort wurde privacyIDEA vor einem internationalen Publikum diskutiert, neue Kontakte geknüpft und internationale Kunden wiedergetroffen.
1. November 2024
Zeit für einen Monatsrückblick im Hause NetKnights. Viel ist passiert: Wir haben die Version 3.10.1 von privacyIDEA releast, unseren ersten privacyIDEA Summit veranstaltet und unser Entwicklungs-Team hat Zuwachs bekommen.

Suche

Drücken Sie "Enter" zum Starten der Suche