Da ich mich seit einiger Zeit mit 2-Faktor-Authentifizierung befasse, habe ich mich von der praktischen Nutzung vor einigen Tagen nochmals zurückbesonnen auf die Theorie dahinter: Das Verfahren, das beispielsweise hinter Googles Authenticator steckt, ist in einer RFC beschrieben.

Nach einer Google-Recherche stieß ich auf die im Titel genannte RFC 6238, die eine Beispielimplementierung des Time-based One-Time Password-Algorithm enthält. Diese ist bereits in Java gehalten. Nach einem Trockentest, bei dem ich in einem Java-Programm das Token erzeugte und mit einem durch die offizielle Google-Authenticator-App erzeugten verglich, konnte es ans Eingemachte gehen:

Die Java Advanced Authentication Software JAAS ist ein System zur Authentifizierung und Autorisierung in Java-Anwendungen. Die Architektur ist modular aufgebaut, so dass die Mittel zur Authentifizierung deklarativ beim Programmstart spezifiziert werden und demzufolge auch unkompliziert ausgetauscht werden können (LoginModule).

Die Autorisierung erfolgt über Principals, die nach erfolgter Authentifizierung zugeordnet werden. In einer Anwendung, die dieses Framework nutzen möchte, muss ein CallbackHandler registriert werden, der die verschiedenen Anforderungen des jeweiligen LoginModules erfüllen kann: Ein einfaches Login-Modul könnte zum Beispiel einen Usernamen und ein Passwort gegen eine Datenbank prüfen. Dann benötigt es natürlich einen Nutzernamen und ein Passwort. Dafür sind im Framework verschiedene Callbacks definiert: unter anderem für UserName, Password und beliebige Texteingaben.

Da ich mit dWb+ bereits eine Anwendung pflege, die die unterschiedlichen Rechte mittels JAAS verwaltet, lag die Idee nahe, RFC 6238 hiermit zu testen: Der CallbackHandler, der hier zum Einsatz kommt, zeigteinen Dialog mit einem Texteingabefeld und einem Passworteingabefeld an und setzt die dort eingetragenen Werte in die entsprechenden Callbacks ein. Ich fügte einen weiteren Callback zum LoginModule und zum CallbackHandler hinzu, der das jeweilige One Time Password transportiert. Den Login-Dialog änderte ich nicht. Statt dessen traf ich eine Festlegung wie folgt: Das Token wird an den Nutzernamen angehängt. Da das Token immer sechs Zeichen lang ist, kann ich die letzten sechs Zeichen des Nutzernamens einfach abschneiden und diese an den Callback für das Token weitergeben. Was dann übrig bleibt, wird wie vorher an den UserName-Callback weitergereicht.

Nach dieser Umstellung der Authentifizierung konnte ich erfolgreich entsprechende Tests durchführen: Die Anmeldung an der Anwendung funktionierte nun nur noch mit dem korrekten One Time Password: Ein Versuch ohne OTP schlägt genauso fehl wie ein Versuch ohne Angabe eines OTP.

Damit ist die prinzipielle Funktionsweise nachgewiesen - allerdings verbietet sich eine solche Implementierung im Produktivbetrieb natürlich, weil das gemeinsame Secret zu Testzwecken fest im Quelltext verankert wurde - in Produktivsystemen muss spezielle Sorge dafür getragen werden, das Secret so abzulegen, dass kein Unberechtigter es auslesen kann!

Artikel, die hierher verlinken

Kommentar hinzufügen (via ) Kommentare ansehen (via )

Kommentar hinzufügen (via ) Kommentare ansehen (via )