Einmalkennwort

Bei den Kennwortgeneratoren wird durch einen speziellen Algorithmus zu jedem Zeitpunkt jeweils ein aktuelles Kennwort generiert. Dabei müssen drei Verfahren unterschieden werden:

1. Zeitgesteuerte Generatoren
2. Ereignisgesteuerte Generatoren
3. Challenge-Response-gesteuerte Generatoren

Bei allen dreien ist es nicht der Algorithmus selbst, der übertragen wird, sondern nur der Beweis, das Ergebnis des Algorithmus. Mit dem richtigen Ergebnis weist der Client nach, dass er über den richtigen Algorithmus und, wenn nötig, die richtige Initialisierung verfügt.

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.

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.

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.

Typische Beispiele für die am häufigsten verwendeten Verfahren sind einerseits die sogenannten Token von z. B. RSA Security, ID Control, Vasco, Kobil und anderen Herstellern, andererseits etwa Implementierungen des Einmalkennworts nach Lamport (auch als Lamport Hash bezeichnet), deren Algorithmus im Wesentlichen auf dem wiederholten Anwenden einer Hashfunktion beruht.

Voraussetzung für das One-Time-Password-Verfahren ist, dass beide Beteiligte (Client und Server) ein gemeinsames, geheimes Kennwort ${\displaystyle ggKW}$ kennen. Aus diesem wird nun eine Reihe von One-Time-Passwords (OTP) erzeugt.

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)}$.

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.

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.

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.

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.

Security Token sind Chipkarten oder Schlüsselanhänger, die einen numerischen oder alphanumerischen Code zur Authentifizierung des Zugriffs auf das System erzeugen. Dieser Geheimcode ändert sich nach einigen Sekunden oder Minuten, je nachdem, wie das Token konfiguriert ist. Mobile Apps wie Google Authenticator verwenden das Token-Gerät und die Persönliche Identifikationsnummer, um das Einmalkennwort für die Bestätigung in zwei Schritten zu generieren. Security Token können mithilfe von Hardware, Software oder bei Bedarf implementiert werden. Im Gegensatz zu herkömmlichen Kennwörtern, die statisch bleiben oder alle 30 bis 60 Tage ablaufen, wird das Einmalkennwort für eine Transaktion oder Sitzung verwendet.

Wenn ein nicht authentifizierter Benutzer versucht, auf ein System zuzugreifen oder eine Transaktion auf einem Gerät auszuführen, generiert ein Authentifizierungsmanager auf dem Netzwerkserver mithilfe von OTP-Algorithmen eine Nummer oder ein gemeinsames Geheimnis. Die gleiche Nummer und der gleiche Algorithmus werden vom Sicherheitstoken auf der Chipkarte oder dem Gerät verwendet, um das Einmalkennwort und den Benutzer abzugleichen und zu validieren.

Bei der Zwei-Faktor-Authentisierung gibt der Benutzer seine Benutzer-ID, sein traditionelles Kennwort und ein temporäres Einmalkennwort ein, um auf das Benutzerkonto oder System zuzugreifen.

Bei OTP-basierten Authentifizierungsmethoden stützen sich die Anwendung des Benutzers und der Authentifizierungsserver auf ein gemeinsames Geheimnis. Werte für Einmalkennwörter werden mithilfe des Keyed-Hash Message Authentication Code und eines Bewegungsfaktors wie zeitbasierter Information oder eines Ereigniszählers generiert. Die OTP-Werte haben Minuten- oder Sekundenzeitstempel für mehr Sicherheit. Das Einmalkennwort wird dem Benutzer über einen weiteren Kanal übermittelt – z. B. via Short-Message-Service-basierten Textnachricht oder E-Mail. Es wird jedoch empfohlen, zeitbasierte Einmalkennwörter (TOTP) besser auf dem Endgerät mittels einer dedizierten App zur Zwei-Faktor-Authentisierung generieren zu lassen. Zu diesem Zweck stehen eine Reihe von Apps zur Verfügung, siehe Zwei-Faktor-Authentisierung.

Zeitlich befristete Einmalpasswörter werden auch von SecurID-Tokens generiert und von der zugehörigen Infrastruktur verarbeitet.