Single Sign-On (SSO) hat einen stillen Grundsatz: Wenn ein Nutzer über einen Identity Provider (IdP) angemeldet wird, darf man davon ausgehen, dass der IdP dessen Identität bereits bestätigt hat. Theoretisch könnte man also auf Passwörter verzichten und den Nutzer direkt einlassen. Doch genau hier lag der Fehler – nicht im System selbst, sondern in der Annahme, dass die übermittelten Nutzerdaten automatisch vertrauenswürdig sind.
Der Fehler: Vertrauen in ein vermeintlich sicheres Feld
In vielen SSO-Implementierungen wird die E-Mail-Adresse als primärer Schlüssel genutzt, um Nutzerkonten zuzuordnen. Sobald ein Nutzer über einen IdP angemeldet wird, prüft das System, ob eine lokale Nutzeridentität mit der übermittelten E-Mail-Adresse existiert. Existiert ein Konto, wird der Nutzer automatisch darauf zugreifen. Einfach, effizient – und gefährlich.
Doch was, wenn der IdP nicht vertrauenswürdig ist? In einer Multi-Tenant-Umgebung kann jeder Nutzer oder jede Organisation eigene IdPs einrichten. Ein Angreifer könnte beispielsweise einen eigenen SAML- oder OIDC-IdP erstellen und beliebige Nutzerdaten in der Assertion hinterlegen. Selbst wenn die digitale Signatur der Assertion korrekt ist, könnte die enthaltene E-Mail-Adresse manipuliert sein – etwa mit ceo@othercorp.com. Das System würde dann den echten CEO des Unternehmens blockieren und stattdessen den Angreifer anmelden.
Der Haken: Es gab keine technische Schwachstelle. Die Authentifizierung des IdPs war korrekt, die Signatur valide und das Konto existierte. Der Fehler lag darin, die E-Mail-Adresse als primären Identifikator zu behandeln – obwohl sie eigentlich nur eine Behauptung des IdPs ist.
Warum zusätzliche Validierung das Problem nicht löst
Eine naheliegende Reaktion wäre, zusätzliche Validierungen einzuführen: Die E-Mail-Adresse muss als verifiziert markiert sein, die Domain muss zur Zielorganisation passen oder weitere Prüfungen müssen durchgeführt werden. Doch genau hier liegt das Grundproblem: Der Angreifer kontrolliert die Assertion und kann jeden Wert setzen, den er möchte. Fordert man etwa email_verified = true, fragt man im Grunde den Fuchs, ob er den Hühnerstall bewacht hat. Solche Prüfungen ändern nichts daran, dass die Daten aus einer unkontrollierten Quelle stammen.
Die E-Mail-Adresse ist zwar praktisch für Nutzer, aber als primärer Schlüssel ungeeignet. Sie ist global verbreitet (dieselbe Adresse kann bei verschiedenen Providern existieren) und manipulierbar (der IdP kann beliebige Werte eintragen). Für eine sichere Zuordnung braucht es einen Schlüssel, der weder global noch fälschbar ist.
Die Lösung: Umstellung auf provider-spezifische Nutzerkennungen
Der Fehler lag nicht in der Logik, sondern im Schlüssel. Statt die E-Mail-Adresse zu nutzen, sollte das System auf ein unveränderliches Feld setzen: die Kombination aus provider (dem IdP) und sub (der Nutzerkennung innerhalb dieses Providers).
Ein Angreifer kann zwar einen eigenen Provider erstellen und innerhalb dessen beliebige sub-Werte vergeben. Doch er kann nicht die sub-Kennung eines anderen Providers übernehmen. Diese Kombination (provider, sub) ist einzigartig und nicht manipulierbar, solange der Provider nicht kompromittiert ist. Das System sucht dann nicht mehr nach einer E-Mail-Adresse, sondern nach der lokalen Nutzeridentität, die zuvor mit dieser spezifischen (provider, sub)-Kombination verknüpft wurde.
Die E-Mail-Adresse behält ihre Rolle als hilfreicher Hinweis – aber nur, wenn sie von einer vertrauenswürdigen Quelle stammt. Beispielsweise kann eine E-Mail-Adresse nur dann einem bestehenden Konto zugeordnet werden, wenn sie von einem IdP mit einer Domain stammt, die in der Liste der erlaubten Domains des Tenants enthalten ist. Andernfalls wird eine neue Nutzeridentität erstellt, anstatt bestehende Konten zu gefährden.
Die zentrale Lektion: Trennung von Authentifizierung und Identitätszuordnung
Bei der Federation von Identitäten müssen zwei Fragen klar getrennt werden:
- Hat der IdP den Nutzer authentifiziert? – Diese Frage wird durch die digitale Signatur beantwortet.
- Welche Identität hat der Nutzer in meinem System? – Diese Frage erfordert einen Schlüssel, den der IdP nicht global manipulieren kann.
Die E-Mail-Adresse ist verlockend, weil sie für Menschen verständlich und scheinbar eindeutig ist. Doch sie ist genau das falsche Feld für die Identitätsauflösung. Jedes Feld in einer Assertion sollte als potenziell manipulierbar betrachtet werden – es sei denn, die Quelle des Feldes ist explizit vertrauenswürdig für diesen spezifischen Anspruch.
Diese Erkenntnis führte zur Implementierung einer sichereren Lösung, noch bevor das Auth-System produktiv eingesetzt wurde. Es ist ein Fehler, der alle Tests besteht, jede Signatur validiert und trotzdem die Tür für Angreifer öffnet – einfach weil die falsche Zeile in der Nutzeridentität gelesen wurde.
Federated Identity Management erfordert klare Regeln für die Zuordnung von Identitäten. Ein falscher Ansatz kann zu einem Kontoübernahme führen, die alle Sicherheitsprüfungen besteht. Moderne Lösungen wie Authagonal setzen genau hier an: Sie lösen Nutzerkonten anhand der provider-spezifischen sub-Kennung auf – und nie anhand der E-Mail-Adresse in der Assertion.
KI-Zusammenfassung
Federasyon tabanlı kimlik doğrulama sistemlerinde hesap ele geçirme saldırılarını önlemek için e-posta yerine doğru anahtarın nasıl kullanılacağını öğrenin. Güvenlik açıklarını ve çözümlerini keşfedin.
