Aufbau einer 2FaktorAuthentifizierung 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 2FaktorAuthentifizierung? 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 LoginFormular(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 LoginFormulare 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 Timebased Onetime Password (TOTP) Standardisiert nach RFC 6238 Grundkonzept: Aus Startgeheimnis und aktueller Uhrzeit wird wechselnder, 6stelliger 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:
Shibboleth IdP BIS IdP BIS J2EE Dienste ekvv, PEVZ, Prüfungsverwaltung, Administration.. Architektur der IdPs im BIS BIS SharePoint elearning, Lernräume Uni Moodle elearning, LernraumPlus PVP NRW
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.unibielefeld.de/wiki/en/2fa Vielen Dank.