Je höher der Wert der zu schützenden Informationen, desto sicherer muss das eingesetzte Authentifizierungsverfahren sein. Die Sicherheit von Authentifizierungsvorgängen lässt sich durch Kombination mehrerer Faktoren (sogenannte Multifaktor-Authentifizierung) signifikant erhöhen. So kombiniert zum Beispiel die EC-Karte schon immer die Faktoren "Wissen" und "Besitz", denn der Benutzer muss sowohl im Besitz der Karte mit Magnetstreifen/Chip sein als auch über die zugehörige PIN verfügen. Noch sicherer wird ein Verfahren aber, wenn zu den Faktoren "Wissen" und "Besitz" noch ein biometrischer Faktor hinzukommt.
Für die meisten Sicherheitsanforderungen dürfte aber eine Authentifizierung mit zwei Faktoren bereits ausreichen. So empfiehlt das Bundesamt für Sicherheit in der Informationstechnolgie (BSI) in den Grundschutzkatalogen beispielsweise den Einsatz von Zwei-Faktor Authentifizierungslösungen für die Authentifzierung von Remote-Access VPN-Benutzern. Und auch der Payment Card Industry Data Security Standard (PCIDSS) – ein verbindliches Regelwerk im Zahlungsverkehr für die Abwicklung von Kreditkartentransaktionen – fordert für den Netzwerkzugriff von Administratoren, Mitarbeitern und Dritten von extern den Einsatz einer Zwei-Faktor Authentifizierung.
Die Anzahl an Multi-Faktor-Authentifizierungslösungen ist in den letzten Jahren kontinuierlich gestiegen. Wer den Einsatz einer solchen Lösung plant, sollte daher schon vorab eine Entscheidung darüber treffen, ob er mit Zertifikaten und/oder Einmalpassworten arbeiten möchte. Bei der zertifikatsbasierten Zwei-Faktor-Authentifizierung kommen typischerweise digitale Zertifikate nach dem X.509-Standard zum Einsatz, was gleichzeitig den Aufbau einer PKI (Public Key Infrastruktur) erfordert. Die Zertifikate werden dann auf einem speziellen Zertifikatsspeicher (Security-Token) abgelegt.
Zur Authentifzierung muss der Benutzer das Security-Token über eine USB- oder SmartCard-Schnittstelle mit dem Gerät verbinden, von dem aus er sich am jeweiligen Dienst anmelden möchte und das gespeicherte Zertifikat durch die Eingabe einer PIN oder eines Passworts freischalten. Erst dann kann zum Beispiel der VPN-Client erfolgreich eine Verbindung mit dem Zielsystem aufbauen. Als Hardware kommen spezielle USB-Sticks oder SmartCards zur Speicherung von elektronischen Zertifikaten und Passworten in Frage. Der praktische Vorteil von USB-Tokens gegenüber SmartCards besteht vor allem darin, dass sich diese am USB-Anschluß des jeweiligen Computers betreiben lassen, während für Smartcards ein zusätzliches Kartenlesegerät erforderlich ist.
Eine gute Alternative zum Zertifikatsspeicher bilden Einmalpasswortgeneratoren, die sogenannten OTP-Token (One Time Password). Diese gibt es in verschiedenen Formfaktoren, zum Beispiel als Hardware, Software oder Grid-Card und natürlich auch "as a service", in diesem Fall dann typischerweise in Form von SMS. OTP-Tokens stellen dem Anwender ein kurzlebiges Einmalpasswort für die Anmeldung zur Verfügung. Je nach Hersteller und verwendeter Methode unterscheidet man Time-Based beziehungsweise Time-Synchronized Tokens (TOTP = Time-Based One-Time Password Algorithm, gemäß RFC 6238) und Event-Based Tokens (HOTP = HMAC One-Time Password Algorithm nach RFC 4226). Hardware-basierende Time-based Tokens sind in der Regel etwas teurer, weil sie als Zähler zur Berechnung ihrer OTPs eine ganggenaue Uhr benötigen, die zusätzlich mit der Hardware verbaut werden muss. Ein großer Vorteil von Einmalpasswortgeneratoren gegenüber Zertifikatsspeichern/SmartCards ist außerdem, dass sie am Client keinen Treiber für den Security Token erfordern.
Eine Middleware fügt eine zusätzliche Diensteschicht zwischen Anwendungen ein und übernimmt dabei spezifische Aufgaben. Bei LinOTP handelt es sich um eine klassische Middleware, denn das Produkt übernimmt die Aufgabe des Authentifizierungsproviders und stellt Schnittstellen für verschiedene Anwendungen bereit. So kommuniziert LinOTP auf der einen Seite mit Verzeichnisdiensten, in denen die Benutzerinformationen gespeichert sind (LDAP, Active Directory und so weiter), und stellt auf der anderen Seite eine Abstraktionsschicht für verschiedene Token-Provider bereit, zum Beispiel Einmalpasswortgeneratoren verschiedener Hard- und Software Hersteller.
Die Kommunikation zur eigentlichen Ziel-Anwendung erfolgt wiederum über klassische Authentifizierungs-Schnittstellen wie PAM, RADIUS oder OpenID, die von LinOTP ebenfalls bereitgestellt werden. Mit LinOTP erhalten Administratoren also zum einen eine Plattform zur Einführung einer herstellerunabhängigen Zwei-Faktor Authentifizierung, zum anderen lassen sich bereits vorhandene Authentifizierungssysteme integrieren. Die Herstellerunabhängigkeit ergibt sich dabei vor allem aus der konsequenten Unterstützung des OATH-Standards, der eine Referenzarchitektur für eine starke Authentifizierung auf Basis offener Standards (HOTP / TOTP / OCRA) beschreibt [1].
Die flexible und modulare Systemarchitektur prädestiniert LinOTP als zentrale Authentifizierungsinstanz für die starke Authentifizierung in heterogenen Umgebungen. Dabei spielt es keine Rolle, ob einzelne Dienste bereits über eine Zwei-Faktor-Authentifizierungslösung gesichert werden oder diese mit LinOTP grundsätzlich erst eingeführt werden soll. Die konsequente Ausrichtung auf Open Source und offene Standards wie OATH hilft den sprichwörtlichen "Vendor Lock-In" zu vermeiden. Basis für Authentifizierungsvorgänge sind bereits vorhandene Datenbanken oder Verzeichnisdienste, die LinOTP über entsprechende Schnittstellen – bei LinOTP UserIDResolvers genannt – anspricht.
Mit Microsofts Active Directory, dem Novell eDirectory und OpenLDAP kommuniziert LinOTP bereits out-of-the box. Alternativ stehen eine SQL-Schnittstelle und die Unterstützung von Flat Files zur Verfügung. Flat-File-Datenbanken basieren in der Regel auf Text-Dateien mit strukturierten Feldtrennern. Bekannte Beispiele dafür sind CSV (comma separated value) beziehungsweise DSV (delimiter separated value). Im einfachsten Fall kann so beispielsweise eine Linux-Passwortdatenbank ("/etc/passwd") zum Einsatz kommen.
Für die Kommunikation mit den Applikationen beziehungsweise Benutzern stellt LinOTP ebenfalls eine standardisierte Schnittstelle bereit. Dieses auch "Triple-A" oder "AAA" (Authentication, Authorization, Accounting) genannte Modul besteht bei LinOTP aus einem ganzen Bündel von Open Source-Komponenten: Die interessanteste - weil betriebssystemübergreifend praktisch von allen wichtigen Anwendungen unterstützt - ist die RADIUS-Schnittstelle, die LinOTP in Form von FreeRADIUS beziehungsweise Radiator bereitstellt. Für Linux und andere Unix-artige Betriebssysteme ist dagegen PAM (Pluggable Authentication Module) erste Wahl. Weitere Module sind ein LDAP-Proxy, Apache Basic Authentica-tion, SAML / OpenID und die Web API, die zum Beispiel für Wordpress, aber auch für andere Web-Applikationen genutzt werden kann.