Lokales Kennwortmanagement – ein Sicherheitsrisiko

Auf dem Black Hat-Treffen in den USA kommende Woche soll demonstriert werden, wie sich der lokale Kennwortspeicher des Firefox-Browsers mit Hilfe von sogenannten Cross Site Scripting-Attacken (XSS) knacken lässt. Nur: Dass solche lokalen Ansätze per se unsicher sind, ist keine Überraschung. Single Sign-On macht Sinn, aber nur wenn es richtig gemacht ist.

Das grundsätzliche Problem ist dabei die sichere Ablage von Credentials. Bei Enterprise Single Sign-On-Lösungen, wie sie inzwischen verbreitet im Einsatz sind, speichern die Kennwörter in zentralen Speichern. Auch hier gilt es zu hinterfragen, wie sicher diese sind. Grundsätzlich lassen sich aber zentrale Server-Systeme besser absichern als dezentrale Clients.

Bei rein lokalen Lösungen läuft es dagegen darauf hinaus, dass die Kennwörter systemseitig verschlüsselt abgelegt werden. Um sie wieder nutzen zu können, muss das System wie ein Browser oder ein lokaler Passwort-Manager diese aber auch wieder entschlüsseln können – und dazu braucht er Zugriff auf den Schlüssel. Da dieser nicht vom Benutzer eingegeben wird, muss er im System liegen. Und so gut man ihn auch versteckt oder wieder verschlüsselt oder auf Basis von Algorithmen unter Verwendung von bestimmten fixen Informationen im System erzeugt: Er ist eine Schwachstelle.

Besser sieht es da schon aus, wenn man zusätzliche Hardware-Elemente (auch als Tokens bezeichnet) wie Smartcards oder USB-Geräte verwendet, auf denen die Credentials in sicherer Weise abgelegt werden. Auch die Möglichkeiten, die TPMs (Trusted Platform Modules) bieten, sind definitiv interessant. Die Low End-Lösungen sind es aber nicht.

Noch besser ist der Schritt weg vom „Schummel-SSO“, bei dem es auf Anwendungsebene immer noch unterschiedliche Benutzernamen, Kennwörter und andere Credentials gibt und hin zu echtem Single Sign-On. Kerberos und Identity Federation heißen hier die Ansätze der Wahl. Hier gibt es ein hoffentlich gut geschütztes zentrales Authentifizierungssystem. Bei der Identity Federation heißt es Identity Provider, bei Kerberos ist es der Kerberos KDC (Key Distribution Center). Dahinter kann in beiden Fällen beispielsweise das Microsoft Active Directory stehen, dessen Sicherheit damit zu einem entscheidenden Faktor wird: Haben Sie alle Domänencontroller in physisch adäquat gesicherten Räumen stehen? Haben Sie ein PAM (Privileged Account Management) für die Administratoren ihrer Windows-Umgebung implementiert?

Die Anwendungen selbst erhalten nur noch eine verschlüsselte Bestätigung über die erfolgreiche Authentifizierung, ein so genanntes Token (nicht zu verwechseln mit den Hardware-Tokens). Dieses enthält die erforderlichen Informationen. Es gibt nur noch ein Kennwort.

Federation ist dabei der Ansatz der Zukunft. Er basiert auf Web Services, funktioniert damit auch über die Unternehmensgrenzen und im Internet und wird zunehmend unterstützt. Kerberos ist dagegen vor allem für die primäre Authentifizierung im Netzwerk und den unternehmensinternen Einsatz mit ohnehin kerberos-fähigen Anwendungen interessant.

Klar ist aber: Wenn man es richtig macht, braucht man sich um Schwachstellen, wie sie Browser (und nicht nur Firefox) per se haben, keine Gedanken machen. Denn dann ist Single Sign-On kein Sicherheitsrisiko, sondern eine Chance für mehr Sicherheit.



KuppingerCole PLUS

Get access to the whole body of KC PLUS research including Leadership Compass documents for only €800 a year

Stay Connected

KuppingerCole on social media

Subscribe to our Podcasts

KuppingerCole Podcasts - listen anywhere


How can we help you

Send an inquiry

Call Us +49 211 2370770

Mo – Fr 8:00 – 17:00