aufbau einer 2-faktor- authentifizierung€¦ · - spezielle hardware (tokens) erhältlich. nutzung...
TRANSCRIPT
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.