Über die Privacy beim Login

Jeder weiss, dass bei einem Social-Login, z.B. mit Google oder Facebook, Daten der Benutzer gesammelt werden und die daraus gebildeten Profile viel Aussagekraft haben. Doch wie funktioniert das überhaupt und wie könnte man das verhindern?

Digitale Identitäten haben sich in den letzten Jahren von rein isolierten zu föderierten Systemen entwickelt. Eine Gegenüberstellung dieser Modelle wurde im Artikel Sichere Identitäten eingehend beschrieben.

Ein gutes Beispiel föderierter Identitätsmodelle sind Social-Logins.  Wie schon im Artikel “Sichere Identitäten” beschrieben, handelt es sich hier um Dienste, welche elektronische Identitäten (engl. Identity Provider, IdP) anbieten. In einem ersten Schritt (siehe Abb. 1) erstellt ein Benutzer meist gemeinsam mit dem IdP eine Identität, welche dann von diesem in einer Benutzerdatenbank zentral abgelegt wird.

Abbildung 1: Erstellen einer zentral geführten Identität

Will ein Benutzer auf eine bestimmte Webseite zugreifen, leitet diese ihn an den IdP weiter (siehe Abb. 2). Dort authentifiziert sich der Benutzer zuerst, z.B. mit einem Passwort oder einer Mehr-Faktoren-Authentifizierung. War dies erfolgreich, so übermittelt der IdP der Web-Applikation eine Bestätigung der erfolgreichen Authentifizierung und ggf. noch Angaben zum Benutzer.

Abbildung 2: Verwendung der elektronischen Identität

Ein Web-Applikationsanbieter muss sich also nicht mehr um die Authentisierung eines Benutzers kümmern. Viel eher kann er dies an einen externen Dienst (Google, Facebook, u.a.) delegieren, und erhält zusätzlich noch bestimmte Informationen über den Benutzer.

Abbildung 3: typischer Login-screen mit “Social Login”

Man kann leicht erkennen, dass bei diesem Vorgehen ein IdP erfährt, wann der Benutzer auf welche Webseite zugreifen will und die Webseite wiederum kann erfahren, bei welchem IdP sich der Benutzer angemeldet hat.

Privacy-Anforderungen

Will man dies technisch verhindern, muss man die folgenden Anforderungen erfüllen[1]:

  1. Eingeschränkte Beobachtbarkeit (Blindness des IdP): Der IdP darf nicht in der Lage sein, Daten über die Nutzung der Web-Applikationen durch Benutzer zu erkennen und zu sammeln, um so persönliche Interessen oder Verhaltensweisen abzuleiten.
  2. Eingeschränkte Beobachtbarkeit (Blindness der Web-Applikation): Eine Web-Applikation darf nicht erfahren, wo und wann sich der Benutzer authentisiert hat und vom wem eine Bestätigung zu seiner Identität stammt.
  3. Unverkettbarkeit: Web-Applikationen dürfen nicht in der Lage sein, personenbezogene Daten – ohne Wissen des Benutzers – zusammenzuführen. Nur wenn es für einen legitimen Zweck erforderlich ist, dürfen Web-Applikationen Informationen eines Benutzers verknüpfen können. Dies betrifft neben eindeutigen Identifikatoren auch Attribute, die mit hoher Wahrscheinlichkeit identifizierend sind.

Lösungsansätze

Die Privacy-Anforderungen können technisch mit verschiedenen Mitteln erfüllt werden.

1. Seltene Kontaktierung des IdP:

Die Benutzer werden nur einmal zu Beginn von der Web-Applikation zum Identity Provider gesandt, um sich dort zu authentisieren und ihre persönlichen Daten freizugeben. Die Web-Applikation holt die Daten ab und legt diese dann in sein lokales Benutzerprofil ab. Nur auf Anregung des Benutzers oder sporadisch (z.B. 1x pro Jahr) wird dieser Vorgang wiederholt. Da die Web-Applikation den Benutzer nun selbst authentisiert, kriegt der IdP nur mit, dass sich ein Benutzer für eine Web-Applikation interessiert und sich mindestens einmal eingeloggt hat. Aber der IdP gewinnt keine Erkenntnis darüber, wann und wie häufig ein Benutzer diese verwendet. Dieses Verfahren ist sinnvoll, wenn die Web-Applikation eine eigene Benutzerverwaltung hat und über viele fachspezifische Angaben sowie über eine eigene Authentifizierung verfügt. Der zentrale IdP kann so für das «Onboarding» (die initiale Registrierung des Benutzers) verwendet werden. Für eine Web-Applikation wäre dies besonders interessant, wenn der IdP über hochqualitative Benutzerdaten (z.B. staatlich beglaubigte Attribute) verfügt und so die Identifizierung der Benutzer einmalig an den IdP delegieren kann.

2. Vermittler-basierte Modelle

Eine andere Möglichkeit die Beobachtbarkeit durch den IdP und die Web-Applikation zu beschränken, sind Vermittler (auch Broker oder Hub genannt), die zwischengeschaltet werden. Durch die Auftrennung der Verbindung bei der Authentisierung in zwei Abschnitte, weiss der IdP nicht welchen Dienst der Benutzer verwendet und der Dienst umgekehrt nicht, bei welchem IdP sich der Benutzer angemeldet hat. Dieses Verfahren ist zudem für die Web-Applikation vorteilhaft, da sie nur mit dem Vermittler interagieren und – für den Fall, dass mehrere IdPs unterstützt werden sollen – nicht mehrere Kommunikationsverbindungen mit potentiellen technischen Unterschieden unterstützen muss. Die Präsenz eines Vermittlers schafft aber neue Probleme, da dieser nun Authentifizierungsvorgänge des Benutzers protokollieren kann. Technisch ist es möglich, den Vermittler so zu bauen, dass auch eine «Blindness» des Vermittlers erreicht werden kann. Allerdings sind diese Verfahren recht aufwändig und teuer.

3. Dezentrale Identitäten

Ein völlig anderer Ansatz sind “dezentrale Identitäten”, wie in diesem Artikel beschrieben . Bei dieser Art der Identität ist der Benutzer sein eigener IdP, d.h. er erstellt seine eigene Identität (1) und veröffentlicht diese. Damit entfällt das Problem der Beobachtbarkeit durch einen IdP. Der Benutzer sammelt in der Folge für seine Identität sogenannte verifizierte Aussagen (2) von autoritativen Quellen (Herausgebern), welche ebenfalls ihre Glaubwürdigkeit veröffentlichen. Die Authentifizierung läuft nur noch zwischen dem Benutzer und der nutzenden Web-Applikation (3), welche die ihr präsentierten Aussagen in einem öffentlichen Identitätsverzeichnis überprüfen kann.

Abbildung 4: Dezentrale Identität

Damit auch die Unverkettbarkeit zwischen Web-Applikationen gewährleistet werden kann, darf eine Web-Applikation die echte Identität nicht mitkriegen können, aber sie muss die Aussagen vertrauenswürdig überprüfen können. Dies kann mit entsprechenden Verfahren erreicht werden. Die heute vorhandenen dezentralen Lösungen sind aber noch nicht so ausgereift, dass sie von der breiten Öffentlichkeit genutzt werden können. Zudem sind einige Forschungsfragen, z.B. zum Thema Schlüsselwiederherstellung, Vertrauen oder Revokation (Sperrung von Aussagen) noch nicht zufriedenstellend gelöst.

Nebst den noch ungelösten Themen bieten dezentrale digitale Identitäten aber Vorteile für den Benutzer und ein Unternehmen. So schützen dezentrale Identitätssysteme von Haus aus die Privatsphäre des Benutzers, da sie den Nutzern die volle Kontrolle über ihre Identität geben und ein Authentisierungsvorgang ohne zentrale Instanz auskommt.

Dezentrale Identitäten stellen auch für Unternehmen einen Mehrwert dar. Das Risiko einer zentralen Userdatenbank entfällt gänzlich. Dadurch werden Unternehmen entlastet, weil sie nicht mehr Identitäten und “Credentials” (z.B. Passworte) speichern und gegen unrechtmässigen Zugriff schützen müssen. Dies gilt sowohl für Identitätsanbieter wie auch für Web-Applikationsbetreiber. Ein Identitätsanbieter muss nicht mehr die Identität eines Benutzers pflegen (diese wird ja vom Benutzer selbst erstellt), sondern nur noch personenbezogene Informationen. Für diese Informationen ist er als autoritative Quelle (Herausgeber) zuständig und kann diese in Form von überprüfbaren Aussagen dem Benutzer zur Verfügung stellen.

Aber auch der Web-Applikationsbetreiber hat einen Vorteil, da er den Überbringer einer Information immer authentifizieren kann, ohne dass er Anmelde-IDs und Passwörter selbst speichern muss. Dadurch kann ein Identitätsbetrug wesentlich reduziert werden, da solche Information nicht mehr gestohlen und wiederverwendet werden können. Nebst Datenverwaltung und -sicherheit werden damit aber auch Kosten für ein “Kunden-Onboarding” und das gesamte Lifecycle-Management» reduziert.

Fazit

Die vorgestellten Lösungsansätze zum Schutz der Privatsphäre beim Einloggen auf Webseiten und Apps sind mit Vor- und Nachteilen behaftet. Aktuell wird weiter daran geforscht (auch an der BFH im Institut IDAS), um zukünftig die gesteckten Ziele der Unbeobachtbarkeit und Unverkettbarkeit zu erreichen. Bis dahin kann man nur dem IdP vertrauen, dass dieser sein Wissen nicht kommerziell missbraucht. Gesetzliche Regelungen, wie z.B. für private IdP’s der geplanten E-ID[2], versuchen zwar dieses Vertrauen zu stärken, aber das Risiko zu viel von seiner Privatsphäre preisgegeben zu haben, bleibt beim Benutzer.


Referenzen

[1]https://www.researchgate.net/profile/Rainer_Hoerbe/publication/284764512_Privacy_by_Design_in_Federated_Identity_Management/links/5b7d06cfa6fdcc5f8b5b13b6/Privacy-by-Design-in-Federated-Identity-Management.pdf

[2]https://www.bj.admin.ch/dam/bj/de/data/staat/gesetzgebung/e-id/datenschutzregelung-bgeid.pdf.download.pdf/datenschutzregelung-bgeid-d.pdf

AUTOR/AUTORIN: Gerhard Hassenstein

Gerhard Hassenstein ist Dozent an der BFH Technik und Informatik.

AUTOR/AUTORIN: Annett Laube

Annett Laube leitet das Institute for Data Applications and Security (IDAS) an der BFH Technik & Informatik und ist verantwortlich für den Schwerpunkt Identität und Privatsphäre am BFH-Zentrum Digital Society.

PDF erstellen

Ähnliche Beiträge

0 Kommentare

Dein Kommentar

An Diskussion beteiligen?
Hinterlasse uns Deinen Kommentar!

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.