Zwei-Faktor-Authentifizierung mit spezieller Hardware, Teil 2
Security-Token sind ebenso wie die ChipTAN eine weitere Möglichkeit, der Authentifizierung einen zweiten Faktor hinzuzufügen. Insbesondere Security-Token, die Einmalpasswörter erzeugen, sind theoretisch sehr sicher. Praktisch kann der Hersteller dafür sorgen, dass sie völlig unsicher sind und ersetzt werden müssen.
Security-Token im Überblick
Security-Token gibt es in einer Reihe von Ausführungen, im Rahmen der Authentifizierung stellen sie immer den Faktor "Besitz" dar: Wer das Token besitzt, ist der damit verknüpfte Benutzer. Theoretisch könnte man das Token auch als einzigen Faktor verwenden, wie es zum Beispiel beim Einsatz als Dongle auch geschieht: Wer das Dongle besitzt, ist der rechtmäßige Benutzer des Programms.
Da so ein Token aber klein ist und durchaus mal verloren gehen kann, vom gezielten Diebstahl ganz zu schweigen, wird es im Rahmen der Authentifizierung meist um den Faktor "Wissen" (von Benutzername und Passwort), seltener um den Faktor "Sein" (Biometrische Systeme), ergänzt.
Im Rahmen der Authentifizierung kommen verschiedene Arten von Token zum Einsatz, von denen hier nur zwei vorgestellt werden sollen: Zum einen Token, die im Rahmen eines Challenge-Response-Verfahrens arbeiten, zum anderen die bereits oben erwähnten Token zum Erzeugen von Einmalpasswörtern.
Im Fall eines Challenge-Response-Verfahren kommen asymmetrische Kryptosysteme zum Einsatz. Der Server sendet einen Testwert, die sog. Challenge, an das Token. Das Token berechnet mit dem Kryptosystem die zugehörige Antwort, genannt Response. Der Server prüft, ob die vom Token erzeugte Response mit der erwarteten überein stimmt. Ist die Prüfung erfolgreich, wird der Benutzer authentifiziert.
Im Fall von Einmalpasswörtern berechnet das Token in einem bestimmten,
konstanten Zeitintervall neue Passwörter nach einem mathematischen
Algorithmus. Dazu ist es notwendig, dass Token und authentifizierender
Server einen gemeinsamen geheimen Schlüssel kennen.
Damit das Verfahren funktioniert, müssen Token und authentifizierender
Server synchronisiert werden. Das kann entweder vor der Ausgabe an den
Benutzer oder bei der Verbindung des Tokens mit einem Lesegerät geschehen.
Da Token und Server im Laufe der Zeit unsynchron werden, müssen sie
regelmäßig neu synchronisiert werden. Ist das nicht möglich, schlägt
die Authentifizierung irgendwann fehl.
Ein schlechtes Beispiel: RSAs SecurID
Die SecurID-Token von RSA erzeugen in bestimmten Zeitintervallen aus aktueller Uhrzeit und geheimen Startwert (dem "Seed") ein neues Einmalpasswort. Der zugehörige Authentifizierungsserver kennt die Seeds der zulässigen Token und kann seinerseits das jeweils aktuell gültige Passwort berechnen.
Der entscheidende Punkt ist in diesem Fall der Seed: Wer den Seed kennt, kann die Einmalpasswörter mit dem öffentlich bekannten Algorithmus berechnen. Eigentlich sollte der Seed nur dem jeweilige Token und dem zugehörige Authentifizierungsserver bekannt sein. Mitte März 2011 gab RSA bekannt, Opfer eines gezielten Angriffs geworden zu sein. Ausgespäht wurden nicht näher beschriebene Informationen zu den SecurID-Token, ein Angriff darauf wurde aber nicht für möglich gehalten.
Etwas später musste RSA dann die SecurID-Token austauschen, da die Angreifer die Seed-Werte ausgespäht und darüber andere Unternehmen angegriffen hatten. Mit anderen Worten: RSA hatte die Seed-Werte nicht nur völlig unnötigerweise gespeichert, sondern sich auch noch stehlen lassen.
Wir erinnern uns: Wer den Seed kennt, kann die Einmalpasswörter berechnen. Eigentlich sollten das nur das jeweilige Token und der zugehörige Authentifizierungsserver sein. Wie durch den Angriff herauskam, gehört auch RSA dazu. Und die Angreifer, die die Seeds bei RSA ausspähen konnten. Wie vertrauenswürdig sind Einmalpasswörter, die auch der Hersteller der Token berechnen kann?
Angriffe auf Token, allgemein
Mal abgesehen von absichtlich gestohlenen Token gibt es für alle Token nur einen möglichen Angriffe, gegen den sie konzeptbedingt machtlos sind: Man-in-the-Middle-Angriffe. Gibt sich der Man-in-the-Middle gegenüber dem Benutzer als Server aus, kann er die vom Benutzer erhaltenen Authentifizierungsdaten verwenden, um sich selbst beim Server als angeblicher Benutzer zu authentifizieren.
Theoretisch sind Replay-Angriffe möglich, bei denen belauschte Authentifizierungsdaten vom Angreifer erneut verwendet werden, um sich beim Server als der belauschte Benutzer auszugeben. In den hier vorgestellten Fällen scheitern sie aber immer (beim Challenge-Response-Verfahren passt die ausgespähte Response nicht zur neuen Challenge) oder sind nur in sehr engen Zeitfenstern möglich (das Einmalpasswort ist nach 1 Minute ungültig).
Spezielle Token sind also bei der Suche nach einem zweiten Faktor für die Authentifizierung eine gute Wahl, sofern man dem Hersteller vertraut (und der das Vertrauen auch verdient). Aber wozu soll man ein zusätzliches Token verwenden, wenn die meisten Benutzer doch ein Smartphone besitzen, dass genau so gut zum Erzeugen von Einmalpasswörtern verwendet werden kann? Um diese Form der Authentifizierung geht es in der nächsten Folge.
Übersicht über alle Artikel zum Thema
- Authentifizierung: Sichere Passwörter
- Authentifizierung: Passwortregeln, Teil 1
- Authentifizierung: Passwortregeln, Teil 2
- Authentifizierung: Ein Faktor reicht nicht (mehr)
- Zwei-Faktor-Authentifizierung per SMS
- Zwei-Faktor-Authentifizierung mit spezieller Hardware, Teil 1
- Zwei-Faktor-Authentifizierung mit spezieller Hardware, Teil 2
- Zwei-Faktor-Authentifizierung mit der Smartphone-App
Trackbacks