Aufbau einer 2-Faktor-Authentifizierung

Henning Brune - BIS - Universität Bielefeld

Agenda

- Vorstellung - Motivation- Konzeption - Implementierung- Erfahrungen

Was ist das BIS

BIS - Bielefelder Informationssystem - seit 1998

BIS Team gehört heute zum Dezernat IT / Orga (Zentrale Verwaltung)

Unsere Dienste:

- Campusmanagement (z. B. Prüfungsverwaltung) - Personenverzeichnis - eLearning- Identity Provider

Technologien & Nutzergruppen

J2EE für Eigenentwicklungen

● Campusmanagement, Personenverzeichnis, IdP.. ● Shibboleth, CAS

SharePoint für eLearning

Ca. 19.000 nutzende Studierende

Ca. 3.000 Nutzerinnen und Nutzer unter den Mitarbeitern

Warum 2-Faktor-Authentifizierung?

Warum sollte man den Aufwand einer 2FA betreiben?

Angriffe mit Identitätsdiebstählen sind heute unvermeidlich

Zwei Fragen stellen sich in solchen Fällen:

1) Wie kamen Angreifer an Benutzerkonten? 2) Wie kann man zukünftige Angriffe stoppen?

Wege zum Identitätsdiebstahl

- Social engineering - (Spear-)Phishing- (Schlechte) Passworte erraten- Brute force auf Login-Formular(e)- Benutzerdatenbank komplett verloren (System gehackt) - Schadsoftware / Trojaner - Keylogger Hardware

Fallbeispiel: Angriff mittels Keylogger Hardware

- Simpel und billig - Kein technisches Wissen notwendig- Schnell installiert- Jeder ‘Idiot’ kann damit ‘hacken’- Nur vor Ort / beim Nutzer zu entdecken - Einsatz nachträglich kaum nachzuweisen - Angreifer braucht physischen Zugang zum PC

Schwierige Abwehr

Herkömmliche Login-Formulare bieten keinen Schutz

● Gute Passworte werden genauso gestohlen wie schlechte● Häufige Passwortänderungen begrenzen nur die

Schadensdauer

Geringfügige Verbesserungen möglich:

‘Virtuelle‘ Tastatur

- Passworteingabe per Mausklick

- Kein Abhören möglich

- Umgehen von Tastatureingaben schützt

- Autocompletion, Passwortmanager

Anzeige von Loginvorgängen

- Einbinden der Nutzer

- Müssen / können selbst prüfen, ob eigener Account missbraucht wird

Tägliche PC Sichtkontrolle

- Jeden Morgen Tastaturkabel prüfen (oder häufiger?)

- Gerät muss zugänglich sein

- Oder: Verzicht auf externe Tastatur

- Wie weit treibt man seine Paranoia?

Fazit: Mit dem Verlust von Logindaten ist zu rechnen

Auch andere Beispiele zeigen dies:

- Anrufe eines falschen Microsoft Supports in 2015- Aktuell verbreitet sich Schadsoftware ‘Locky’ rasant - Nutzer geben Anmeldedaten bereitwillig weiter

Anmeldeverfahren allein mit Benutzername / Passwort reichen nicht aus

-> Einführung eines zusätzlichen Faktors

Charakteristika eines zusätzlichen Loginfaktors

- Nur temporär gültig / einmalig- One Time Password (wie Nonce, TAN)- Abhören ermöglicht Angreifer keinen Zugriff

- Erzeugung auf einem separaten Gerät- Zugriff auf Nutzerrechner reicht nicht für erfolgreichen Angriff- Nutzer können Loginfaktor nicht einfach weitergeben

- Kombination aus Wissen und Besitz- Wissen: Benutzername und Passwort- Besitz: Gerät zur Erzeugung des zusätzlichen Faktors

-> Wirksamer Schutz gegen viele Angriffsszenarios

Generelle 2FA Entscheidungspunkte

- Viele verschiedene Verfahren- SMS, TAN Listen, Telefonanlage, Apps, Tokens…- Verschiedene Standards

- Entscheidungsdimensionen- Kosten (initial, dauerhaft)- Supportaufwand (initial, dauerhaft)- Nutzergruppen (Art und Größe)- Kann / soll 2FA Nutzung erzwungen werden- Einsatz spezieller Hardware- Einsatz privater Hardware (Smartphones)- Integration in bestehende IT Landschaft- ...

2FA im BIS: Randbedingungen

- Kleines Team (Supportbelastung)- Kein eigenes Budget- Keinen Durchgriff auf IT Ausstattung der Nutzer- Zielgruppe sind alle Mitarbeiter/-innen

- Bei Masse der Nutzer wird Nutzung freiwillig erfolgen müssen- Bei kritischen Nutzergruppen wird 2FA durchgesetzt

- Quasi beliebige Geschäftslogik in IdP Eigenentwicklung möglich

- Benutzerverwaltung ist in unserer Hand und erweiterbar- Kapazitäten für spezielle Programmierungen vorhanden

2FA im BIS: Entscheidungen für Verfahrenswahl

- Dauerhafter Mischbetrieb aus Nutzern mit und ohne 2FA- 2FA ist ein ‘add on’, nicht die Ablösung von Benutzername / Passwort

- Supportaufwand muss sich in Grenzen halten- Z. B. keine lokalen Softwareinstallationen bei Nutzern

- Nutzung mit jedem gängigen Betriebssystem / Webbrowser- Keine dauerhaften Kosten z. B. für Lizenzen- Generierung der Einmalpassworte

- sowohl mit spezieller Hardware (Tokens)- wie auch mit (privaten) Smartphones

- Verwendung eines offenen Standards- Idealerweise vorhandener Quellcode, Apps, etc.

2FA im BIS: Entscheidung für TOTP

- Time-based One-time Password (TOTP)- Standardisiert nach RFC 6238- Grundkonzept: Aus Startgeheimnis und aktueller Uhrzeit

wird wechselnder, 6-stelliger Code errechnet- Nutzung durch Dienste wie Google, Wordpress, Dropbox,..

- Einem Teil der Nutzer daher möglicherweise bereits bekannt- Orientierung an deren Implementierungen möglich

- Java Quellcode von Google verfügbar- Apps für alle gängigen Plattformen vorhanden- Spezielle Hardware (Tokens) erhältlich

Nutzung mit Smartphone: Google Authenticator App

Nutzung mit Smartphone

● Nutzer muss TOTP Geheimnis selbst auf Smartphone bringen

● Einscannen eines QR Codes

Nutzung mit spezieller Hardware: Feitian Tokens

Nutzung mit spezieller Hardware

- Aufbau einer Geräteverwaltung- TOTP Geheimnis eingebrannt- Hersteller liefert Daten- Nutzersupport muss Tokens

Nutzern zuordnen, aber nicht in Kontakt mit Geheimnis kommen

- Tokens müssen ‘vermessen’ werden -> Gangabweichungen der internen Uhr

2FA: Abrundungen

Sind wir jetzt fertig? Noch nicht ganz:

- Wie kann man Verfügbarkeit verbessern?- Wie kann man Nutzerakzeptanz verbessern?

-> Es wird mehr als ein zweiter Faktor gebraucht

Ersatzcodes: Für Verfügbarkeit

- Was wenn Smartphone leer oder Token zu Hause vergessen?- Nutzer müssen arbeitsfähig gehalten werden- Ersatzcodes eröffnen alternativen Zugang- Konzeptionell mit TAN Listen vergleichbar- Ein Code kann genau einmal genutzt werden- System generiert Ersatzcodes bei 2FA Aktivierung- Mitnahme als Ausdruck im Portemonnaie- Maximal 5 Ersatzcodes pro Nutzer- Nutzer generieren Codes, Support sieht sie nie

Vertrauensstellungen: Für Komfort

- Tägliche Eingabe des zweiten Faktors kann ‘nerven’- Lösung: Vertrauensstellungen- Vertrauensstellung kennzeichnet einzelne Endgeräte als

‘vertrauenswürdig’- Abfrage des zweiten Faktors wird für 30 Tage unterdrückt- Benutzer können Vertrauensstellungen selbst aufheben- Technisch ein Cookie im Benutzerbrowser- 2FA Aufwand am täglich genutzten Rechner damit nahe Null

Zusammenfassung

- Implementierung von drei unterschiedlichen 2FA Verfahren- Ähnlich wie Google, Wordpress, etc..

- Zielkonflikte Sicherheit vs. Akzeptanz vs. Verfügbarkeit- Insgesamt eine komplexe Funktion- Eingebettet in grundlegende Sicherheitsfunktionen

- Angriffsabwehr- Fehlversuchszählungen

- Viele Stellschrauben- Dauer Loginsession, Anzahl Ersatzcodes, Dauer Vertrauensstellung, ..

-> Will man nicht bei jedem System erneut machen!

2FA und Identity Provider

- IdP ist ideale Stelle um diesen Aufwand zu treiben- Alle angeschlossenen Dienste erben direkt den 2FA Schutz- Eigentlich muss jeder (neue) Dienst hinter einen IdP- Offenheit für weitergehende Konzepte erreichen

- Angeschlossene Dienste sollten keine Benutzernamen mehr erhalten- Vielleicht brauchen / haben wir solche Namen bald nicht mehr!

-> Wie sind die IdPs im BIS konkret aufgebaut:

Architektur der IdPs im BIS

BIS J2EE Dienste eKVV, PEVZ,

Prüfungsverwaltung,Administration..

BIS SharePoint eLearning, Lernräume

Uni MoodleeLearning,

LernraumPlusPVP NRW

BIS IdP Shibboleth IdP

Verhältnis von BIS IdP und Shibboleth IdP

- Shibboleth IdP ist für BIS IdP ein Service Provider (SP)- BIS IdP:

- Schwerpunkt auf Loginvorgang / Sicherheitsaspekte- Halten der Loginsession (SSO, Cookies)

- Shibboleth IdP:- Schwerpunkt auf Attributweitergabe- Loginsessions werden unterdrückt

- Festlegung zugelassener SPs in beiden IdPs- Problem: Single Logout bei Shibboleth Anwendungen

- Logout erfolgt über BIS IdP. Falls nicht möglich: - Sonderbehandlung beim Login (keine Login Session, kein SSO)

Sicherheitsaufgaben des BIS IdP

- Loginprüfung- Formularhärtungen gegen XSS, UI Redressing,..

- 2FA Implementierung- Prüfung der 2FA Codes, Vertrauensstellungen

- Angriffserkennung und -abwehr- Brute force auf Passworten oder 2FA Codes ausbremsen

- Durchsetzung von Passwortrichtlinien- Passwortänderung / Passwortverbesserung / Migration Hashformat

- Kommunikation mit SPs / Diensten über Loginvorgang- Zwang zur 2FA Nutzung in bestimmten Diensten

Implementierung BIS IdP & Shibboleth Integration

- BIS IdP ist Eigenentwicklung- J2EE Anwendung auf Tomcat- Tief integriert in die BIS Benutzerverwaltung- Shibboleth Integration nutzt vorhandenen BIS Code für

J2EE SPs- Filter auf Remote User Authentication Servlet- Sessionhandling von Shibboleth musste verstanden und modifiziert

werden

- BIS IdP macht keine Attributweitergaben- Nur eindeutiges Benutzermerkmal

Erfahrungen bisher

- 2FA Option seit ca. einem Jahr im IdP implementiert- Bisher: Langsamer Rollout bei kritischen Benutzergruppen- Tokens und Smartphone Apps- Zugang zu bestimmten Diensten nur noch mit 2FA Login- 2FA tut, wofür sie gedacht war- Ausdehnung auf weitere Nutzergruppen

- Marketing für freiwillige Nutzung - Vorgabe für weitere Nutzergruppen

- BIS SSO wird immer mächtiger -> Schutz um so wichtiger- Benutzer begreifen 2FA teilweise als Entlastung

Supportaufwände für Token Nutzer

- Einmaliger Aufwand bei Ausgabe hoch- Verknüpfung von Benutzern und Tokens im System (Tokenvermessung)- Direkte Übergabe vor Ort bei Nutzern- Verbunden mit Schulung, Ausdruck Ersatzcodes, ..

- Aufwände während der Nutzung meist gering- Ein Teil der Tokens hat ungenaue Uhren- Neuvermessung wie bei Erstausgabe notwendig- Einzelne Geräte ausgesondert

- Frage der sicheren Aufbewahrung der Tokens ist immer wieder ein Thema- Einzelne Nutzer finden Tokens zu klobig für Schlüsselbund

Supportaufwände für Smartphone Nutzer

- Erfahrungen bisher noch geringer als bei Tokens- Nutzer haben Kontrolle über 2FA Aktivierung- Nutzer auf Android, iOS und Windows Phone- Heute nur private Geräte- Auch Smartphones können Uhrzeitabweichungen haben- Frage der sicheren Aufbewahrung stellt sich hier nicht

- Niemand lässt sein privates Smartphone Nachts im Büro

Weitere Infos:

https://ekvv.uni-bielefeld.de/wiki/en/2FA

Vielen Dank.