Web Single Sign-On Nutzen eines optimalen Zusammenspiels von Authentisierung und WAF Marc Bütikofer Senior Security Engineer Kryptologie & Security Experte Ergon Informatik AG

Facts & Figures Ergon Informatik AG Gegründet 1984 160 Mitarbeitende 90% mit Hochschulabschluss 29.6 Mio CHF Umsatz (2011) In Mitarbeiterbesitz Standort Zürich Aufteilung des Umsatzes nach Branchen 32% Industry/Pharma 29% Telecommunications 25% Finance 14% Public Sector 53% davon mit Dienstleistungen, 47% mit Produkten/Lösungen Prix Egalité 2011

Kompetenz in IT Security: Airlock und Medusa WAF: Airlock (500 Installationen bei 200 Kunden) Authentisierung: Medusa (70 Kunden) 25 Mitarbeiter im Thema WAF / Authentisierung Produkte kurz erwähnen Breite Kundenbasis Erfahrungen Verbindung zu Infotrust

Übersicht Typische Ausgangslage Zielarchitektur mit WAF und Authentisierung Warum eine WAF? Warum separate Authentisierung? Möglichkeiten aus Zusammenspiel WAF + Authentisierung, Single Sign-On, Identity Propagation Starke Authentisierung auf Mobiltelefonen

Typische Ausgangslage Login mit Credential-Set C Kein oder direkter Zugriff auf aus dem Internet auf Webapplikationen Schwache Authentisierung in Applikationen Verschiedene Identitäten/Credential-Sets Credential-Set A Login mit Credential-Set B Login mit Grundannahme: - Zugang zu Webapplikationen (auch Apps) ermöglichen oder absichern Ausgangslage A x Applikationen mit eigenen Authentisierungsseiten schwache Authentisierung, kein oder geringer Schutz vor Angriffen Wunsch nach starker Authentisierung z.T. Wunsch nach SSO und zentraler Verwaltung Ausgangslage B Eine Applikation absichern Es tauchen im Projekt noch mehr interessante Applikationen auf A B C D geschützte Applikationen Externe Applikation Firmennetzwerk

WAF und vorgelagerte Authentisierung Cross Domain SSO Firmennetzwerk WAF Authentisierung A B C D geschützte Applikationen Externe Applikation

Weshalb eine Web Application Firewall?

Schlüsselkriterien für Webapplikationssicherheit WER? Wer greift zu? Zugriffskontrolle Whenever dealing with security (e.g. look at the airport or soccer stadium example) we need to address these two fundamental questions airlock provides the necessary means to control these questions efficiently and effectively for entire web environments WAS Was wird geschickt? Filterung

Wichtige Themen Webapplikationssicherheit So far we talked about filtering requests and data to protect web applications (blue circles). However, strong authentication enforcement with secure session handling is equally if not even more important if applications with authenticated users should be protected. Additionally, other management, monitoring and availability aspects are also very important if an organization wants to address the web application security topic. airlock as only solution combines all key aspects of web application security and represents a comprehensive, strategic solution.

Warum vorgelagerte und zentrale Authentisierung? Höchste Anforderungen Exponiert und mächtig Keine Kommunikation mit geschützten Applikationen vor der Authentisierung Komplexe Workflows Integrationskosten Flexibilität bezüglich Token Policies zentral umsetzbar Kostenersparnisse

Vielzahl von Authentisierungsmittel Passwortprüfung, Password Policy Enforcement Point Hardware OTP Generatoren(SecurID, VASCO Digipass, KOBIL OTP) Client-Zertifikate (SmartCard, USB Stick, SuisseID) Hardened Browser mit Client-Zertifikat-Stick Flickering Devices Challenge-Response Verfahren Integrierte Authentisierungsdienste Umfassende Matrixkartenlösung Mobile TAN (mTAN SMS) Mobile OTP

Möglichkeiten dank WAF und zentraler Authentisierung Client Certificate Mobile ID Mobile TAN SAML SP Cross Domain SSO with SAML Firmennetzwerk Airlock Kerberos/ Smart Card Medusa Password Management/ Transaction Signing Radius Client A B C D Mobile TAN Mobile OTP Database/ Directory PKI Geschützte Applikationen Externe Applikation

Identity-Propagation Single Sign-On und Identity-Propagation Client Certificate Mobile ID Mobile TAN SAML SP Cross Domain SSO with SAML Domänenübergreifender SSO Domänenübergreifender SSO Firmen- netzwerk Airlock Interner SSO Kerberos/ Smart Card Medusa Password Management/ Transaction Signing Inhalt: Verschiedene Arten der ID Propagation kurz vorstellen: Via Airlock Cookie Store / Header Store (evt. auch Kerberos, Basic-Auth, etc. erwähnen). Gemeinsam ist hier, dass alles via WAF geht und nichts via Browser Via SAML (Logoutproblematik, Grenzen aufzeigen) Wann ist SAML (et al.) angebracht, wann etwas einfacheres Art der ID-Propagation ist meist von bestehenden Systemen beeinflusst  Migrationspfade müssen möglich sein (evt. Allianz als kommendes Beispiel erwähnen) Mehrere Arten der ID Propagation müssen nebeneinander möglich sein Rolle als „Service Provider“ (Empfänger von SSO Tickets) auch als Authentisierungsart anschauen  Rest der Integration gleich Ziele: Verstehen von verschiedenen ID Propagation Methods „Trends“ wie SAML hinterfragen und differenzierter betrachten Verstehen, dass Authentisierung auch sehr viel mit Integration resp. Integrationsfähigkeit zu tun hat Radius Client A B C D Mobile TAN Mobile OTP Database/ Directory PKI Geschützte Applikationen Externe Applikation

Unabhängigkeit von Authentisierung und Identity Propagation Client Certificate Mobile ID Mobile TAN SAML SP Cross Domain SSO with SAML Corporate Network Airlock Kerberos/ Smart Card Medusa Password Management/ Transaction Signing Inhalt: Trennung von Authentisierung und ID Propagation beleuchten Vorteile: Unabhängigkeit, Einfachere Integration von Appls + Einfachere Integration von Authmethoden Macht WAF + Authentisierung als „Infrastruktur“ vielseitiger verwendbar und damit kosteneffizienter Auch SAML SP oder z.B. Kerberos sind mögliche Authentisierungsprozesse  integrierbare mit vorhandenen Systemen (e.g. IG B2B oder corporate Windows Infrastruktur) -SAML SP als Überleitung zu Anwendungsszenario bei Allianz (Allianz verwendet Medusa als SAMP SP aber nicht nur) Ziele: Verstehen, weshalb eineTrennung zwischen Authentisierung und ID-Propagation Sinn macht Verstehen, dass auch extern Authentisierungsprozesse so weitergegeben werden können (SSO, SAML, Kerberos) Radius Client A B C D Mobile TAN Mobile OTP Database/ Directory PKI Geschützte Applikationen Externe Applikation

Starke Authentisierung auf Mobiltelefonen

Mobile Trojaner sind Realität Smartphones werden auch aktiv attackiert. Bereits gibt es mit ZitMo und SpitMo Trojaner, die auch Smartphones infizieren. Das Ziel dieser mobilen Trojaner ist es, sogennante SMS TANs abzufangen und an den Angreifer weiterzuleiten. ZitMo war sogar kurze Zeit im offiziellen Android Market als Sicherheits-App aufgeführt. -- Infection: User benutzt E-banking Trojaner blendet Nachricht ein: Bank bietet mobile App an um das Abfangen von SMS zu verhindern © Trusteer 2011 ZitMo and SpitMo (Zeus/SpyEye in the Mobile) Fangen SMS (mTAN) ab ZitMo wurde sogar während kurzer Zeit im offiziellen „Android Market“ als Security Tool angeboten

Starke Authentisierung auf Mobiltelefonen Zu welchem “Preis”? SMS/MTAN geht nicht mehr! Wenig Schnittstellen Kandidaten: - Mobile Signature Service (“Mobile ID”)? - Flickering / Barcode? - HW OTP? Motivate security requirements that will follow by enumerating a few practical use cases.

Starke Authentisierung und Transaktionssignierung auf Mobiltelefonen Benötigte zweiten unabhängigen Kommunikationskanal Transaktionsbestätigung Trotz aller Bemühungen kann man nie 100% sicher sein, dass der Kunden-PC sauber ist. Als letztes Mittel bleiben dann die sogenannten Transaktionsbestätigungen. D.h. die Bank muss verdächtige Transaktionen vom Benutzer über einen 2., unabhängigen Kanal bestätigen lassen. Mögliche Kandidaten für 2. Kanäle sind SMS aufs Handy Automatisierte Telefonanrufe Ein externes Gerät, welches lediglich verschlüsselte Daten über den PC schickt Man sieht hier auch gleich, dass diese Kanäle gut funktionieren, wenn man E-Banking auf dem Desktop macht. Wenn man jedoch das Smartphone dafür benutzt, Sind SMS und die Telefonanrufe keine unabhängigen Kanäle mehr Auch werden die Kunden kaum ein externes Gerät mit sicher herumtragen, das beinahe gleich gross ist wie das Handy selbst mTAN (SMS) Automatisierte Anrufe ? Separates Token

Mobile Signature Services (MSS) – Die Lösung? 1. Application request (UMTS) 2. Check 2nd factor 6. Yes/no MSS Provider Please enter your PIN: 3. 2nd factor OK? (SMS) 4. Challenge user Mobile Signature Services (MSS) verwendet das Handy selbst als Token. Der Benutzer kriegt eine SIM Karte mit SmartCard Chip, Zertifikat und einer Authentisierungs-Applikation. Der Clue an der ganzen Sache: Die SIM Karte hat direkten Zugriff auf SMS und den Screen des Phones, am Betriebssystem vorbei! Sie sehen hier ein Beispiel für die Verwendung von MSS. … Das sieht nach einem guten Konzept aus und bietet tatsächlich einen unabhängigen Kanal. Man muss jetzt mal schauen wie sich das in der Praxis bewährt. Swisscom plant die Einführung von MSS unter dem Namen «Mobile ID» noch in diesem Jahr. Wir arbeiten bereits mit Swisscom zusammen um Mobile ID in den Medusa Authentisierungsserver zu integrieren. ---- Standard: ETSI TR 102 203 ****** 5. Yes/no SIM Karte mit SmartCard Chip Zertifikat und privaten Schlüsseln Authentisierungsapplikation (in SIM!) Direkter Bildschirm/Tastaturzugriff

Mobile Banking is read-only, but… My personal E-Banking is a web application (no mobile app available) verifies transactions with SMS TANs is accessible from browser of mobile phone! Wie erwähnt, bieten die meisten Banking Apps zur Zeit nur Lesezugriff an. Was aber vergessen geht: Die meisten von uns haben bereits heute mobiles E-Banking ohne Einschränkungen! Warum? Mein persönliches E-Banking ist eine Webapplikation. Sie sichert Login und Transaktionen mit SMS TAN. Sehr vorbildlich. ABER: Sie ist vom Smartphone aus erreichbar! Damit fällt plötzlich der 2. Kanal in sich zusammen und ich habe mobiles E-Banking ohne Schutz gegen Session Hijacking ohne Schutz gegen Passwort-Klau (weil die SMS TANs die Streichliste ersetzen) ohne Einschränkung der erlaubten Transaktionen Mein Konto ist also gleich gut geschützt wie mein Facebook Account.  Eigentlich müsste man den Zugriff von Smartphones aus verbieten. Doch wie soll man das machen? (User Agent, IP address range? Hilft es überhaupt? -> Dieb geht mit Handy ins Internet-Café) No protection against session hijacking! No protection against password theft! No transaction restrictions!

WAF und vorgelagerte zentrale Authentisierung bieten hohe Sicherheit und viele Anwendungsmöglichkeiten. Starke Authentisierung auf Mobil- telefonen ist nicht trivial. Erste Lösungen zeichnen sich ab.