Kontakt aufnehmen
Wir helfen Ihnen gerne weiter
Beim Einsatz von Authentifizierung und Autorisierungsverfahren ist es wichtig, als unsicher geltende, überholte Verfahren schnellstmöglich zu ersetzen. Galt es vor einigen Jahren noch als best-practice jede Anwendung mit LDAP mit einem zentrales Active Directory zu verbinden, so sind heute schon 2-Faktor Authentifizierungen im Fokus von Hackern. Aktuelle Protokolle wie WebAuthn stellen sich Phishing entgegen, bringen aber Usability-Herausforderungen mit sich. Im Folgenden geben wir einen Überblick über alte und aktuelle Protokolle.
LDAP ist der "alte Hase" unter den Authentifizierungs- und Autorisierungsprotokollen. Es ist ein Protokoll, mit dem man Informationen in einem sogenannten Verzeichnisdienst abfragen und ändern kann. Bekannte Verzeichnisdienste sind Microsoft Active Directory und Red Hat Directory Server.
Der große Nachteil an der direkten Authentifizierung mit LDAP ist, dass die Authentifizierung immer nur mit einem Passwort geprüft werden kann. Wenn man also einen Anwendungsserver über LDAP verbindet, muss die Anwendung das Passwort des Users entgegennehmen und gegen den LDAP Server prüfen. Wird nun eine von vielen Anwendungen kompromittiert, werden auch die Passwörter der User kompromittiert. Als Lösung für dieses Problem wurde Single-Sign-On mit Tokens erfunden, dafür kann z.B. SAML oder OpenID Connect verwendet werden.
Das SAML Protokoll ist Protokoll für Single-Sign-On. Es erlaubt einer Anwendung, einen Benutzer anzumelden, ohne selbst die Identität des Benutzers prüfen zu müssen. Diese Aufgabe übernimmt der sogenannte Identity Provider, also das IAM-System. SAML stammt bereits aus dem Jahr 2001 und basiert auf XML, HTTP und Kryptografie. Über die Jahre wurden immer mal wieder Schwachstellen in SAML oder SAML Implementierungen entdeckt. Insbesondere das XML Parsing und die kryptografische Validierung ist komplex und fehleranfällig, aber sehr relevant für die Sicherheit.
Mit dem Artifact Binding kann man die Angriffsfläche massiv reduzieren, da sich dabei nicht nur auf Kryptografie verlassen wird. Richtig implementiert, gilt das Verfahren als sicher. In vielen großen Unternehmen ist SAML der Standard. Da es viele Konfigurationsparameter gibt, sollte man darauf achten, dass genug Zeit und das richtige Personal für die notwendige Sorgfalt bereitgestellt wird. Eine Übersicht gibt es im OWASP SAML Security Cheat Sheet .
OpenID Connect ist ebenfalls ein Protokoll für Single-Sign-On. Es stammt aus dem Jahr 2014 und ist damit deutlich neuer als SAML. Beim Design wurde aus Problemen mit SAML gelernt und direkt ein Verfahren, äquivalent zum Artifact Binding, im Protokoll verpflichtend gemacht. Im Gegensatz zu SAML setzt das Protokoll nicht auf XML, sondern auf JSON und eine REST-API.
Auch bei OpenID Connect gibt es aber einige Dinge bei der Konfiguration zu beachten :
Man sollte immer den Authorization-Code Flow (für User) oder den Client Credential Grant (für Anwendungen) verwenden. Mit Proof-Key-for-Code-Exchange (PKCE) können Angriffsszenarien bekämpft werden, bei denen ein Angreifer den Authorization-Code klaut. Insgesamt würden wir bei neuen Implementierungen OpenID Connect den Vorzug vor SAML gewähren, da es deutlich weniger komplex ist und bereits von Grund auf sicherer designt wurde.
In komplexen Systemlandschaften kommt es vor, dass ein Benutzer (Browser) nicht direkt mit einer Anwendung interagiert, sondern die Kommunikation über eine andere Anwendung stattfindet. Stellen Sie sich ein Dashboard vor, das Informationen von verschiedenen System aggregiert anzeigt. Das Dashboard muss "On-Behalf-Of", also im Namen des Benutzers, mit den Anwendungen sprechen. Wenn nun das Dashboard das Token des Benutzers verwendet, um den Benutzer bei den anderen Anwendungen zu authentifizieren, nennt man diesen Vorgang "Token Propagation". Hier entsteht ein Problem: Jede der Anwendungen könnte sich dieses Token nehmen und damit "Böses" in anderen Anwendungen im Namen des Benutzers unternehmen. Das Sicherheitsproblem, dass eine kompromittierte Anwendung alle anderen Anwendungen betrifft, das wir eigentlich durch das Single-Sign-On Protokoll bekämpfen wollten, ist wieder da.
Die Lösung für das Problem ist einfach: Das Dashboard tauscht vor der "On-Behalf-Of" Verwendung das Token beim IAM-System gegen ein anderes eingeschränktes Token aus, das nur für die Zielanwendung gültig ist. Das Verfahren wurde in RFC 8693 - OAuth 2.0 Token Exchange standardisiert.
Eine sehr sinnvolle Vorsichtsmaßnahme gegen Passwort-Leaks ist die Verwendung mindestens eines zweiten Faktors. Weit verbreitet ist hier der Google Authenticator oder das Verschicken von Codes per SMS oder E-Mail. Inzwischen ziehen allerdings auch die Angreifer mit und attackieren 2-Faktor Authentifizierung mit Phishing-Attacken. Der einzige wirksame Schutz gegen Phishing ist, dass sich nicht nur der Benutzer bei der Webseite authentifiziert, sondern auch die Webseite beim Benutzer. Erreicht werden kann das kryptografisch. Das FIDO2 Projekt definiert dafür das WebAuthn-Protokoll, das inzwischen von den gängigen Browsern unterstützt wird. Zusätzlich ist ein interner oder externer Authentifikator nötig, z.B. ein Yubikey oder ein Smartphone.
Kerberos ist ein Single-Sign-On Authentifizierungsprotokoll, das sich von SAML und OpenID Connect dadurch unterscheidet, dass es nicht nur in Webanwendungen verbreitet ist. Es ist das Standardprotokoll in Microsoft Active Directory und daher in vielen Windows-basierten Unternehmensnetzwerken verbreitet. Kerberos selbst stammt schon aus dem letzten Jahrtausend, die aktuelle Version 5 aus dem Jahr 2005 behebt viele der zuvor bekannten Sicherheitsprobleme. Bei vielen IAM-Systemen kann die Authentifizierung an Kerberos delegiert werden. Das heißt, dass die Mitarbeiter, die sich an Ihrem Arbeitsplatz angemeldet haben, auch Zugang zu Webanwendungen erhalten, die über SAML oder OpenID Connect angeschlossen werden.
Es ist auch möglich, die Authentifizierung am Identity & Access Management System rein auf kryptografischer Basis durchzuführen. Voraussetzung dafür sind vertrauenswürdige Zertifizierungsstellen. Der zentrale Vorteil hier ist, dass das Geheimnis das Clients - der Private-Key - den Computer des Clients nicht verlassen muss. Das ist anders als bei einer Passwort-basierten Authentifizierung, bei der der Benutzer das Passwort in der Login-Oberfläche des IAM-Systems eingibt. Herausforderungen sind allerdings das Verteilen der Zertifikate, das sichere Speichern der Private Keys, sowie der Betrieb der Zertifizierungsstellen.
SCIM ist ein Protokoll, das sich nicht der Authentifizierung widmet. Es dient dazu, Benutzer, Attribute, Gruppen und ähnliche in verschiedene Anwendungen zu synchronisieren. Wenn ein Büro-Mitarbeiter in einem Unternehmen eingestellt wird, kann so z.B. ein Account in Microsoft Office 365 angelegt werden und mit den nötigen Rechten versehen werden. Der Benutzer kann von anderen Mitarbeitern in Office gefunden werden, noch bevor er sich das erste Mal eingeloggt hat. Wenn der Mitarbeiter das Unternehmen wieder verlässt oder in einen anderen Beruf wechselt, kann dieser Benutzer mit SCIM automatisch wieder aus Office gelöscht werden. Bei einer Vielzahl von Anwendungen, insbesondere als SaaS, ist dieses Verfahren sehr hilfreich.
Das Client/Server Protokoll RADIUS dient der Authentifizierung, Autorisierung und dem Accounting eines Netwerkdienstes. Ein RADIUS Client schickt dazu eine Anfrage für einen Netzwerkservice an den RADIUS Server. Dieser authentifiziert den Absender anhand der mitgeschickten Zugangsdaten (typischerweise Benutzername & Passwort). Dazu werden häufig weitere an den RADIUS Server angeschlossene Verzeichnisdienste, wie z.B. ein LDAP Server verwendet. Anschließend wird die Anfrage vom Server autorisiert, d.h. entschieden, ob der Benutzer auf den angefragten Netzwerkdienst zugreifen darf und eine entsprechende Antwort an den Client geschickt. Diese Funktionen werden in RFC 2865 - Remote Authentication Dial In User Service (RADIUS) spezifiziert.
Zusätzlich können Accounting Funktionen genutzt werden, um z.B. die Nutzung des Netzwerkdiensts abzurechnen, oder die Einhaltung bestimmter Quotas zu überprüfen. Dazu sendet der Client typischerweise eine Startmeldung für das Accounting an den Server, sowie periodische Updatemeldungen, die den Server über die weiterhin geöffnete Sitzung informieren. Nach Beendigung der Sitzung erfolgt eine Stopmeldung an den Server. Diese Funktionen werden in RFC 2866 - RADIUS Accounting beschrieben.
Kontakt aufnehmen
Wir helfen Ihnen gerne weiter