{"id":19473,"date":"2021-08-24T11:25:00","date_gmt":"2021-08-24T09:25:00","guid":{"rendered":"https:\/\/www.sysbus.eu\/?p=19473"},"modified":"2021-08-17T10:25:35","modified_gmt":"2021-08-17T08:25:35","slug":"plattform-security-sichere-authentifizierung-und-selbstsouveraene-nutzerprofile","status":"publish","type":"post","link":"https:\/\/www.sysbus.eu\/?p=19473","title":{"rendered":"Plattform-Security: Sichere Authentifizierung und selbstsouver\u00e4ne Nutzerprofile"},"content":{"rendered":"\n

Autor\/Redakteur: Stefan Adolf, Developer Ambassador bei Turbine Kreuzberg<\/a>\/gg<\/p>\n\n\n\n

Digitale Plattformen erfordern ein hohes Ma\u00df an Sicherheit und Datensparsamkeit, um das Vertrauen der Nutzer nicht zu verlieren. Wie k\u00f6nnen wir heute dennoch notwendige Profildaten sicher und unkompliziert austauschen? Von OAuth und JWT zu selbstsouver\u00e4ner Identit\u00e4t.<\/p>\n\n\n\n

\"\"<\/a>
Bild: Turbine Kreuzberg<\/figcaption><\/figure>\n\n\n\n\n\n\n\n

Selbst popul\u00e4re Handelsplattformen wie Wish oder Etsy bieten ihn inzwischen als Standard an: den Login-Knopf f\u00fcr Google, Facebook oder Apple, gemeinhin bekannt als \u201cSingle Sign On\u201d, oder fachlich korrekt: f\u00f6deralisierte Anmeldeverfahren. Zentral kontrollierte Nutzerprofile sind f\u00fcr alle Akteure vorteilhaft. Laut verschiedenen Umfragen geben mehr als 80 Prozent der Benutzer an, dass sie es als st\u00f6rend empfinden, auf Websites neue Konten erstellen zu m\u00fcssen. Ein Drittel der Verbraucher bricht den Online-Einkauf ab, weil sie sich nicht an ihre Passw\u00f6rter erinnern \u2013 so hei\u00dft es in einer Studie von MasterCard und der University of Oxford<\/a>. Ein Login mit Hilfe eines Social Media Accounts kann also die Konversionsrate und Kundenbindung steigern. Aber es gibt auch eine Schattenseite: Vor etwa drei Jahren gab es bei Facebook eine massive Datenschutzverletzung, die sich auf mehr 50 Millionen Nutzer auswirkte. Sie legte jedes externe Konto offen, bei dem sich die Betroffenen mit Facebook angemeldet hatten. Eine <\/a>Studie<\/a> fand zudem bei einer Untersuchung von insgesamt 95 Web- und Mobil-Diensten zahlreiche Fehler bei der Implementierung von solchen Login-Verfahren. Seitdem haben Daten-Hacks und -Lecks eher zu- als abgenommen.<\/p>\n\n\n\n

Um das Internet sinnvoll nutzen zu k\u00f6nnen, sind Authentifizierungsprozesse freilich notwendig. Wie sollte man sonst bequem sein Facebook-Profil updaten, seine Lieblingsmusik by Spotify h\u00f6ren oder eine Bestellung veranlassen? Die Datenschutzgrundverordnung verlangt von den Plattformbetreibern ein hohes Ma\u00df an Sicherheit und Datensparsamkeit ihrer Systemarchitektur. Sie sehen sich folglich mit einer Reihe von Fragen konfrontiert: Wie vermeidet man es, unn\u00f6tig viele pers\u00f6nliche Informationen der Kunden auszutauschen oder zu speichern? Welche beteiligten Parteien k\u00f6nnen auf die Nutzerdaten zur\u00fcckgreifen? Wer kann sie zu welchem Zeitpunkt im Klartext lesen, und wie l\u00e4sst sich ein DSGVO-konformer Audit-Trail \u00fcber die Zugriffe realisieren? Letztlich muss das Ziel sein, Anmeldedaten und Profilinformationen zu f\u00f6deralisieren, ohne dabei sicherheitskritische Nutzerprofile zu sammeln. Im folgenden werfen wir einen Blick auf die gegenw\u00e4rtigen Verfahren sowie ihre Vor- und Nachteile.<\/p>\n\n\n\n

OAuth (Open Authorization)<\/strong><\/p>\n\n\n\n

Um nicht st\u00e4ndig ein neues Profil bei jedem Anbieter erstellen zu m\u00fcssen, erfanden 2012 zun\u00e4chst Facebook und Twitter f\u00fcr ihre Nutzer das Authentifizierungsprotokoll OAuth, heute auch bekannt als Internet-Standard RFC 6749<\/a>, der die genannten \u201cLogin mit\u2026\u201d-Buttons erm\u00f6glicht. OAuth definiert, wie zwei einander bekannte Dienste im Namen der User auf die Ressourcen des jeweils anderen zugreifen k\u00f6nnen, ohne Anmeldeinformationen miteinander zu teilen. Wer ein Konto bei Facebook hat, kann es also zum Login bei anderen Diensten verwenden, ohne ihnen Passwort oder E-Mail-Adresse preiszugeben.<\/p>\n\n\n\n

Man kann sich das Prinzip wie in einem Hotel vorstellen. Eine Kundin geht zur Rezeption, zeigt ihren Personalausweis und ihre Kreditkarte, und erh\u00e4lt daf\u00fcr eine Schl\u00fcsselkarte, mit der sie ihre Zimmert\u00fcr \u00f6ffnen, ein Fahrrad leihen und im Restaurant bezahlen kann. Auf der Karte selbst stehen keinerlei Informationen \u00fcber die Kundin; wichtig ist nur, dass sie die Karte besitzt. Online funktioniert es \u00e4hnlich: M\u00f6chte sich eine Kundin zum Beispiel mittels \u201eSign up with Google\u201c bei Etsy registrieren, leitet Etsy sie \u00fcber einen individualisierten URL zu Googles Anmeldedienst weiter. Der URL enth\u00e4lt lediglich Informationen \u00fcber die anfragende Plattform (Etsy), den generellen Anmeldewunsch sowie eine Liste von Freigaben auf bestimmte Bereiche (Scopes) des Google-Profils der Nutzerin. Google erkennt, dass die Anfrage von Etsy stammt, und zeigt der Nutzerin einen Dialog an, welche Informationen Etsy von ihr anfordert. Stimmt die Kundin dem Datenaustausch zu, sendet die Google-API ein einmaliges Grant-Token an den Etsy-Server, der wiederum mit einem nur zwischen ihm und Google bekannten Geheimnis antwortet. Im letzten Schritt stellt Google ein Access-Token zur Verf\u00fcgung, das die Authentifizierung und Freigaben der Kundin repr\u00e4sentiert. Dieses Access-Token ist die Analogie zur Schl\u00fcsselkarte: Wer es besitzt, handelt im Namen der Kundin und hat Zugriff auf die in ihm vermerkten Google-Ressourcen. Access-Tokens werden \u00fcblicherweise im Browser der Nutzerin gespeichert und m\u00fcssen nach einiger Zeit erneuert werden.<\/p>\n\n\n\n\n\n\n\n

Das OAuth-Protokoll hat den Weg f\u00fcr f\u00f6deralisierte Anmelde- und Authentifizierungsprotokolle geebnet, die Registrierung von Benutzerkonten revolutioniert und ist aus dem modernen Web nicht wegzudenken. Dabei hat es zwei entscheidende Nachteile: Zum einen erf\u00e4hrt der Authentifizierungsanbieter (\u201cGoogle\u201d) aus den Wechselbeziehungen der Metadaten viel \u00fcber die Menschen, die es nutzen. Zum anderen sind solche Verfahren von den Anbietern abh\u00e4ngig. Verbraucher und Plattform-Betreiber m\u00fcssen sich nicht nur darauf verlassen, dass Unternehmen wie Google und Facebook die Daten und die Kommunikation sch\u00fctzen, sondern auch, dass sie das Protokoll nicht einfach einstellen. In letzterem Fall h\u00e4tten die Kunden keinen Zugriff mehr auf ihre Daten.<\/p>\n\n\n\n

JSON Web Token (JWT)<\/strong><\/p>\n\n\n\n

JSON Web Tokens sind ein Authentifizierungsverfahren, das die Integrit\u00e4t beim Datenaustausch mit kryptographischen Signaturen absichert. JWTs bestehen aus drei Teilen: Header, Payload und Signature. Der Header erh\u00e4lt Informationen \u00fcber die Art des Tokens sowie die Algorithmen, die f\u00fcr die Signatur verwendet werden. Der Payload enth\u00e4lt Lastinformationen \u00fcber den Gegenstand des Tokens, zum Beispiel die Nutzer-ID oder eine Liste von Nutzerrollen sowie Ausstellungs- und Ablaufdatum. Der letzte Teil besteht aus der Signatur, die der Aussteller des Tokens mit Hilfe seines geheimen privaten Schl\u00fcssels aus Header aus Payload erstellt hat. Wer den \u00f6ffentlichen Schl\u00fcssel kennt, kann \u00fcberpr\u00fcfen, dass ein ihm vorgelegter JWT von diesem Aussteller stammt und dass die Inhalte des JWTs nicht ver\u00e4ndert wurden.<\/p>\n\n\n\n

Das Verfahren hat den immensen Vorteil, dass JWTs ein sich selbst gen\u00fcgendes Format darstellen: Sobald man ein JWT f\u00fcr g\u00fcltig befindet und seinem Herausgeber vertraut, kann man auch den im JWT pr\u00e4sentierten Informationen bedingungslos vertrauen. Unter anderem l\u00e4sst sich mit JWTs serverseitig auch die Initialisierung eines Nutzerobjekts, einer Session und die erneute \u00dcberpr\u00fcfung von Berechtigungen einsparen.<\/p>\n\n\n\n

JWTs sind sicher, solange Nutzer ihre Tokens geheim halten und sie nicht auf dem Transportweg abgefangen werden; eine tokenbasierte Anmeldung setzt immer die Nutzung eines kryptographisch gesicherten Transportkanals wie TLS voraus. In der Regel verf\u00fcgen JWTs als zus\u00e4tzlichen Schutz \u00fcber ein relativ kurzfristiges Ablaufdatum, nach dem sie als ung\u00fcltig betrachtet werden m\u00fcssen. Mit Hilfe von langlebigen Refresh-Tokens k\u00f6nnen sie Clients aber analog zu einer \u201cAngemeldet bleiben\u201d-Checkbox \u00fcber l\u00e4ngere Zeitr\u00e4ume vom Herausgeber erneuern lassen. JSON Web Tokens spielen ihre St\u00e4rken bei der Nutzerauthentifizierung in Microservice-Umgebungen aus: Einzelne Dienste m\u00fcssen nicht einen zentralen Anmeldedienst nach der Richtigkeit eines Tokens befragen, sondern k\u00f6nnen anhand des \u00f6ffentlichen Schl\u00fcssels selbst von seiner Richtigkeit ausgehen.<\/p>\n\n\n\n

Selbstsouver\u00e4ne Identit\u00e4ten, DIDs und Verifiable Credentials<\/strong><\/p>\n\n\n\n

OAuth und JWT sind bew\u00e4hrte Standards f\u00fcr Platform-Security. Beide setzen aber auf einen zentralen Herausgeber von Identit\u00e4t und Rechten, der die Kontrolle \u00fcber das Profil des Nutzers beh\u00e4lt. Die moderne Alternative dazu sind Self-Sovereign-Identities (SSI). Hier verwalten Menschen ihre digitale Identit\u00e4t und ihre Profildaten vollkommen autonom und nutzen als Identifikationsmerkmale einen oder mehrere Schl\u00fcsselpaare, die sie zum Beispiel in einer Wallet auf ihrem mobilen Endger\u00e4t aufbewahren. SSIs machen die Nutzer tats\u00e4chlich unabh\u00e4ngig von zentralen Identit\u00e4tsdienstleistern.<\/p>\n\n\n\n

Die Grundlage einer SSI ist ein Decentralized Identifier (DID): eine global eindeutige Zeichenkette, die auf die gew\u00e4hlte DID-Methode und einen \u00f6ffentlichen Schl\u00fcssel einer Identit\u00e4t hinweist. Derzeit werden \u00fcber 120 verschiedene DID-Methoden erprobt, deren gr\u00f6\u00dfte Gemeinsamkeit ihre universelle Aufl\u00f6sbarkeit ist: Jede Methode spezifiziert, wie man das dazugeh\u00f6rige DID-Dokument mit weiteren, zweckgebundenen Schl\u00fcsseln und Service-Links findet oder aus \u00f6ffentlich sichtbaren Quellen oder der DID selbst herstellen kann. Viele DID-Methoden verankern das \u00f6ffentliche Schl\u00fcsselmaterial auf \u00f6ffentlich zug\u00e4nglichen dezentralen Systemen wie Blockchains, andere leiten Schl\u00fcsselmaterial direkt aus dem DID ab oder setzen auf Drittsysteme wie DNS.<\/p>\n\n\n\n

Die Schl\u00fcssel hinter den DID-Dokumenten erm\u00f6glichen es jedem, der eine DID kontrolliert, Aussagen \u00fcber andere DIDs zu treffen und diese kryptografisch abzusichern. Solche sogenannten Verifiable Credentials folgen einem \u00e4hnlichen Datenschema wie JWTs, k\u00f6nnen aber wie eine Sammlung von Plastikkarten in der Wallet eines Nutzers aufbewahrt und auf Anfrage pr\u00e4sentiert werden. Dabei spielt es perspektivisch keine Rolle, welche DID-Methoden zum Einsatz kommen: Die Wahl des Verfahrens obliegt der jeweiligen Partei. Solange ein Resolver ein DID-Dokument und dessen \u00f6ffentliche Schl\u00fcssel liefern kann, l\u00e4sst sich die Herkunft und Integrit\u00e4t von Credentials verifizieren.<\/p>\n\n\n\n

Je nach Applikation kann ein Nutzer mehrere DIDs f\u00fcr verschiedene Aspekte seiner digitalen Identit\u00e4t verwalten und so den Informationsfluss und die Korrelierbarkeit seiner Pr\u00e4sentationen kontrollieren. Entsprechende W3C-Standards schlagen dar\u00fcber hinaus Verfahren vor, mit denen sich die schematische Interoperabilit\u00e4t von Credentials, selektive oder kombinierte Pr\u00e4sentationen oder die Kommunikation zwischen den Wallets realisieren lassen. 2021 befinden sich die meisten dieser Vorschl\u00e4ge aber noch weitestgehend in der Erprobung.<\/p>\n\n\n\n

Der Preis der Souver\u00e4nit\u00e4t ist die auf den Nutzer \u00fcbergehende Verantwortung zur sicheren Verwahrung seiner geheimen privaten Schl\u00fcssel und der \u00fcber ihn ausgestellten Credentials. Es gibt zwar Dienstleister, die mit sogenannten Custodial Wallets das Risiko f\u00fcr den Nutzer \u00fcbernehmen, wer aber seine neu gewonnene Freiheit keinem Dritten \u00fcberlassen m\u00f6chte, sollte mit den geheimen Daten in seiner Wallet sehr sorgf\u00e4ltig umgehen.<\/p>\n\n\n\n

Laut einer Studie von Nightfall<\/a> waren bei den 100 gr\u00f6\u00dften Datenschutzverletzungen der letzten Jahre durchschnittlich 147,2 Millionen Personen pro Jahr betroffen. Insgesamt verursachten die Vorf\u00e4lle Kosten in H\u00f6he von mindestens 8,8 Milliarden Dollar und enthielten 51 Milliarden Datens\u00e4tze. Wir brauchen bessere M\u00f6glichkeiten, Nutzerinformationen sicher und einfach auszutauschen. Nur so k\u00f6nnen wir uns von den Profilierungs- und Anmeldeservern f\u00f6deralisierter Datenkraken auf Dauer endg\u00fcltig befreien \u2013 als Kunde wie als Plattform-Betreiber.<\/p>\n","protected":false},"excerpt":{"rendered":"

Digitale Plattformen erfordern ein hohes Ma\u00df an Sicherheit und Datensparsamkeit, um das Vertrauen der Nutzer nicht zu verlieren. Wie k\u00f6nnen wir heute dennoch notwendige Profildaten sicher und unkompliziert austauschen? Von OAuth und JWT zu selbstsouver\u00e4ner Identit\u00e4t.<\/p>\n","protected":false},"author":1,"featured_media":19475,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"colormag_page_container_layout":"default_layout","colormag_page_sidebar_layout":"default_layout","footnotes":""},"categories":[8,15078],"tags":[15124,15123,7553,15125,15122,15126],"class_list":["post-19473","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-artikel","category-authentifizierung","tag-did","tag-jwt","tag-oauth","tag-ssi","tag-turbine-kreuzberg","tag-w3c"],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/posts\/19473","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=19473"}],"version-history":[{"count":1,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/posts\/19473\/revisions"}],"predecessor-version":[{"id":19476,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/posts\/19473\/revisions\/19476"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/media\/19475"}],"wp:attachment":[{"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=19473"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=19473"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=19473"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}