Zeitgesteuert

Obwohl der Server jeweils dieselbe Berechnung wie der Client (der Security-Token) ausführt, akzeptiert und berechnet er im Allgemeinen innerhalb eines Toleranzbereichs mehrere Einmalkennwörter, da die im Token eingebaute Uhr eventuell nicht hundertprozentig exakt geht. Dennoch hat jedes Einmalkennwort ein genau definiertes Zeitintervall für seine Gültigkeit, das in der Regel zwischen 1 und 15 Minuten liegt.

Dazu ein kurzes Beispiel eines Tokens, das jede Minute sein Einmalkennwort ändert. Das Einmalkennwort ist jedoch nicht nur zum Zeitpunkt t gültig, sondern wird serverseitig wegen der Toleranz auch zum Zeitpunkt t − 1 min und t + 1 min und damit drei Minuten lang akzeptiert. Gute Verfahren synchronisieren sich anhand der eingehenden Daten auf den Client. Bei längeren Unterbrechungen zwischen den Anmeldungen kann aber auch dies fehlschlagen.

Bei Verwendung eines einzigen Tokens bei mehreren unabhängigen Stellen würde sich bei einem Ablauschen des Einmalkennworts bei einer Stelle ein Sicherheitsrisiko für die anderen Stellen innerhalb des Toleranzbereiches eröffnen.

Ereignisgesteuert

Auch bei dem ereignisgesteuerten Verfahren führt der Server wie beim zeitgesteuerten dieselbe Berechnung aus, die auf der Client-Seite stattgefunden hat, und auch hier berechnet und akzeptiert er in einem Toleranzbereich mehrere Einmalkennwörter, ausgenommen schon verwendeter. Der Grund ist, dass der Besitzer gelegentlich ein generiertes Kennwort nicht verwenden könnte. Dieses Verfahren ist viel schonender für die Batterien eines entsprechenden Gerätes (Token). Es ist auch möglich, es ohne permanente Stromversorgung zu betreiben, indem einfach der letzte verwendete und damit ohnehin entwertete Wert gespeichert wird.

Bei einer Verwendung eines einzigen Tokens bei mehreren unabhängigen Stellen müssen alle Stellen zeitnah über jede Verwendung bei irgendeinem Ereignis informiert werden.

Challenge-Response-gesteuert

Synchronisationsprobleme gibt es im Falle eines Challenge-Response-Verfahrens nicht. Bei diesem Verfahren gibt der Server eine Aufgabe (Challenge) vor, die der Client beantworten muss (Response). Der Client erhält also einen Wert des Servers als Eingabe und berechnet darauf basierend ein Einmalkennwort.

Der Vorteil dieses Verfahrens ist, dass die Challenge völlig unabhängig gestellt werden kann. Gibt es auf der Server-Seite keinen Algorithmus, der sich vorausberechnen lässt, dann gibt auf der Client- bzw. Cracker-Seite keine Möglichkeit, eine Response im Voraus zu berechnen. Damit ist auch die Verwendung eines einzigen Algorithmus bei mehreren unabhängigen Stellen möglich, die Sicherheit wird dadurch nicht reduziert. Es gibt Lösungen, die mit einem Gerät (Token) die Response berechnen. In diesem Fall kann auch die unten beschriebene Technik zur Anwendung kommen, mit dem Initialwert als Challenge.

Initialisierung

Konfiguriert wird das Verfahren, indem der Server und der Client mit dem gleichen Startwert ${\displaystyle S}$ initialisiert werden. Dieser berechnet sich über eine Zufallszahl ${\displaystyle r_{A}}$, dem sogenannten „Samen“ (englisch seed), verbunden (konkateniert) mit dem „gemeinsamen geheimen Kennwort“ ${\displaystyle ggKW}$, und einer nicht umkehrbaren, kryptographischen Hash-Funktion ${\displaystyle H}$:

${\displaystyle S=H(r_{A}\ ||\ ggKW)}$.

Berechnung der One-Time-Passwords

Nun wird eine Reihe von One-Time-Passwords generiert, indem auf ${\displaystyle S}$ mehrfach iterativ die Hash-Funktion angewandt wird: Das erste OTP entsteht, indem die Hash-Funktion ${\displaystyle N}$-mal angewandt wird: ${\displaystyle KW_{N}=H^{N}(S)}$. Das nächste, indem die Hash-Funktion ${\displaystyle N-1}$-mal angewandt wird. Ein möglicher Mithörer kann aus dem verschickten Kennwort nicht das Nächste berechnen, da er dazu die Hash-Funktion invertieren müsste, um von ${\displaystyle KW_{N}}$ auf ${\displaystyle KW_{N-1}}$ zu kommen. Dies ist jedoch unmöglich.

Verifizierung des OTP beim Server

Der Server hat initial die gleiche Operation durchgeführt wie der Client und sich nur ${\displaystyle KW_{N}\ =H^{N}(S)}$ gemerkt. Der Client schickt als erstes OTP ${\displaystyle KW_{N-1}}$ an den Server. Dieser verifiziert es, indem er auf das neu erhaltene OTP ${\displaystyle KW_{N-1}}$ einmal die Hash-Funktion anwendet ${\displaystyle H(KW_{N-1})\ \to KW_{N}}$ und das Ergebnis mit dem bei sich gespeicherten OTP ${\displaystyle KW_{N}}$ vergleicht. Stimmen die Werte überein, ist das OTP ${\displaystyle KW_{N-1}}$ verifiziert.

Für die nächste Verifizierung merkt sich der Server nun ${\displaystyle KW_{N-1}}$ und der Client muss als nächstes OTP ${\displaystyle KW_{N-2}}$ senden.

Reinitialisierung

Da bei jeder Authentifizierung ein neues OTP geschickt wird, und der Zähler ${\displaystyle N}$ irgendwann Null erreicht, muss das OTP-System reinitialisiert werden. Dazu kann der Client z. B. selbständig einen neuen Seed ${\displaystyle r_{A}}$ und ein neues ${\displaystyle N}$ wählen und dem Server mitteilen. Auch kann über eine sichere Leitung ein neues gemeinsames, geheimes Kennwort ${\displaystyle ggKW}$ vereinbart werden. Bei vielen, heute verwendeten Token ist jedoch eine Kommunikation über den Wert selbst hinaus nicht vorgesehen.

Sicherheit

Da kryptographische Hash-Funktionen nicht invertierbar sind, kann das geheime Kennwort nicht in Erfahrung gebracht werden. Auch ist das System gegen Replay-Attacken geschützt, da jedes Mal ein neues Kennwort übertragen wird.

Authentifiziert wird aber nur der Client vom Server. Der Server authentifiziert sich hingegen nicht beim Client. Somit kann ein Angreifer einen eigenen Server im Netzwerk installieren und dem Client vorgaukeln, dass dieser Server der Authentifizierungs-Server sei.