Zwei-Faktor-Authentifizierung

Transkript

1 Zwei-Faktor-Authentifizierung Impulsvortrag im Rahmen des ZKI Arbeitskreises Verzeichnisdienste 14./15. März 2016 in Marburg

2 Kurzüberblick Token-Typen I Algorithmen HOTP (HMAC-based One Time Password, auch: Event-based) HMAC(Shared Secret, Shared Counter) TOTP (Time-based One Time Password HMAC(Shared Secret, Current Time) Challenge-Response Standards OATH HOTP (RFC 4226) OATH TOTP (RFC 6238) FIDO U2F (Universal Second Factor) Public Key Cryptography + Challenge-Response 2

3 Kurzüberblick Token-Typen II Umsetzung auf Nutzer-Seite Software-Tokens bzw. Token Management Softwares auf dem Smartphone Google Authenticator (OATH HOTP, OATH TOTP) Sophos Authenticator (OATH HOTP, OATH TOTP) RedHat FreeOTP (OATH HOTP, OATH TOTP) Hardware-Tokens Tokens in allen Größen, Formen und Farben Tokens mit oder ohne Uhr und Batterie Initialisierbarkeit durch Hersteller, Anbieter, Kunde oder Nutzer Schnittstellen: Papier zum Ablesen, Display zum Ablesen, Chipkarte, RFID, USB 3

4 Kurzüberblick Token-Typen III 4

5 Entscheidung über die verwendeten Token-Typen Software-Tokens Google Authenticator (OATH HOTP, OATH TOTP) Sophos Authenticator (OATH HOTP, OATH TOTP) RedHat FreeOTP (OATH HOTP, OATH TOTP) Hardware-Tokens Einfache, langlebige, initialisierbare, kleine und portable HOTP- Tokens mit USB-Keyboard-Schnittstelle Papierlisten im Chipkarten-Format (Entweder als obligatorische Backup-TAN-Liste oder als Alternative zu Hardware- und Software-Tokens) 5

6 Kurzüberblick 2-FA-Server-Typen I Closed Source vs. Open Source Cloud Service vs. In-House Service Entscheidung über den verwendeten Authentifizierungs- Server 6

7 Kurzüberblick 2-FA-Server-Typen II Closed Source Kommerzieller Support i.d.r. möglich Abhängigkeit von externem Anbieter, und damit von dessen zukünftiger Existenz, Produktpflege, Produktplanung Art und Weise der Speicherung der Tokens sowie deren Sicherheit ist nicht bekannt oder kann nicht überprüft werden Für einen Export der Tokens bestehen in der Regel keine Schnittstellen, was den Weg zum Vendor-Lock-In eröffnet Mehr oder weniger teure Abrechnungsmodelle je Zeitraum, Benutzer-Anzahl und Support-Level Open Source Kommerzieller Support i.d.r. möglich Keine relevante Abhängigkeit von externem Anbieter, da Komplexität der Logik und des Quellcodes niedrig ist Art und Weise der Speicherung der Tokens sowie deren Sicherheit ist bekannt und kann überprüft werden Für einen Export der Tokens bestehen Schnittstellen oder es können selbst Schnittstellen entwickelt werden, was einen Vendor-Lock-In ausschließt Kosten i.d.r. nicht je Nutzer, sondern bei Inanspruchnahme von optionalem Support 7

8 Kurzüberblick 2-FA-Server-Typen III Cloud Eventuell weniger Aufwand im Betrieb, allerdings entfällt der Aufwand für Anbindung der Dienste und den Nutzer- Support nicht Abhängigkeit von externer Netz-Anbindung Abhängigkeit von externen Rechenzentren Es ist unklar, wo die Daten gespeichert sind In-House Eventuell höherer Aufwand im Betrieb Unabhängigkeit von externer Netz- Anbindung Unabhängigkeit von externen Rechenzentren Es ist klar, wo die Daten gespeichert sind 8

9 Entscheidung über den verwendeten 2-FA-Server OpenSource- und In-House-Strategie Konkret LinOTP: Seit 2014 intern erfolgreich getestet, aber auf einem abgekündigten Web-Framework basierend (Stand: März 2016) PrivacyIDEA: Seit 2016 erfolgreich getestet und in Sachen Web-Framework und Funktionsumfang eine deutlich überarbeitete Fork von LinOTP (Stand: März 2016) 9

10 LinOTP / PrivacyIDEA I Python Web Application Pylons Web Application Framework / Flask Web Application Framework Betrieb via WSGI (Web Server Gateway Interface) hinter HTTPS-Server 10

11 LinOTP / PrivacyIDEA II LDAP-User-Resolvers zur Verwaltung unterschiedlicher User- und Admin-Realms SQL-Datenbank-Interface für Tokens, Admin-Users und Policies REST-Interface für Authentisierung, Administration und Self- Service CLI-Interface für Administration, Authentisierung, Ausrollen von Hardware-Tokens Web-User-Interface für Administration und Self-Service 11

12 Anbindung der Dienste an den 2FA-Server 2FA-LDAP-Proxy Kompatibel zu jedem bisher an LDAP-Auth angebundenen Dienst mit normalem Username-Passwort-Anmelde-Dialog Wird zwischen Dienst und LDAP eingerichtet Leitet die LDAP-Anfragen mit Dienst-Proxy-User oder Anonymous-User ungefiltert weiter an den LDAP-Server (z. B. hole DN des Benutzernamens ) Leitet die LDAP-Anfragen des eigentlichen Users erst an den LDAP-Server weiter, wenn Username + Passwort + Einmalpasswort am 2FA-Server erfolgreich validiert wurden; Meldet andernfalls fehlgeschlagene Authentisierung 12

13 Herausforderungen I Konzeption zentraler Authentifizierungs-Richtlinien Konfiguration des 2FA-Servers entsprechend der Richtlinien Schrittweise Anbindung der Dienste (z. B. Web-Dienste, Windows-Login, etc.) Evtl. Anpassung der Dienst-Login-Dialoge 13

14 Herausforderungen II Konzeption von Workflows für das Ausrollen der Tokens und den anschließenden Support Initiales Ausrollen von Hardware-Tokens an Netzbeauftragte der Fachbereiche Initiales Ausrollen von Hardware-Tokens an Mitarbeiter Initiales Ausrollen von Software-Tokens an Studenten Support für Tokens und Authentisierung (Sperren, Entsperren, Ausrollen, Auditing) 14

15 Vielen Dank für Ihre Aufmerksamkeit! 15