|
|
| Zeile 59: |
Zeile 59: |
| <div class="mw-collapsible-content">'''Antwort5'''</div> | | <div class="mw-collapsible-content">'''Antwort5'''</div> |
| </div> | | </div> |
|
| |
| = TMP =
| |
| Ein '''Einmalkennwort''' oder '''Einmalpasswort''' ist ein [[Kennwort]] zur [[Authentifizierung]] oder auch [[Autorisierung]].
| |
| * Jedes Einmalkennwort ist nur für eine einmalige Verwendung gültig und kann kein zweites Mal benutzt werden.
| |
| * Entsprechend erfordert jede Authentifizierung oder Autorisierung ein neues Einmalkennwort.
| |
| * Es ist sicher gegen passive Angriffe, also Mithören.
| |
| * Auch [[Replay-Attacke]]n sind somit unmöglich.
| |
| * Gegen das Angriffsszenario [[Man-In-The-Middle-Angriff|Man in the Middle]] helfen Einmalkennwörter nicht.
| |
| * Auch hat der Einsatz von Einmalkennwörtern keinen Einfluss auf die Sicherheit einer Verschlüsselungsmethode.
| |
|
| |
| Die oft gebrauchte Abkürzung ''OTP'' steht für {{enS|one-time password}}, was der direkten Übersetzung von „Einmalkennwort“ entspricht.
| |
| * Es besteht jedoch die Gefahr einer Verwechslung mit dem Verschlüsselungsverfahren [[One-Time-Pad]], da beide mit „OTP“ abgekürzt werden.
| |
|
| |
| Die Herausforderung beim Einmalkennwort ist, wie beide Seiten wissen können, welches Kennwort für einen bestimmten Anmeldevorgang gültig ist.
| |
| * Dazu kommen zwei Möglichkeiten in Betracht: Kennwortlisten oder Kennwortgeneratoren.
| |
|
| |
| == Kennwortlisten ==
| |
| Bei diesem System werden vorgefertigte Listen von Kennwörtern auf beiden Seiten hinterlegt.
| |
| * Diese Liste wird entweder der Reihe nach abgearbeitet (d. h.: die Einträge sind durchnummeriert) oder es wird ein noch nicht benutzter Wert frei ausgewählt.
| |
| * Dieser Wert wird als Kennwort übermittelt und auf beiden Seiten aus der Liste gestrichen.
| |
| * Die [[Transaktionsnummer|TAN]]-Listen beim Online-Banking sind ein Beispiel für eine Kennwortliste.
| |
|
| |
| Zwischen den genannten Varianten besteht folgender Unterschied: Bei Einmalkennwörtern, die hintereinander, also [[Sequenz|sequentiell]], verwendet werden, gibt es zu jedem Zeitpunkt genau einen gültigen Wert, nämlich den ersten noch nicht verwendeten.
| |
| * Bei Einmalkennwörtern, die vom Absender beliebig aus einer Liste ausgewählt werden können, gibt es zu jedem Zeitpunkt genau so viele gültige Werte, wie es unverbrauchte Werte auf der Liste gibt.
| |
|
| |
| Ein Nachteil ist ein möglicher Verlust der Kennwortliste.
| |
| * Ein Angreifer, dem sie (z. B. bei einem Systemeinbruch) in die Hand fällt, kennt damit alle in Frage kommenden Einmalkennwörter.
| |
| * Ein System, das die Liste nicht komplett speichern muss, ist demnach diesem Verfahren vorzuziehen.
| |
|
| |
| == Kennwortgeneratoren ==
| |
| Ein Kennwortgenerator ist ein Programm, das automatisch ein Kennwort generiert.
| |
|
| |
| === Verfahren ===
| |
| Bei den Kennwortgeneratoren wird durch einen speziellen Algorithmus zu jedem Zeitpunkt jeweils ein aktuelles Kennwort generiert.
| |
| * Dabei müssen drei Verfahren unterschieden werden:
| |
| # Zeitgesteuerte Generatoren
| |
| # Ereignisgesteuerte Generatoren
| |
| # 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.
| |
|
| |
| ==== 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-Authentifizierung|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.
| |
|
| |
| === Verwendete Technik in den meisten Generatoren ===
| |
| 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 [[Leslie Lamport|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 <math>ggKW</math> kennen.
| |
| * Aus diesem wird nun eine Reihe von One-Time-Passwords (OTP) erzeugt.
| |
|
| |
| ==== Initialisierung ====
| |
| Konfiguriert wird das Verfahren, indem der Server und der Client mit dem gleichen Startwert <math>S</math> initialisiert werden.
| |
| Dieser berechnet sich über eine Zufallszahl <math>r_A</math>, dem sogenannten „Samen“ ({{enS|seed}}), verbunden (konkateniert) mit dem „gemeinsamen geheimen Kennwort“ <math>ggKW</math>, und einer nicht umkehrbaren, kryptographischen [[Hash-Funktion]] <math>H</math>:
| |
| :<math>S = H(r_A \ || \ ggKW)</math>.
| |
|
| |
| ==== Berechnung der One-Time-Passwords ====
| |
| Nun wird eine Reihe von One-Time-Passwords generiert, indem auf <math>S</math> mehrfach iterativ die Hash-Funktion angewandt wird: Das erste OTP entsteht, indem die Hash-Funktion <math>N</math>-mal angewandt wird: <math>KW_N = H^N(S)</math>.
| |
| * Das nächste, indem die Hash-Funktion <math>N-1</math>-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 <math>KW_N</math> auf <math>KW_{N-1}</math> 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 <math>KW_N \ = H^N(S)</math> gemerkt.
| |
| Der Client schickt als erstes OTP <math>KW_{N-1}</math> an den Server.
| |
| Dieser verifiziert es, indem er auf das neu erhaltene OTP <math>KW_{N-1}</math> einmal die Hash-Funktion anwendet
| |
| <math>H(KW_{N-1}) \ \to KW_N</math> und
| |
| das Ergebnis mit dem bei sich gespeicherten OTP <math>KW_N</math> vergleicht.
| |
| Stimmen die Werte überein, ist das OTP <math>KW_{N-1}</math> verifiziert.
| |
|
| |
| Für die nächste Verifizierung merkt sich der Server nun <math>KW_{N-1}</math> und der Client muss als nächstes OTP <math>KW_{N-2}</math> senden.
| |
|
| |
| ==== Reinitialisierung ====
| |
| Da bei jeder Authentifizierung ein neues OTP geschickt wird, und der Zähler <math>N</math> irgendwann Null erreicht, muss das OTP-System reinitialisiert werden.
| |
| * Dazu kann der Client z. B.
| |
| * selbständig einen neuen Seed <math>r_A</math> und ein neues <math>N</math> wählen und dem Server mitteilen.
| |
| * Auch kann über eine sichere Leitung ein neues gemeinsames, geheimes Kennwort <math>ggKW</math> 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-Angriff|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.
| |
|
| |
| == Beispiele ==
| |
|
| |
| === Security Token ===
| |
| [[Security-Token|Security Token]] sind [[Chipkarte]]n oder [[Schlüsselanhänger]], die einen numerischen oder [[Alphanumerische Zeichen|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 App]]s 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 [[Kennwort|Kennwörtern]], die statisch bleiben oder alle 30 bis 60 Tage ablaufen, wird das Einmalkennwort für eine [[Transaktion (Informatik)|Transaktion]] oder [[Sitzung (Informatik)|Sitzung]] verwendet.
| |
|
| |
| Wenn ein nicht [[Authentifizierung|authentifizierter]] Benutzer versucht, auf ein System zuzugreifen oder eine [[Transaktion (Informatik)|Transaktion]] auf einem Gerät auszuführen, generiert ein Authentifizierungsmanager auf dem [[Netzwerkserver]] mithilfe von OTP-[[Algorithmus|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.
| |
|
| |
| === Zwei-Faktor-Authentisierung ===
| |
| 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 [[Anwendungssoftware|Anwendung]] des [[Benutzer]]s 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 (Informationstheorie)|Kanal]] übermittelt – z. B. via [[Short Message Service|Short-Message-Service]]-basierten Textnachricht oder [[E-Mail]].
| |
| * Es wird jedoch empfohlen, zeitbasierte Einmalkennwörter ([[Time-based One-time Password Algorithmus|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.
| |
|
| |
| == Wann ist die Nutzung von One-Time-Passwords sinnvoll? ==
| |
| Die Tatsache, dass Einmalpasswörter nach kurzer Zeit ungültig werden, hindert potentielle Angreifer daran, an die Codes zu gelangen, um diese anschließend wiederzuverwenden.
| |
| * Die Verwendung von Einmalpasswörtern ist deshalb insbesondere bei Websites und Online-Diensten, bei denen besonders wichtige und sensible Daten verwendet werden, empfehlenswert.
| |
|
| |
| So zum Beispiel bei
| |
| * Sensiblen Unternehmensdaten
| |
| * Vertraulichen Kommunikationskanälen
| |
| * Online-Banking
| |
| * Finanzdienstleistungen wie Börsen für Kryptowährungen oder Online-Aktiendepots
| |
|
| |
| Einmalpasswörter sind somit nicht für jede Website dringend erforderlich.
| |
| * Allerdings empfiehlt es sich im Allgemeinen, aufgrund zunehmender Cyberkriminalität, auf sichere Passwörter zu achten.
| |
|
| |
|
| [[Kategorie:Authentifizierung]] | | [[Kategorie:Authentifizierung]] |