HMAC-based one-time password

HMAC-based one-time password (HOTP) ist ein Verfahren zur Erzeugung von Einmalkennwörtern basierend auf dem Keyed-Hash Message Authentication Code (HMAC), welcher im Rahmen der Authentifizierung Anwendung findet. Das Verfahren wurde von der Initiative For Open Authentication (OATH) entwickelt und im Rahmen der Internet Engineering Task Force (IETF) im Dezember 2005 als RFC 4226 veröffentlicht.^[1]

Das Verfahren zählt zu den ereignisgesteuerten Kennwortverfahren und findet beispielsweise im Rahmen der Authentifizierung bei der Anmeldung von einem Benutzer (Sender) bei einem Validierungsserver (Empfänger) Anwendung. In praktischen Anwendungen wie dem Internet hat sich HOTP nur in Randbereichen durchgesetzt und es wird üblicherweise das auf HOTP aufbauende Verfahren Time-based one-time password (TOTP) verwendet.

Verfahren

Das Verfahren basiert im Kern auf einer kryptografischen Hash-Funktion (HMAC), mit deren Hilfe aus dem zwischen Sender und Empfänger vereinbarten und geheimen Schlüssel K und einen zwischen Sender und Empfänger synchronen Zähler C ein kryptografischer Hash-Wert berechnet wird. Der Zähler wird bei jeder Authentifizierung auf beiden Seiten, sowohl bei dem Sender als auch beim Empfänger, inkrementiert und ergibt damit bei jedem Aufruf ein unterschiedliches, vom geheimen Schlüssel abhängiges Einmalkennwort.

Zur Berechnung können im Rahmen des Verfahrens verschiedene kryptografische Hash-Funktionen eingesetzt werden wie beispielsweise SHA-1 oder auch die sicheren Verfahren aus der Gruppe SHA-2 wie beispielsweise SHA-512. Der so berechnete Hash-Wert wird auf eine Länge von 31 Bit abgeschnitten und daraus dann durch modulo 10^d, mit d=6 oder d=8 für sechs oder acht Stellen, das eigentliche Einmalpasswort gebildet.

Das Verfahren ist ein offener Standard und frei von Patenten.

Anwendungen

Der praktische Nachteil des ereignisgesteuerten Verfahrens HOTP im Rahmen der Authentifizierung bei der Anmeldung von einem Benutzer (Sender) bei einem Server (Empfänger) besteht in dem Umstand, dass der zwischen Sender und Empfänger synchron zu haltende Zähler C bei der Initialisierung synchronisiert wird und danach ohne erfolgreiche Validierung keine weitere Synchronisierung im Verfahren vorgesehen ist.

Bei jeder Code-Generierung seitens Benutzer (Sender) zählt sein Zähler um eins hoch, beim Server (Empfänger) erfolgt das Weiterzählen nur bei einer erfolgreichen Validierung. Erzeugt nun der Benutzer auf seinen Token (Codegenerator) mehrere Codes ohne diese zum erfolgreichen Validieren am Validierungsserver zu verwenden, wird sein Zähler immer weiter gezählt, während der Zählerstand am Validierungsserver gleich bleibt und die beiden Zähler damit auseinander laufen. Ungleiche Zählerstände bedeuten aber, dass die Validierung fehl schlägt.

Um diesen störenden Seiteneffekt des zählerbasierenden Verfahren etwas zu mindern wird am Server eine bestimmte Anzahl von zusätzlichen Zählerständen über den aktuellen Zählerstand hinaus akzeptiert. Dieses Intervall an zulässigen Codes wird als Validierungsfenster bezeichnet. Bei einer erfolgreichen Validierung am Server innerhalb des Validierungsfensters passt der Server seinen Zählerstand darauf an, zählt also unter Umständen seinen Zählerstände um ein Vielfaches weiter. Liegt der erzeugte HOTP-Code ausserhalb des Valdidierungsfensters ist der Zugang dauerhaft gesperrt da keine erfolgreiche Validierung und damit Angelich der Zählerstände mehr möglich ist und die Authentifizierung muss neu eingerichtet werden.

Wird dieses Validierungsfenster zu klein gewählt, können nur durch einige wenige Codegenerierungen ohne erfolgreiche Validierung der Zugang dauerhaft verunmöglicht werden. Ist hingegen das Validierungsfenster zu groß gewählt, besteht das Problem, dass dann viele Ziffernfolgen, welche den unterschiedlichen Zählerständen innerhalb dieses Fensters entsprechen, gültig sind. Ein zu großes Validierungsfenster steigert damit die Wahrscheinlichkeit durch Ausprobieren von zufälligen Ziffernfolgen um damit unberechtigten Zugang zu erlangen.

Der Nachfolger TOTP vermeidet dieses Problem der auseinander laufenden Zählerstände zwischen Sender und Empfänger und verwendet statt einen Zähler die absolute Uhrzeit, welche auf beiden Seiten, Sender und Empfänger hinreichend genau vorhanden sein muss. Zwar existiert auch bei TOTP ein Validierungsfenster, um die Ungeauigkeiten der Uhrzeiten zwischen den Systemen von Sender und Empfänger zu kompensieren, dieses Validierungsfenster von TOTP kann bei hineichend genauen Uhren bis auf einige wenige Einmalcodes (+/- 1 bis 2 TOTP Codes um die aktuelle Uhrzeit herum) reduziert werden. Der Benutzer kann bei TOTP beliebig viele TOTP-Codes in seinen Codegenerator erzeugen und diese in Folge nicht verwenden, ohne dabei Gefahr zu laufen, dadurch seinen Zugang bzw. die Validierungsmöglichkeit am Server zu verlieren.

Weblinks

• openauthentication.org – Initiative For Open Authentication.