Martina: Was mir persönlich immer geholfen hat, ist, wenn ich auch verstanden habe,
Martina: wie die Dinge im Hintergrund funktionieren.
Martina: Ich mag es persönlich gar nicht, wenn man mir einfach sagt, ja,
Martina: du musst jetzt deine Passwörter mit Argon2 hashen oder du musst jetzt einfach,
Martina: jetzt, um im OAuth-Kontext zu bleiben, den Authorization Code Flow mit PKCE verwenden.
Martina: Dann bist du sicher. Damit habe ich irgendwie immer Probleme,
Martina: weil ich irgendwie gerne auch wissen würde, warum denn?
Martina: Also warum ist das jetzt wichtig, dass ich diese Erweiterung nutze?
Martina: Und deshalb war es mir auch so wichtig, das sehr detailliert in meinem Buch
Martina: zu schreiben und ich hoffe, ich habe das auch sowohl auf einem abstrakten Level
Martina: als dann auch sehr detailreich geschafft, um halt klarzumachen,
Martina: wie die ganzen sogenannten Flows, wie die halt genau funktionieren.
Ali: Hallo und herzlich willkommen zu Klüger als gestern. Mein Name ist Ali Hackalife,
Ali: das ist ein Rheinwerk-Podcast und heute darf ich mit Martina Kraus sprechen.
Ali: Sie hat ein Buch geschrieben über Authentifizierung und Autorisierung,
Ali: was dahinter steckt und was es da zu lernen gibt, das besprechen wir heute. Hallo Martina.
Martina: Hallo, ja, danke für die Einladung, ich freue mich sehr.
Ali: Wie kommt es, dass du ein Buch zu diesem Thema schreibst, bei dem ich am Anfang
Ali: gedacht habe, wie füllt man dazu so viele Seiten? Ich habe dein Buch gelesen,
Ali: ich verstehe, wie man dazu so viele Seiten füllt, aber wie bist du zu IT-Security
Ali: und diesem speziellen Thema gekommen?
Martina: Ja, tatsächlich, seit Beginn habe ich mich generell für Security interessiert,
Martina: habe dann auch Informatik studiert, bin dann in die Web-Entwicklung letztendlich
Martina: reingekommen und darüber dann auch in das ganze Thema Web-Security.
Martina: Und da hat sich schon ein bisschen herausgestellt, dass mich das ganze Thema
Martina: Authentifizierung, Autorisierung, vor allem weil es erstmal so komplex erscheint,
Martina: mich wahnsinnig interessiert und ich liebe es tatsächlich nichts mehr als komplexe
Martina: Themen so einfach wie möglich darzustellen, damit sie auch jeder und jede verstehen kann.
Martina: Und so bin ich auch mal dabei gelandet, für einen führenden Identity Provider,
Martina: der das Ganze also auch wirklich implementiert, zu arbeiten und konnte da halt
Martina: mein Wissen rund um Authentifizierung und Autorisierung zu vertiefen.
Martina: Und ja, und umso mehr hat es mich dann gefreut, als ich gefragt wurde,
Martina: ob ich mein Wissen auch in ein Buch teilen darf. Und da habe ich natürlich sofort Ja gesagt.
Ali: Ich habe dein Buch in Vorbereitung auf die Sendung gelesen und ich hatte so
Ali: grob im Hinterkopf, also ich bin IT-Autodidakt, ich mache das auch irgendwie
Ali: seit 15 Jahren mittlerweile und ich hatte im Kopf, ja, es gibt da was mit Tokens
Ali: und dann gibt es hier und da einen Handshake und die überprüfen sich gegenseitig.
Ali: Aber wie das im Detail funktioniert, das war sowas, wo ich immer wusste,
Ali: wo ich nachschaue, aber es nie nachgeschaut habe.
Ali: Und du gehst in deinem Buch ja sehr detailreich durch, was überhaupt der Vorteil
Ali: von verschiedenen Systemen ist, wie zum Beispiel OAuth 2 und dem OpenID Connect
Ali: System und wo die Anwendung finden.
Ali: Und ich habe sehr viel darüber verstanden, was im Hintergrund passiert und vor
Ali: allem was in einer wahnsinnigen Geschwindigkeit im Hintergrund passiert und
Ali: worüber man ja gar nicht so nachdenkt. Also diese Mechanismen sind ja allgegenwärtig.
Ali: Und ich habe dann auch nochmal separat ein bisschen in der Historie gegraben
Ali: und was ich nicht wusste, wie neu das alles ist. Und vor allem OAuth,
Ali: das erste, ist von Leuten von Ma.gnolia und Twitter zusammen entwickelt worden.
Ali: Also Twitter war mal wirklich der Innovationsort fürs Internet.
Ali: Dann stellt sich ja direkt die Frage, ich habe doch einen Benutzernamen und ein Passwort.
Ali: Wofür brauche ich denn was anderes? Was können Benutzernamen und Passwort nicht,
Ali: was diese ganzen OAuth-Systeme können?
Martina: Einer der größten Herausforderungen, die halt da durch Twitter kam,
Martina: war die Einbindung von sogenannter Third-Party-Software oder Third-Party-Quellen, also Bilder
Martina: oder URLs oder Videos von YouTube, von vielleicht Google, vielleicht auch etwas,
Martina: was den Google-Kalender betroffen hat.
Martina: Und man musste dann halt Twitter die Berechtigung geben, auf vielleicht meinen
Martina: Google-Account zuzugreifen, auf mein YouTube-Profil zuzugreifen.
Martina: Und das hat tatsächlich die Internetwelt vor ganz großen Problemen gestoßen,
Martina: weil wie macht man das? Ich muss ja irgendwie Twitter jetzt meinen Nutzername und Passwort geben.
Martina: Klar, dann bin ich in Twitter eingeloggt, aber ich müsste ja jetzt Twitter meinen
Martina: Nutzername und Passwort geben, damit Twitter sich in meinem Namen jetzt auf
Martina: YouTube oder irgendeine andere,
Martina: Webseite, um mal vielleicht Bilder davon zu laden, einloggen zu können.
Martina: Damit Twitter eben diese Bilder oder Medien anzeigen kann. Also diese Weitergabe
Martina: von Zugriffsberechtigung.
Martina: Und da ist dann halt Nutzernamen und Passwörter an ihre Grenzen gestoßen,
Martina: weil ich finde es persönlich natürlich nicht so cool, wenn ich jetzt Twitter
Martina: meinen Nutzernamen und Passwort gebe, um vielleicht auf YouTube zugreifen zu können.
Martina: Und ich weiß ja auch nicht, was Twitter vielleicht mit den Nutzernamen und Passwort macht.
Martina: Und da hat dann halt sich ganz schnell herausgestellt, wir brauchen irgendetwas,
Martina: was wir Access Delegation nennen, also die Weitergabe von Zugriffsrechten,
Martina: dass ich Twitter einfach sagen kann, ja, liebes Twitter, du darfst jetzt genau
Martina: auf diese Medien zugreifen,
Martina: und dann darfst du sie anzeigen, aber sonst darfst du auch nichts mehr machen.
Martina: Also du darfst nicht irgendwelche anderen Bilder laden oder du darfst da nicht
Martina: in meinem Namen des Google-Accounts auf irgendwelche Inhalte oder meine E-Mails
Martina: zugreifen, sondern wirklich nur sehr dediziert, um zum Beispiel ein Bild anzuzeigen in Twitter.
Ali: Und dieses Weiterleiten von diesen sehr spezifischen Zugriffsrechten,
Ali: dafür brauche ich dann mehr als Nutzername und Passwort und da kommen dann Tokens
Ali: beziehungsweise die OAuth Mechanismen zum Greifen?
Martina: Absolut richtig, genau. Denn, also da greift mir jetzt schon ein bisschen viel
Martina: vor, aber quasi, wenn ich mich in so einem Identity Provider einlogge,
Martina: dann erhalte ich diesen sogenannten Access Token.
Martina: Und da steht halt ganz genau drin, welche Berechtigungen jetzt dieses Token hat.
Martina: Das ist auch völlig losgelöst dann letztendlich von dem Nutzer oder Nutzerin.
Martina: Jeder, der eigentlich dieses Token dann hat, und darf eben auf die APIs,
Martina: auf die Daten, auf die Services zugreifen mit den Berechtigungen,
Martina: die eben letztendlich in diesem Token vorhanden sind.
Ali: Wer sind solche Identity Provider? Also wer bestätigt, dass das gerade eine echte Identität ist?
Martina: Das können zum Beispiel Google sein. Es gibt Google Identity.
Martina: Wir haben aber auch Entra ID, kennt man wahrscheinlich. Früher hieß das Azure, Microsoft Azure AD.
Martina: Wir haben aber auch Open Source Lösungen wie zum Beispiel Keycloak.
Martina: Man kann aber auch ganz verrückt sein und das quasi selbst implementieren.
Martina: Da bietet zum Beispiel Java Spring Security, die bieten sogar eigene Bibliotheken
Martina: an, um quasi so einen Identity Provider zu implementieren.
Martina: Konkret würde ich davon aber abraten, da gibt es einfach zu viel,
Martina: was man leider falsch machen kann.
Martina: Ich würde da eher auf sogenannte Identity-as-a-Service-Lösungen,
Martina: wie sie halt von auch zum Beispiel Auth0 oder Okta oder Entra ID angeboten werden
Martina: oder zumindest halt so eine,
Martina: Self-Hosting-Lösung, wie sie zum Beispiel von Keycloak angeboten wird, zurückgreifen.
Ali: Das ist ja generell bei Security ein riesiges Thema, wo ich auch in meiner IT-Karriere
Ali: sehr oft drüber gestolpert bin, dass Leute sagen, die Kryptografie dafür,
Ali: das machen wir einfach selbst, anstatt diese Library zu benutzen,
Ali: dann sind wir unabhängig.
Ali: Und das war in der Regel immer der Schuss in den Fuß. Also es ging danach nie
Ali: besser, weil es gibt einen Grund, dass sich da große Industriestandards etabliert
Ali: haben und nicht alle ihre eigene Suppe kochen.
Martina: Absolut. Also es betrifft auch hier natürlich nicht nur OAuth oder OpenID Connect,
Martina: wenn ich auch beispielsweise meine Passwörter hashen möchte.
Martina: Da gibt es bestehende Algorithmen, also bestehende Hash-Funktionen wie beispielsweise
Martina: scrypt oder Argon2 und die will ich auch gar nicht selbst implementieren.
Martina: Da gibt es Leute, Kryptografen, die haben sich darüber Gedanken gemacht,
Martina: haben dazu mathematische Paper verfasst und sehr clevere Menschen,
Martina: viel cleverere Menschen als ich es bin definitiv, haben diese Hash-Algorithmen
Martina: dann auch implementiert.
Ali: Ja, um mal einen Begriff in den Raum zu werfen. Bei elliptischer Kryptografie
Ali: sitze ich immer davor und habe das Gefühl, jemand erzählt mir gerade etwas,
Ali: das ist so sci-fi, dass ich beeindruckt bin, dass Menschen das können.
Ali: Aber ich habe großen Respekt davor und ich bin einfach froh,
Ali: dass ich nur eine Library einbinden muss und das nicht verstehen muss.
Ali: Aber zum Thema Verstehen. Du sagtest gerade, Passworte hashen.
Ali: Warum ist in der Moderne, wir haben jetzt das mit dem ein anderer Anbieter möchte,
Ali: Daten durchleiten können, beziehungsweise Zugriffe minimal gewährleisten,
Ali: auf spezielle Dinge angerissen.
Ali: Aber warum reicht es nicht mehr, dass ich sage, ich habe Nutzernamen und Passwort
Ali: und meinetwegen ist das Passwort noch gehasht. Das heißt, Twitter selbst hat
Ali: mein Passwort gar nicht im Klartext da liegen oder beliebiger anderer Online-Dienst
Ali: hat mein Passwort gar nicht mehr im Klartext da liegen.
Ali: Welche anderen Vorteile bringen mir Möglichkeiten wie OAuth dabei,
Ali: wenn ich mich mit einer Plattform verbinde oder Plattform untereinander verbinde?
Martina: Also, da muss man tatsächlich etwas differenzieren, weil OAuth beschäftigt sich
Martina: gar nicht so mit der Frage Nutzername, Passwort.
Martina: OAuth ist per se ein reines Autorisierungsframework.
Martina: In OAuth ist gar nicht bestimmt, wie sich dieser Nutzer jetzt eigentlich authentifiziert.
Martina: Also der kann sich dann mit dem Nutzername Passwort authentifizieren,
Martina: der kann sich mit einem Passkey authentifizieren, mit einem zweiten,
Martina: dritten, fünften Faktor, wie auch immer.
Martina: Das ist in OAuth selbst gar nicht beschrieben.
Martina: Was OAuth letztendlich eigentlich nur beschreibt ist, wie erhält jetzt ein Nutzer
Martina: oder Nutzerin, nachdem er oder sie sich identifiziert hat, nachdem das quasi
Martina: geklärt ist, jetzt einen Token,
Martina: um dann mit diesem Token eben, in dem gewisse Berechtigungen drinstehen,
Martina: dann letztendlich die richtigen APIs, die richtigen Services aufrufen kann.
Martina: Und dabei ist ganz klar beschrieben, was halt in diesem Access-Token drinsteht.
Martina: Dass dieser wirklich nur für
Martina: eine Teilmenge von Berechtigung oder auch für eine Teilmenge an Services.
Martina: Ich kann nicht mit dem einen Access-Token jetzt eine Google API aufrufen und
Martina: mit demselben Access-Token vielleicht dann noch einen anderen Service aufrufen,
Martina: um gegebenenfalls davon noch Bilder zu laden.
Martina: Und das ist halt, wie gesagt, ganz streng getrennt voneinander.
Martina: Und Authentifizierung, wie das Ganze vonstatten geht, darum kümmert sich tatsächlich
Martina: eigentlich eher dann OpenID Connect.
Ali: Jetzt hast du gerade gesagt einen zweiten, dritten oder fünften Faktor.
Ali: Um das hier nochmal kurz anzureißen, du und ich, wir wissen was damit gemeint
Ali: ist, viele Nutzer sind bestimmt schon mal über den Second Factor oder Two Factor
Ali: Authentication gestolpert, die ja mittlerweile immer gängiger wird,
Ali: wo ich auch sagen muss, SMS ist ein wahnsinnig schlechter Second Factor, weil
Ali: mir so passiert, mein Telefonanbieter hat, nachdem ich den Vertrag gelöscht
Ali: habe, die Nummer nicht mehr angeboten und
Ali: stellt sich raus, das war zu einem meiner GitHub-Accounts
Ali: der Second Factor, dass ich eine SMS an dieser Handynummer bekommen kann und
Ali: dann habe ich mich da ausgeschlossen.
Ali: Und dann steht GitHub da als Plattform, die dir sagt, ja, also wir können die
Ali: nicht verändern, das musst du schon können. Und mein Telefonprovider sagt,
Ali: ja, die Nummer ist in unserem Pool, die können wir nicht nochmal vergeben,
Ali: auch nicht, wenn du ganz lieb bitte sagst.
Ali: Also bei der Frage, was sind weitere Faktoren, können wir vielleicht nochmal
Ali: reingehen und erklären, bei dem, was die meisten Leute als Second Factor kennen,
Ali: wie sieht das idealerweise aus? Da gibt es ja Unterscheidungen zwischen etwas,
Ali: das ich habe, etwas, das ich weiß und so weiter.
Martina: Genau, ja. Das, was du natürlich beschreibst, ist wirklich so das Worst-Case-Szenario.
Martina: Aber auch wie du schon richtig gesagt hast, dieser SMS-Code gilt eigentlich
Martina: als so das Unsicherste, was man nutzen kann.
Martina: Was man normalerweise nutzt, sind sogenannte Authenticators auf dem Smartphone.
Martina: Die werden beispielsweise von Microsoft oder Google angeboten oder auch natürlich
Martina: hat jedes Betriebssystem sowie Android oder auch iOS ihre eigenen Authenticators.
Martina: Und letztendlich kann ich damit eben mein Account verknüpfen.
Martina: Und was dann eigentlich passiert ist, dass auf meinem Smartphone wird quasi ein Code generiert.
Martina: Und das ist meistens so ein sechsstelliger Code und der ist dann für 60 Sekunden dann gültig.
Martina: Und immer wenn ich mich eingeloggt habe mit Nutzername und Passwort,
Martina: werde ich eben nach diesem zweiten Faktor, nach diesem Code gefragt.
Martina: Und das ist meistens etwas, was ich habe. Also das kategorisiert man in diese
Martina: zweite Faktorkategorie etwas, das ich habe.
Martina: Es gibt natürlich auch die Möglichkeit, etwas, was ich bin, das wäre dann,
Martina: dass der zweite Faktor tatsächlich eine Art Gesichtserkennung ist oder auch
Martina: meine biometrischen Daten, also mein Fingerprint zum Beispiel,
Martina: dass wenn ich mich zum Beispiel auf meinem Smartphone irgendwie einlogge,
Martina: dass mein Smartphone mich dann auch nur fragt.
Martina: Bitte gebe mir noch einen zweiten Faktor als dein Fingerprint halt letztendlich zur Verfügung.
Martina: Was es natürlich auch noch gibt, ist die IP-Adresse oder auch mein Standort, wo ich gerade bin.
Martina: Da können dann sehr viele verschiedene Arten als sogenannter zweiter Faktor zugezogen werden.
Martina: Aber klar, am besten eignet sich halt eben etwas Biometrisches,
Martina: also wirklich so Iris-Scan, wie man es so aus James-Bond-Filmen kennt.
Martina: Dass man dann jemanden vielleicht den Fingerabdruck klaut.
Martina: Sowas ist natürlich in der reellen Welt, kommt nicht so häufig vor.
Martina: Es gibt natürlich immer eine kleine Möglichkeit.
Martina: Man darf keine absoluten Aussagen treffen in der Sicherheit.
Martina: Aber ja, also sowas, was eher so nur in James-Bond-Filmen vorkommt,
Martina: ist ja in der Realität nicht immer ganz so gängig.
Martina: Und deshalb ist gerade so biometrische zweite Faktoren oder auch natürlich diesen
Martina: Code, von dem ich anfänglich gesprochen habe, am sichersten.
Ali: Also biometrische Faktoren sind natürlich beliebt, haben nur einen großen Nachteil.
Ali: Wenn sie einmal in die Öffentlichkeit gelangen, kann man sie nicht mehr ändern.
Ali: Ich kann meinen Fingerabdruck, meine Iris oder mein Gesicht nicht so ohne weiteres ändern.
Ali: Und dementsprechend, ich erinnere mich da sehr prominent an eine Pressekonferenz,
Ali: bei der Ursula von der Leyens Daumen mit einem Teleobjektiv fotografiert wurde und von,
Ali: ich glaube Schäuble war es, gibt es ein Wasserglas, von dem nach der Bundespressekonferenz
Ali: mal mit Talgpulver einfach ein Negativ vom Finger runtergepinselt wurde, um zu zeigen,
Ali: die Menschen, die sich hier dafür einsetzen, dass biometrische Daten in,
Ali: ich glaube Reisedokumente war es, damals verpflichtend reinkommen.
Ali: Wenn deren eigene Daten dann in die Öffentlichkeit geraten, sind sie ganz alert.
Ali: Wo ich sagen muss, ich kann das auch schon verstehen. Ich fände es auch nicht
Ali: schön, wenn mein Fingerabdruck öffentlich rumgereicht werden würde,
Ali: aber da ist halt das Problem. Wenn diese Form der Verifizierung einmal bekannt
Ali: ist, ist sie nicht komplett wertlos, aber ein Angriffsvektor.
Martina: Ja klar, das ist auf jeden Fall ein guter Punkt und deshalb bevorzuge ich,
Martina: wenn man noch Nutzername und Passwort benutzt, als zweiten Faktor eben halt
Martina: diesen sechs- oder fünfstelligen Code, je nach Authenticator,
Martina: den man dann eingeben muss.
Martina: Wenn wir generell gerade ein bisschen davon sprechen, von Authentifizierung,
Martina: gibt es ja noch eine weitere Möglichkeit, die ganz von Nutzername und Passwort
Martina: mittlerweile absieht und das sind die sogenannten Passkeys.
Ali: Oh ja, bin ich großer Freund von. Und hast du auch in deinem Buch angeschnitten.
Ali: Ich finde, die Idee dahinter ist so schön, dass man gar nicht mehr sagt,
Ali: ich gebe dir als Website, als Anbieter
Ali: die Informationen, mit denen ich mich authentifiziere, sondern ich gebe dir
Ali: im Prinzip ein Schloss in die Hand, zu dem ich den Schlüssel halte und du prüfst
Ali: nur, ob ich das Schloss aufschließen kann.
Ali: Das ist so eine elegante Lösung, die sich sehr zeitgemäß anfühlt.
Ali: Also ich bin großer Passkey-Fan.
Martina: Ich auch tatsächlich. Also ich reise viel auf Konferenzen und rede eigentlich
Martina: nur über Passkeys, weil das für mich so die bislang jetzt vielversprechendste
Martina: Variante ist, um sich auch sicher authentifizieren zu können.
Martina: Aber wie gesagt, das sind alles so auch Dinge, weil zum Beispiel Passkeys,
Martina: das hat gar nichts mehr mit OpenID Connect oder OAuth zu tun.
Martina: Das ist zum Beispiel in der FIDO2-Allianz, das ist Fast Identity Online,
Martina: das ist quasi eine eigene Gruppierung, die sich zusammengefunden hat,
Martina: um einfach passwortlose Authentifizierung zu ermöglichen.
Martina: Und darüber könnte man auch stundenlang natürlich reden. Aber OIDC und OAuth beschäftigt
Martina: sich quasi so ein bisschen mit den Schritten danach.
Martina: Also womit sich dann OIDC, also OpenID Connect noch beschäftigt,
Martina: ist beispielsweise auch diese Identity Federation, wie man es auch so gerne
Martina: nennt, dass ich beispielsweise mich auch einfach mit Google einloggen kann.
Martina: Man kennt es ja vielleicht, man ist auf irgendeiner Webseite und dann bekomme
Martina: ich die Möglichkeit, mich über vielleicht damals auch noch Twitter-Account oder
Martina: auch Facebook-Account, GitHub oder auch eben mit Google einloggen zu können.
Martina: Das heißt, ich brauche gar nicht eine wirkliche Registrierung auf diesem Service,
Martina: sondern ich kann mich einfach dann einloggen mit eben Google oder auch von mir aus auch meinem,
Martina: iCloud Keychain Passwort, also meiner Apple ID ist das dann.
Martina: All die Möglichkeiten, das ist tatsächlich auch in OIDC beschrieben worden.
Martina: Und das führt natürlich dazu, wenn ich dann den Service wieder besuche,
Martina: dann kann ich einfach nur auf Login with Google quasi drücken.
Martina: Dann werde ich vielleicht kurz zu Google redirected und muss mich dann gegebenenfalls
Martina: nochmal gegenüber Google authentifizieren. Aber das ist dann das Wilde.
Martina: Ich sehe dann gar nicht so richtig, was passiert, weil wenn ich dann auf Login
Martina: with Google drücke, dann sieht man, dass in dieser Browser-Adresszeile wilde
Martina: Dinge passieren und dann bin ich plötzlich eingeloggt.
Martina: Und genau diese wilden Dinge, die da hinten dran passieren, das ist halt letztendlich
Martina: auch, was in OIDC so genau spezifiziert ist.
Ali: Bevor wir da im Detail drauf eingehen, es gibt natürlich die valide Kritik,
Ali: dass bei den Sign-in-with-Buttons, dass man sich da mehr und mehr abhängig von Big Tech macht.
Ali: Also ich selbst bin im Apple-Ökosystem, ich habe einige Services,
Ali: bei denen ich Sign in with Apple angeklickt habe für die Convenience, vor allem wenn man
Ali: mal was nur schnell ausprobieren möchte und man möchte sich jetzt nicht einen
Ali: Account anlegen, wobei das ja auch mittlerweile immer einfacher geworden ist,
Ali: aber es gibt dann noch einige Services, wo ich Sign in with Apple angeklickt habe.
Ali: Wenn ich jetzt sagen würde, ich möchte Open Source gehen, ich verlasse macOS,
Ali: dann wäre das schon eine ziemliche Arbeit, all meine Accounts aufzuspüren,
Ali: in denen ich Sign in with Apple angeklickt habe und da neue Credentials zu hinterlegen,
Ali: um die Accounts zu behalten.
Ali: Also das kommt natürlich auch mit seinem Preis, dass man entsprechend diese Services vorschickt.
Martina: Absolut. Und ein weiterer Punkt ist natürlich, angenommen, ich habe jetzt überall
Martina: mich eingeloggt mit Google, wenn dann jemand mal mein Google-Passwort hat und
Martina: vielleicht keinen zweiten Faktor hat, das ist nicht ausreichend geschützt und so weiter.
Martina: Und die Person, der Angreifer, die Angreiferin sich dann in meinen Google-Account
Martina: einloggen kann, dann kann die Person sich natürlich ebenfalls in alle,
Martina: alle, alle anderen Services automatisch einloggen, weil ich ja überall Login
Martina: mit Google geklickt habe.
Martina: Das heißt, es ist nicht ganz so von der Hand zu weisen, dass es natürlich ein
Martina: paar Risiken mit sich bringt.
Martina: Wo wir natürlich erneut zu dem Punkt kommen, einfach Passkeys zu benutzen, für jeden Service einen.
Martina: Aber wie du schon gesagt hast, das ist ja auch eine Art Convenience.
Martina: Und ich bin in beiden oder in vielen Ecosystemen unterwegs.
Martina: Glaube zwar eher so ein bisschen in den Google-Ecosystemen, aber dadurch,
Martina: dass ich auch Mac habe, habe ich auch viel in meiner iCloud Keychain,
Martina: dass es so ein bisschen verteilt ist. Aber ja, man macht sich absolut abhängig
Martina: von den ganzen Vendors auf jeden Fall.
Ali: Jetzt hatten wir, bevor wir auf dieses Detail eingegangen sind,
Ali: noch darüber gesprochen. Du meintest, da passiert da ganz viel ganz schnell
Ali: in deiner Adresszeile und du bekommst das gar nicht so im Detail mit.
Ali: Das gehst du ja in deinem Buch wirklich mal im Detail nach.
Ali: Wer da an wen, wo, wie eine Information weiterleitet, die dann von wem wie bestätigt
Ali: und validiert und weitergereicht wird, sodass die Services im Zweifel nur wissen,
Ali: ist es ein legitimer Zugriff und nicht mehr über mich wissen müssen.
Martina: Ja, genau, weil für mich ist es ganz wichtig. Oder was mir persönlich immer
Martina: geholfen hat, ist, wenn ich auch verstanden habe, wie die Dinge im Hintergrund funktionieren.
Martina: Ich mag es persönlich gar nicht, wenn man mir einfach sagt, ja,
Martina: du musst jetzt deine Passwörter mit Argon2 hashen oder du musst jetzt einfach,
Martina: jetzt, um im OAuth-Kontext zu bleiben, den Authorization-Codeflow mit PKCE verwenden.
Martina: Dann bist du sicher. Ja, damit habe ich irgendwie immer Probleme,
Martina: weil ich irgendwie gerne auch wissen würde, warum denn?
Martina: Also es ist jetzt vielleicht aufwendiger, diese Erweiterung PKCE noch zu verwenden,
Martina: weil ich das irgendwie auch konfigurieren muss und ich will doch einfach nur
Martina: ein Access-Token haben.
Martina: Warum ist das jetzt wichtig, dass ich diese Erweiterung nutze?
Martina: Und deshalb war es mir auch so wichtig, das sehr detailliert in meinem Buch zu schreiben.
Martina: Und ich hoffe, ich habe das auch sowohl auf einem abstrakten Level als dann
Martina: auch sehr detailreich geschafft, um halt klarzumachen, wie die ganzen sogenannten Flows,
Martina: da kann ich gleich dazu kommen, was die genau bedeuten, und wie die halt genau funktionieren.
Martina: Ein großes Problem oder eins der größten Probleme, die OAuth löst oder versucht
Martina: zu lösen, ist eben, ich habe jetzt eine Webseite und in dieser Webseite möchte ich mich einloggen.
Martina: Diese Webseite möchte natürlich auch Daten haben und diese Daten sollen ja geschützt
Martina: sein mit so einem Access, also mit einem Access-Token, sprich,
Martina: wenn diese Webseite Daten braucht.
Martina: Angenommen, wir sind vielleicht auf einer Shop-Webseite, wo ich irgendwie einkaufen
Martina: kann und dann sollen mir ja quasi die ganzen Produkte angezeigt werden.
Martina: Das heißt, ich rufe in den meisten Fällen so eine Art Produkt-API auf.
Martina: Ich will ja vielleicht aber jetzt auch meinen Warenkorb sehen und ich will jetzt
Martina: natürlich nur die Produkte angezeigt bekommen, die ich jetzt bereits in den
Martina: Warenkorb gelegt habe oder die ich bereits eingekauft habe.
Martina: Auch wenn ich meine Rechnungen einsehen will, das soll ja alles beschützt sein.
Martina: Deshalb muss ich an diese API so einen Access-Token senden.
Martina: Jetzt ist es aber gar nicht so einfach, an diesen Access-Token zu kommen.
Martina: Denn wie schaffe ich denn es sicher, meinem Authorization-Server zum einen natürlich
Martina: zu beweisen, dass ich ich bin.
Martina: Okay, da gibt es so dieses Nutzername-Passwort. Okay, das funktioniert dann schon.
Martina: Aber dann, nachdem ich mich erfolgreich vielleicht authentifiziert habe,
Martina: muss ja dieser Identity Provider irgendwie jetzt diesen Access Token wieder
Martina: zurücksenden an meinen Browser, damit der das halt weiterverarbeiten kann.
Martina: Und dieses Zurücksenden, das hat wahnsinnig.
Martina: Viele Risiken und Probleme, weil sich da eben Angreifer und Angreiferinnen theoretischerweise
Martina: relativ einfach dazwischen schalten können und so tun können gegenüber diesem Identity Provider.
Martina: Ja, ja, du kannst den Token an mich senden und nicht an das,
Martina: was du hast für eine Anfrage bekommen von so einem anderen Browser,
Martina: aber sende mal den Token bitte an mich.
Martina: Und da gibt es viele verschiedene Angriffsszenarien und deshalb macht es es
Martina: eben auch so kompliziert, weil...
Martina: Ein Hauptproblem, kurz noch der eine Satz dazu, ein Hauptproblem ist,
Martina: dass ich halt als Browser kann ich dem Authorization Server oder auch Identity
Martina: Provider genannt, nicht sagen, guck mal, hier, ich bin der legitime Client,
Martina: mir darfst du den Access Token geben.
Martina: Meine Client-Application, meine heutzutage Single-Page-Application,
Martina: kann sich ja nicht authentifizieren gegenüber dem Authorization-Server.
Martina: Der kann ja nicht sagen, guck mal, ich bin der richtige Client,
Martina: der liebe Client, mir kannst du den Access-Token jetzt geben.
Martina: Wie soll das funktionieren, wenn ich ein Secret oder so ein Passwort
Martina: halt in meiner Single-Page-Application speichere, dann kann die natürlich jeder
Martina: einsehen, weil das liegt dann im JavaScript rum, es ist dann im Browser ausgeliefert
Martina: und das kann natürlich jeder über die Dev-Konsole letztendlich auslesen.
Ali: Ab dem Moment, wo ich im Browser im Cookie hinterlege, ich bin vertrauenswürdig,
Ali: ist das etwas, was andere Leute im Prinzip lokal selbst reinschreiben könnten oder eben ablesen.
Martina: Genau, nicht nur in dem Cookie. Der Cookie ist nochmal ein bisschen anders tatsächlich.
Martina: Der Cookie ist schon beschützt durch gewisse andere Maßnahmen,
Martina: aber der Cookie hilft uns gar nicht so viel, weil der Cookie darf halt nur immer
Martina: an dieselbe Domäne mitgesendet werden, wie von der Domäne, die den Cookie gesetzt hat.
Martina: Also zum Beispiel authserver.com. Wenn mein authserver.com mir ein Cookie setzt,
Martina: dann wird der Cookie ja nur mitgesendet, wenn ich ein Request an authserver.com sende.
Martina: Hauptsächlich, also damit das funktioniert, irgendwie würde das nur möglich
Martina: sein, dass ich irgendwie ein Secret in mein JavaScript lege und da kann ich
Martina: es natürlich jederzeit auslesen.
Martina: Aber klar, theoretischerweise, wenn ich das Secret auch so in den Cookie speichere
Martina: und das Secret ist immer gleich, was es halt vielleicht sein muss dann für den
Martina: Client, dann kann ich auch den Cookie natürlich über die Developer-Konsole mal
Martina: kurz öffnen und auch reingucken und das auslesen.
Ali: Und jetzt hattest du vorhin gesagt, die Flows im Hintergrund seien interessant.
Ali: Also ich denke, es ist nachvollziehbar, dass es ein Problem ist bei diesen Großanwendungen,
Ali: also zum Beispiel beliebiger Online-Webshop, wo es relativ reibungslos sein muss.
Ali: Und natürlich im Hochsicherheitsbereich würde man das Ganze anders regeln,
Ali: dass man sagt, was hier untereinander spricht, das hat alles Zertifikate, die entweder, also
Ali: das kann man ja beliebig komplex denken, dass ich darkside alle Zertifikate
Ali: nur aus diesem Gebäude heraus vergeben habe mit Geräten, die physisch vor Ort waren.
Ali: Da kann ich mir relativ sicher sein, dass die Geräte, die sich da zurückmelden
Ali: mit dem entsprechenden Zertifikat, die Geräte sind, die ich rausgegeben habe.
Ali: Aber ab dem Moment, wo ich das on scale mache, wie ein
Ali: großer beliebiger Online-Shop, der ja nicht mit den Leuten vorher noch Zertifikate
Ali: austauschen kann in Person, ab da an brauche ich ja andere Wege,
Ali: um sicher zu gehen, dass meine Rücksendung auch bei einem entsprechenden Browser
Ali: ankommt und nicht unterwegs abgegriffen werden kann.
Ali: Also da gibt es auch in der Wikipedia beschrieben
Ali: ein potenzielles Angriffsszenario und man versucht ja Man-in-the-Middle zu umgehen,
Ali: aber wenn ich bei den Authentifizierungsservern
Ali: Schad-Server dabei habe, wie gesagt, große Diagramme, komplizierte Angriffe,
Ali: ich bin froh, dass die Wikipedia das sehr vereinfacht hat, aber da gibt es ja
Ali: durchaus Probleme, dass da nicht ganz klar ist, an wen schicke ich jetzt zurück.
Ali: Ich kann nicht ohne weiteres als Authentifizierungsserver bestätigen,
Ali: dass der, dem ich gerade die Authentifizierung erteilt habe,
Ali: der ist, der sie angefordert hat.
Martina: Ja, also absolut richtig. Und das ist halt hauptsächlich, wie gesagt,
Martina: eins der größten Probleme bei den Single-Applications, die wir heutzutage haben.
Martina: Es gibt natürlich auch Szenarien, wo wir Microservices haben,
Martina: wo ein Server mit einem anderen Server irgendwie redet.
Martina: Meistens ist man ja so mittlerweile, dass man so seine ganze Web-Applikation
Martina: so ein bisschen schneidet, vertikal und es gibt verschieden,
Martina: für jede Domäne gibt es einen eigenen Microservice.
Martina: Und klar, wenn ich dann Daten anfrage, die über mehrere Microservices gehen,
Martina: dann müssen die ja auch miteinander reden, dass alle Daten zusammen kumuliert
Martina: werden und halt als eine Datenmenge vielleicht wieder zurückgegeben werden.
Martina: Das wäre zumindest ganz nett, dass ich nicht als Client alle Microservices einzeln aufrufen muss.
Martina: Und da kommt es natürlich auch zu Trage, dass sich ein Microservice auch einen
Martina: Access-Token holt, damit dieser sich natürlich auch ausweist als,
Martina: hey, guck mal, ich habe die Berechtigung und darf jetzt auf deinen Daten ebenfalls zugreifen.
Martina: Der größte Vorteil ist halt daran, dass ich, wenn ich in der Backend-Welt bin,
Martina: hinter gesicherten Firewalls, es zumindest weitaus ungefährlicher ist,
Martina: dass jetzt ein Backend natürlich.
Martina: Eine kleine ID und einen kleinen Secret nennt sich das dann,
Martina: also halt ein Secret letztendlich speichere, um sich damit halt ein Token zu holen.
Martina: Und das ist in diesen sogenannten Flows niedergeschrieben.
Martina: Das ist auch eigentlich ein guter Einstieg vielleicht mal da rein,
Martina: denn so ein Backend, da gibt es dann wie gesagt einen Microservice und der agiert
Martina: jetzt als ein OAuth-Client, weil er Daten haben möchte.
Martina: Und dieser Microservice, der
Martina: nimmt jetzt einen speziellen Flow, der nennt sich Client-Credentials-Flow.
Martina: Der macht nichts anderes, als einmal zum Authorization-Server zu gehen und zu
Martina: sagen, hey, guck mal, ich habe hier ein Client-ID, Client-Secret,
Martina: ich möchte mit dem Microservice sprechen, bitte stelle mir so einen Access-Token aus.
Martina: Und dieser Flow ist super einfach und super simpel, weil dann der Authorization-Server
Martina: sagt, okay, ich kenne dich, du hast mir dein richtiges Passwort verraten, also dieses Secret,
Martina: Und ich schreibe eben dein Target Service, wo du Daten haben möchtest,
Martina: auch noch als eine Audience, also damit auch klar ist, für wen das Token bestimmt
Martina: ist, in den Token rein und dann hast du den Access Token.
Martina: Und das ist alles super simple und alles super cool.
Martina: Aber wie gesagt, das geht halt nicht so einfach in Single-Page-Application.
Martina: Und was ich immer, wenn ich über OAuth rede, dann liebe ich es immer zu sagen,
Martina: dass es halt bei OAuth rund irgendwie,
Martina: sieben Flows gibt und fünf davon sind nur alleine für Single-Page-Applications oder für das Web.
Martina: Sagen wir mal, das hat nicht gestimmt, Single-Page-Application nicht,
Martina: aber für die Web-Applikation, dass man
Martina: als Web-Applikation ebenfalls ein Access-Token holen kann, was halt die,
Martina: Schwierigkeit und die Irrsinnigkeit vielleicht auch ein bisschen am besten beschreibt dafür natürlich.
Ali: Das ist durchaus sehr nachvollziehbar. Vor allem, wir leben ja mittlerweile
Ali: in einer Welt, wo Web-Apps omnipräsent sind und Dinge werden zu immer kruderen,
Ali: einfach nur anders ausgespielten Websites, wenn man mal wirklich tief gräbt.
Ali: Und dementsprechend, ich verstehe, dass da so ein großer Fokus drauf liegt.
Ali: Ich verstehe, dass das große Probleme mit sich bringt.
Ali: Du sagtest gerade, der Authentication-Server kann das sehr einfach dann bestätigen.
Ali: Und ein Begriff, der in deinem Buch auch vorkommt, zum Thema Einfaches bestätigen, das ist Zero Trust.
Ali: Und Zero Trust ist eine der Sachen, ich weiß nicht, ob es da auch Anwendung findet.
Ali: Im Zweifel musst du mich da korrigieren.
Martina: Na klar, also Zero Trust ist eigentlich ja genau das.
Martina: Also Zero Trust gibt es in verschiedenen Ebenen,
Martina: also dass ich als Server auch keinem Client vertraue, aber Zero Trust ist oftmals
Martina: eigentlich so in der Microservice-Welt,
Martina: bedeutet letztendlich, dass ich natürlich auf jeden Fall immer auch mit einem
Martina: Access-Token an Inter-Service-Kommunikation letztendlich halt haben muss,
Martina: dass ich da auch immer ein Access-Token haben muss.
Martina: Und natürlich auch TLS, also dass auch die Services untereinander immer nur
Martina: verschlüsselt sprechen, dass ich halt nur, weil ich vielleicht im selben Netzwerk bin,
Martina: dass ich halt nicht einfach belanglos jetzt jedem Service vertraue,
Martina: der meine Daten haben möchte.
Ali: Wo du TLS sagst, also Transportverschlüsselung. OAuth in der ersten Version
Ali: war noch für HTTP entwickelt und dementsprechend ohne Transportverschlüsselung
Ali: in mind. Und da sind wir jetzt auch, wie gesagt, 2007 entwickelt.
Ali: Da hat sich ja auch mittlerweile viel getan.
Martina: Ja, klar. Also OAuth 2 setzt auf jeden Fall TLS voraus. OAuth 1 hatte halt
Martina: so ein bisschen noch den Vorteil, dass wir so etwas hatten, was sich Sender-Constrained-Tokens nennt.
Martina: Also dass das Token quasi hochkryptografisch gebunden ist und klar ist,
Martina: ich klar verifiziere als Empfänger des Tokens, der den Token dann auswertet,
Martina: ganz klar verifizieren kann, dass der Token auch vom richtigen Sender kommt.
Martina: Da konnte ich nicht einfach so ein Token mal austauschen, sage ich mal,
Martina: oder an jemanden geben und die Person kann dann mit ihrem Client und dem Token
Martina: irgendwie mal eine Anfrage senden.
Martina: Das wäre auf keinen Fall gegangen, weil das halt kryptografisch an den Absender gebunden ist.
Martina: Und das hat man auch Sender-Constraining genannt. Und das ist etwas,
Martina: was man halt mit OAuth 2 absolut entfernt hat. Da gibt es kein Sender-Constraining mehr.
Martina: Da ist dann das entstanden, was man auch vielleicht kennt, das nennt sich dann Bearer-Token.
Martina: Also der Träger des Tokens, der ist legitimiert, einfach jetzt die Anfrage zu senden.
Martina: Das bringt natürlich das Problem auf sich, wenn ich so eine schöne Cross-Site-Scripting-Attacke
Martina: auf meiner Webseite habe und mein Access-Token liegt vielleicht in einem Speicher
Martina: im Webbrowser, der über JavaScript zugänglich ist,
Martina: wie beispielsweise der wunderschöne Local oder Session Storage,
Martina: dann könnte ich halt mit so einer Cross-Site-Scripting-Attacke diesen Access-Token stehlen.
Martina: Und wenn ich ihn gestohlen habe, dann kann ich halt einfach so den Access-Token selbst verwenden.
Martina: Der hat eine gewisse Gültigkeit.
Martina: Eigentlich soll er meistens so fünf bis 15 Minuten lang gültig sein.
Martina: Aber 15 Minuten, wenn ich ihn dann bereits nach zwei Minuten gestohlen habe,
Martina: dann habe ich noch 13 Minuten Zeit.
Martina: Damit kann ich halt schon noch einiges anstellen und auch machen im Namen des
Martina: Nutzers oder der Nutzerin.
Ali: Wir hatten ja gerade Zero Trust auch beschrieben und Zero Trust ist so eine
Ali: der Sachen, da gibt es schöne, einfache Schaubilder zu, über die ich mich sehr
Ali: gefreut habe und wenn man dann das erste Mal die Mathematik dahinter sieht,
Ali: dann bin ich wirklich sehr beeindruckt.
Ali: Ich weiß nicht, wie tief du da mal gegraben hast. Also ich finde Zero Trust
Ali: zu erklären ist gar nicht so schwer, aber Zero Trust nachzubauen ist,
Ali: oh mein Gott, was hat die Menschheit da geschafft, das ist im Prinzip die nächste Mondlandung.
Martina: Auf jeden Fall. Und es ist halt noch komplizierter, das auch umzusetzen und
Martina: so diszipliniert umzusetzen. Und klar gibt es Lösungen, die das anbieten.
Martina: Aber Zero Trust bedeutet halt auch Performance-Einbußen. Und das ist halt natürlich
Martina: etwas, was viele gerade in der sehr schnelllebigen Webwelt,
Martina: deshalb doch nicht implementieren wollen, also Zero Trust dann nicht so durchgängig
Martina: implementieren wollen, weil sie halt sagen, das ist zu viel Kryptografie.
Martina: Kryptografie sind performanceintensive Operationen und deshalb ist es nur so
Martina: ein halbes Zero Trust, das oftmals implementiert wird.
Ali: Also in der Idealvorstellung bedeutet Zero Trust jetzt hier einmal im Schaubild
Ali: gesprochen, das macht dann auch verständlich, was eins der Performance-Probleme ist,
Ali: dass ich dem Anbieter gegenüber gar nicht beweisen muss, dass ich weiß,
Ali: was er weiß, sondern es gibt dieses Schaubild von, es gibt eine Felswand,
Ali: in der es sind ganz viele Höhlen und Höhleneingänge und ein paar von denen sind
Ali: miteinander verbunden.
Ali: Und der Anbieter weiß, dass es einen direkten Weg gibt von der Höhle 1 zu der Höhle 2
Ali: und ich zeige ihm jetzt, dass ich diesen Weg kenne, indem ich in die eine Höhle
Ali: rein und aus der anderen Höhle rauskomme.
Ali: Aber es gibt hunderte mögliche Höhlenein- und -ausgänge. Das heißt,
Ali: es reicht nicht, wenn ich auf Verdacht sage, übrigens der Eingang ist der da
Ali: oben links und der Ausgang ist der da unten rechts, weil es könnten ganz viele andere Wege sein.
Ali: Ganz viele von diesen Höhlen sind theoretisch nicht miteinander verbunden.
Ali: Also ich muss sehr spezifisch beweisen, ich kenne Ein- und Ausgang und wie ich
Ali: zwischendrin belege, dass ich den Weg zwischen denen kenne, muss der Anbieter,
Ali: der verifiziert, gar nicht wissen. Für den reicht es, dass ich performen kann.
Ali: Ich kenne die Start- und die Endbedingungen und dazwischen kann ich nur über
Ali: komplizierte Kryptografie wirklich den Weg gefunden haben.
Ali: Das zu erraten, ist halt so ein klassisches Problem von, wenn man das bruteforced,
Ali: sind wir schnell an dem Punkt von, so viel Zeit hat das Universum nicht oder
Ali: es ist für die Anwendung nicht relevant, wenn man sagt,
Ali: Bruteforce ist möglich, aber bei der aktuellen Rechenleistung bräuchtest du
Ali: 1,5 Millionen Jahre, ist das ein Risiko, das man eingehen kann.
Ali: Hat aber das Problem, dass wenn ich anfange zu bruteforcen, der Authentifizierungsserver
Ali: erstmal damit überlastet ist, dass er die ganze Zeit sagen muss,
Ali: nee, das war nicht richtig, auch hier wieder nicht richtig, auch hier wieder
Ali: nicht richtig, ich mache die Session mal zu, neue Session kommt auf,
Ali: oh, du hast wieder mehrfach falsch angefragt.
Ali: Und das sind halt solche Probleme, die dann on scale dazu führen,
Ali: dass man als Anbieter, der mit Zero Trust verifizieren möchte,
Ali: schnell das Problem läuft, dass wenn man angegriffen wird, man einfach sehr
Ali: viele Ressourcen darauf werfen muss, dass jemand gerade versucht einzubrechen.
Martina: Ja, genau. Und wie du schon beschrieben hast, das sind halt super viele komplexe,
Martina: kryptografische Fahnen dahinter, es gibt aber tatsächlich also Zero Trust ist
Martina: ja auch mehr ist ja kein Produkt in dem Sinne ist ja kein,
Martina: etwas was man jetzt konkret anwenden kann, sondern ist ja mehr so ein Gedankenmodell,
Martina: was man dann halt letztendlich,
Martina: umsetzen kann, muss,
Martina: mit dem Nachteil dann natürlich, dass wir vielleicht ein bisschen Performance einbüßen müssen.
Ali: Jetzt hast du in deinem Buch am Ende ein Fazit geschrieben, in dem es darum
Ali: geht, wie sich die Moderne umsetzt. Also du hast moderne Ansätze und Standards
Ali: beschrieben, praktische Umsetzungen davon, wo man anfängt, wie man die umsetzen kann.
Ali: Und du machst auch einen Zukunftsausblick und der de facto Standard im Moment,
Ali: den beschreibst du ja auch. Und ein Kapitel, das JSON-Web-Token.
Ali: Ich denke, wir kommen nicht drum herum zu beschreiben, warum das gerade so wichtig ist.
Martina: Ja, JSON-Web-Tokens sind tatsächlich einfach erstmal komplett losgelöst von OAuth.
Martina: OAuth selbst sagt sogar, dass die Access-Tokens gar nicht JSON-Web-Tokens sein
Martina: müssen, sondern das können auch sogenannte Opaque-Tokens, nennen sich dann also
Martina: einfach nur Reference-Tokens in dem Sinne.
Martina: Aber in den meisten Fällen oder nahezu immer ist ein Access-Token halt so ein JSON-Web-Token.
Martina: Und das Coole an so einem JSON-Web-Token ist halt, dass es self-contained ist
Martina: und man kann es verifizieren. Was bedeutet das?
Martina: Da müssen wir vielleicht einen kleinen Zurückschwenker zu cookiebasierter Authentifizierung machen.
Martina: Wenn wir uns ja mit Cookies authentifizieren, ist das ja normalerweise so,
Martina: ich logge mich ein mit Passkey, Second Factor, wie auch immer ich mich halt authentifizieren möchte.
Martina: Und der Server, der in den meisten Fällen damals halt so eine traditionelle
Martina: Web App war, der baut dann eine Session auf und erstellt ein Session Cookie.
Martina: Und diese Session Cookie wird mir dann in meiner Web App eben.
Martina: Die ebenfalls von demselben Web-Server ausgeliefert wird. Und das war dann eigentlich
Martina: ganz cool, weil jedes Mal, wenn ich Daten haben wollte, habe ich halt so ein
Martina: Request an meinen Web-Server geschickt und der Browser setzt dieses Cookie ganz
Martina: automatisch. Also es war ein Browser-Feature.
Martina: Ich musste das Cookie nicht manuell speichern, nicht manuell auslesen.
Martina: Der Browser hat es einfach mitgesendet. Und der Nachteil davon war halt aber,
Martina: dass ich halt total stateful war.
Martina: Also, dass ich halt jedes Mal, wenn ich halt Daten haben wollte,
Martina: musste der Cookie mitgesendet werden.
Martina: Und ich konnte jetzt auch nicht einfach sagen, oh, schick mir jetzt bitte einen
Martina: Request an einen anderen Server, weil ich von dem auch Daten haben möchte.
Martina: Weil der andere Server wäre dann auf einer ganz anderen Domäne gelaufen und
Martina: hätte auch die Session gar nicht gespeichert und wüsste dann gar nicht, wer ich bin.
Martina: Und ich hätte mich da vielleicht auch nochmal einloggen müssen.
Martina: Das ist alles so ein bisschen nicht so vorteilhaft gewesen, weshalb man dann
Martina: natürlich gesagt hat, ja, wir wollen eine gewisse Flexibilität haben.
Martina: Es wäre super, wenn wir einfach etwas an die Server senden können und die Server
Martina: können total unabhängig von wer auch immer diesen Token ausgestellt hat, also
Martina: wer auch immer dieses Authentifizierungs- oder Autorisierungstoken ausgestellt hat,
Martina: halt einfach verifizieren, dass jetzt dieser Client oder Nutzer,
Martina: der diesen Token gesendet hat, eben die Daten haben darf.
Martina: Und da kamen dann diese JSON-Web-Tokens ins Spiel. Und in diesen JSON-Web-Tokens,
Martina: das ist eigentlich nichts anderes wie ein sogenannter Header,
Martina: ein Payload und eben die Signatur.
Martina: Und die Signatur hat halt diesen Vorteil, dass halt der Token natürlich signiert ist.
Martina: Und wie wir vielleicht schon wissen, wenn wir etwas signieren,
Martina: dann können wir auf die Authentizität überprüfen,
Martina: aber auch überprüfen, dass auch niemand den Token irgendwie boshaft verändert
Martina: hat, also diesen Payload hauptsächlich irgendwie verändert hat.
Martina: Weil in diesem Payload stehen ja halt jetzt meine Berechtigungen drin.
Martina: Man kann sich ja schon vorstellen, wenn ich jetzt eine Berechtigung,
Martina: ich sag mal einfach nur lesen habe und ich würde jetzt bösartig eine Admin-Berechtigung reinschreiben,
Martina: dann habe ich wenigstens den Vorteil, dass halt der Token nicht mehr verifiziert
Martina: werden kann, weil halt die Integrität, also die Signaturprüfung dann natürlich gebrochen ist.
Ali: Zum Thema der Integrität des Tokens hast du auch ein eigenes Kapitel,
Ali: was ich sehr zukunftsorientiert fand, über die Quantencomputer-Angriffsvektoren
Ali: und die Post-Quanten-Kryptographie, die in den Web-Tokens, in den
Ali: JWTs mittlerweile drinsteckt. Das war so etwas, wo ich gedacht habe,
Ali: ganz oft, wenn Leute sagen, welche tollen Anwendungsbereiche Quantencomputer
Ali: haben, dann sehe ich immer nur den, ja, wir können Security umgehen und dann
Ali: bin ich immer froh, wenn aus der Security-Kryptographie,
Ali: Branche heraus schon kommt übrigens und wir haben hier Post-Quantum-Cryptography-Sicherheit
Ali: implementiert, wo es auch nicht hilft, wenn man das Token tatsächlich mit dem
Ali: Quantencomputer in Anführungszeichen aufbrechen kann.
Martina: Ja, es gibt doch schon zig Post-Quantum-Algorithmen, die sowohl für Verschlüsselung,
Martina: Entschlüsselung als auch für die Signaturüberprüfung eben zugezogen werden können.
Martina: Ich arbeite auch sehr viel im Banken- oder Finanzsektor und da ist es eigentlich
Martina: sogar schon gang und gäbe,
Martina: dass da gerade Post-Quantum-Algorithmen eingebaut werden, weil die haben halt
Martina: einfach schon auch die Pflicht und müssen das letztendlich umsetzen.
Martina: Ein kleiner, das habe ich auch kurz in meinem Buch erwähnt, aber nur als Info
Martina: ist, es gibt sogar noch etwas, das nennt sich FAPI, Financial API und das setzt
Martina: sogar OAuth noch eins oben drauf.
Martina: Da steht beispielsweise drin, müssen wir jetzt gar nicht groß ausführen,
Martina: aber da steht beispielsweise nämlich drin, dass wir bitte so etwas wie Post-Quantum-Kryptographie
Martina: schon implementieren in diesen Access-Tokens.
Martina: Eben, dass halt quasi die Hochsicherheitsstufe ausgerufen ist,
Martina: die Requirements dafür.
Martina: Und die müssen dann natürlich gerade im Medizin- und Finanzsektor dann natürlich auch umgesetzt werden.
Ali: Und da ist dann das ewige Waffenrennen zwischen, wie sicher kann ich es machen,
Ali: wie performativ bleibt das System zeitgleich und
Ali: welche Risiken kann ich eingehen, weil wir hatten ja schon mal angeschnitten,
Ali: ich kann theoretisch extrem sichere Systeme bauen, die extrem nutzerunfreundlich
Ali: sind und da dann die Abwägungen zu schaffen zu, es muss immer noch schnell gehen, es muss
Ali: sicher genug sein, es muss zukunftssicher genug sein, das ist ja wirklich etwas,
Ali: da gibt es keine richtige Entscheidung, sondern das sind halt sehr komplizierte
Ali: Pfade, die da zusammenlaufen.
Martina: Ja, absolut. Das ist ja auch schon das heutige Problem alleine,
Martina: wenn ich Passwörter verschlüsseln möchte, also hashen möchte.
Martina: Ich kann natürlich mein scrypt oder Argon2-Hash-Funktion kann ich ja konfigurieren,
Martina: wie, um es mal sehr salopp zu sagen, wie langsam sie sein sollen.
Martina: Denn gerade mal so Bruteforce-Attacken oder wenn ich dann mal so Datenbanken
Martina: geklaut habe, wo ganz viele Hash-Werte drinstehen, dann will ich ja ganz,
Martina: ganz viele Versuche schaffen, das zu hashen,
Martina: innerhalb von wenigen Sekunden und wenn ich einmal diese Hash-Ausführung aber
Martina: jetzt irgendwie fünf Sekunden lang mache…,
Martina: Und ich brauche vielleicht eine Million mal, um ein einziges Passwort zu knacken,
Martina: dann ist ja eine Million mal fünf, ist ja schon eine ganz schön lange Zeitdauer.
Martina: Aber deshalb könnte man natürlich sagen, ja, wieso dann nur fünf Sekunden?
Martina: Dann mach doch die Hash-Funktion, konfiguriere doch die Hash-Funktion so,
Martina: dass sie 20 Sekunden braucht.
Martina: Ja, das wäre natürlich viel, viel, viel sicherer.
Martina: Aber wenn ich als Nutzerin, ich persönlich mich irgendwo einlogge,
Martina: dann muss ja mein Passwort ebenfalls gehasht werden, um zu vergleichen,
Martina: ob derselbe Hashwert auch in der Datenbank steht.
Martina: Und ich kriege schon die Krise, wenn ich auf eine Webseite gehe und sie braucht,
Martina: zwei Sekunden zum Laden.
Ali: Oh, du lebst nicht in Deutschland?
Martina: Ja, da hast du absolut recht. Das ist sehr schade manchmal.
Ali: Also zwei Sekunden zum Laden, das rechne ich hier immer noch zu
Ali: „So ist das Internet hier halt" ein, aber ich verstehe komplett,
Ali: was du meinst, vor allem bei den 20 Sekunden.
Ali: Als moderner Mensch hat man einen Passwortmanager und tippt das Passwort nicht
Ali: mehr von Hand ein, aber wenn es dann doch eins ist, das man mal von Hand eintippen
Ali: muss und man muss 20 Sekunden bei jedem Typo, den man gemacht hat,
Ali: warten, das ist natürlich auch einfach unpraktisch.
Martina: Ja, da gibt es natürlich was, was helfen kann und das sind Passkeys.
Martina: Ja, also Passkeys haben tatsächlich schon statistisch die Login-Dauer auch verringert.
Martina: Also da gibt es ganz coole Statistiken von der Fido-Allianz dazu.
Martina: Ja, großer, großer Fan.
Ali: Ja, jetzt hattest du verschiedene Gremien erwähnt und auch bei OpenID Connect,
Ali: es stehen ja Organisationen hinter diesen de facto Standards,
Ali: hinter diesen Entwicklungen.
Ali: Wie ist das, welche Interessen haben die, entwickeln die das für das Greater
Ali: Good der Menschheit, entwickeln die das, um selbst sicher zu sein,
Ali: weil wir hatten es ja auch schon mal angeschnitten,
Ali: irgendwann kommst du an den Punkt mit, es gibt verschiedene konkurrierende Systeme
Ali: und Interoperabilität ist ja total wichtig, damit so ein System sich durchsetzen kann.
Ali: Also wer entwickelt an diesen Standards und wer unterstützt,
Ali: dass diese Entwicklung stattfinden kann, denn das ist ja jetzt nichts,
Ali: was ausschließlich durch Goodwill und ein paar Universitäten entsteht.
Martina: Ja, in den meisten Fällen ist es der IETF, das ist der Internet Engineering
Martina: Task Force und die erstellen sogenannte RFCs.
Martina: Und da ist letztendlich, die RFCs sind quasi die Spezifikation.
Martina: Und da finden sich aber meistens dann Menschen aus der Industrie zusammen.
Martina: Das kann mal jemand von Microsoft sein oder mal jemand von Ping Identity ist
Martina: hauptsächlich auch oftmals dabei, aber auch von Google natürlich, von Apple.
Martina: Also schon die Big Tech-Vendors natürlich, die ihre eigenen Interessen natürlich
Martina: auch ein bisschen umgesetzt haben möchten.
Martina: Sei es, dass es doch noch irgendwo in den Secure Enclave von MacBooks vielleicht
Martina: eine Backdoor gibt oder so und die muss auch irgendwie abgebildet sein in diesem RFC,
Martina: weil wenn sich dann Apple plötzlich an den RFC beteiligen muss und den implementieren
Martina: muss, dann kann das natürlich auch für Apple vielleicht Millionen kosten oder Milliarden sogar.
Martina: Und deshalb steigen die natürlich sehr gerne damit ein, also nicht nur Apple,
Martina: auch Google und Microsoft und so weiter, senden quasi Vertreter aus und die
Martina: arbeiten dann in sogenannten Taskforce-Gruppen oder Working Groups dann an dem entsprechenden RFC.
Martina: Das ist immer ein bisschen schwierig natürlich, weil es gibt meistens auch natürlich
Martina: jemanden dabei, der wirklich nur Goodwill ist, der wirklich einfach nur die
Martina: Menschheit ein bisschen sicherer machen möchte.
Martina: In der Webwelt. Und dann kommt man natürlich da ein bisschen oder stößt man
Martina: natürlich ein bisschen auf Widerstand, weil dann natürlich Google,
Martina: Microsoft und wie sie alle heißen, da vielleicht ein bisschen dagegen wirken.
Martina: Eins der zum Beispiel größten oder der größten Probleme war tatsächlich damals
Martina: der Umstieg von OAuth 1 auf OAuth 2.0.
Martina: Ich hatte ja schon angedeutet, dass OAuth 1 dieses coole Sender Constraining eigentlich
Martina: mit drin hat, dass man halt den Access Token nicht einfach so senden kann,
Martina: sondern der muss immer irgendwie an den Client gebunden sein, kryptografisch.
Martina: Und jetzt kam halt tatsächlich, nachdem Twitter aufkam, kam natürlich da auch
Martina: Apple und Microsoft dazu und
Martina: haben gesagt, jetzt wollen wir aber dieses Internet weiter voranbringen.
Martina: Wir wollen Webseiten weiter voranbringen.
Martina: Und in so einem Browser kann ich nicht so richtig standaktuell Sender-Constraining
Martina: umsetzen, weil Sender-Constraining würde ja bedeuten, dass ich vielleicht auch so eine Art,
Martina: Private Key dann im Browser habe, mit dem ich dann den Token vielleicht signiere,
Martina: und ein Private Key einfach so im Browser zu haben.
Martina: Also mittlerweile ist das möglich. Es gibt so eine Web-Crypto-API.
Martina: Mittlerweile geht es, aber damals hat man halt keine Möglichkeit gehabt für sowas.
Martina: Und dann hat halt tatsächlich Apple und Google gesagt, wir entfernen das Ganze.
Martina: Wir entfernen das Ganze, Sender-Constraining einfach und machen das zu Bearer-Tokens.
Martina: Haben also ihren Willen durchgebracht, nur damit sie halt mehr in dieser Webwelt
Martina: flexibler ihre Interessen durchdrücken können.
Martina: Und das hat halt sogar dazu geführt, dass der ursprüngliche Gründer von OAuth,
Martina: der hat eine riesige Hasstirade tatsächlich in einem Artikel verfasst.
Martina: Das nennt sich OAuth 2, Road to Hell.
Martina: Wie schlimm jetzt das ist, dass die Vendors tatsächlich da in Spezifikationen
Martina: eingreifen, dass jetzt dieses ganze Kryptografische wegfällt und damit,
Martina: landen wir halt dabei, dass wir Autorisierung, Authentifizierung weitaus unsicherer machen.
Martina: Jetzt kann man natürlich nochmal den Bogen spannen auf die OWASP Top Ten.
Martina: Das ist so eine coole Liste, wo quasi die gängigsten Angriffsszenarien aufgelistet
Martina: sind, was so die größten Schwachstellen sind heutzutage in Web-Anwendungen.
Martina: Und die kommt alle vier Jahre raus.
Martina: Und seit 2021 ist Platz, also auch davor schon, aber ist Platz 1 Broken Access Control.
Martina: Also quasi genau das ein bisschen, was er vorausgesagt hat, dass Broken Access
Martina: Control, dass halt der Token gestohlen wurde, dass einfach,
Martina: Token irgendwo hingesendet wurde, die werden nicht richtig überprüft,
Martina: weil man halt diese ganze Kryptografie letztendlich entfernt hat.
Martina: Aber um wieder den ganzen Bogen zurückzuspannen, also ja, es gibt dann immer
Martina: diese Taskforce und die kümmert sich halt um die Spezifikationen,
Martina: aber klar mischen da die großen Big Tech Companies halt mit,
Martina: um auch ihre eigenen Interessen durchzudrücken.
Ali: Das ist bei solchen Standards ja durchaus immer eine Schwierigkeit,
Ali: die man auch in der Open-Source-Community viel sieht von Leuten,
Ali: die etwas aus Idealismus anfangen oder weil sie eine Idee haben und dann kommen
Ali: die Leute, die damit ein Produkt machen wollen.
Ali: Und dann entsteht natürlich auch dieses, wenn Apple es schafft,
Ali: vor Google einen entsprechenden Service anzubieten, der viel reibungsloser ist,
Ali: ist das für sie ein Marktvorteil.
Ali: Und dieses, man arbeitet schon zusammen, aber man hat ja nicht unbedingt das
Ali: gleiche Interesse, nämlich wir machen das Internet sicher, sondern man hat immer
Ali: noch im Hinterkopf das Interesse, die Leute sollen meine und nicht deine Produkte kaufen.
Ali: Das ist hochkompliziert und ich finde es immer spannend, wenn man sieht,
Ali: wer auf solchen entsprechenden
Ali: Konferenzen, Panels und so weiter und so fort als Sponsoren auftaucht und man
Ali: sieht, da ist dann teilweise komplett Big Tech vertreten und dann schaffen sie
Ali: es irgendwie hier an einem Strang zu ziehen und dann fehlt auffällig einer wie
Ali: zum Beispiel Microsoft oder Amazon und man fragt sich, warum?
Ali: Also profitieren die jetzt nur von dem neuen Standard, der hier ausgearbeitet
Ali: wird und warum unterstützen sie ihn nicht oder haben sie selbst was,
Ali: das sie da gerade kochen? Also da gibt es, ich glaube, man könnte einen kompletten
Ali: Gossip-Podcast machen, nur
Ali: um szeneninterne Streitigkeiten bei der Weiterentwicklung von Standards.
Martina: Ja, absolut. Es gibt ja auch, jetzt fange ich später damit an,
Martina: aber es gibt ja auch einen relativ langen, ausführlichen Blogartikel,
Martina: wie Apple es fast geschafft hätte, Passkeys zu töten,
Martina: eben weil sie sich nicht so richtig an den Standard, der geschrieben wurde,
Martina: gehalten haben und ihr eigenes Süppchen gekocht haben.
Martina: Was halt dann in dem Moment bedeutet, dass wenn ich ein Passkey halt anlege in
Martina: Apple, in meiner iCloud Keychain oder auf dem Gerät, dass ich den halt definitiv
Martina: nicht synchronisiert bekomme mit anderen, mit Google oder wie auch immer. Ja.
Martina: Und glücklicherweise hat sich das mittlerweile wieder ein bisschen geregelt,
Martina: aber sie hätten es halt beinahe leider geschafft, halt Passkeys wieder aussterben
Martina: zu lassen, bevor es richtig im Kommen war letztendlich.
Ali: Eine Sache, mit der ich dann das Ganze auch abbinden würde, du hattest RFCs
Ali: gerade erwähnt und in deinem Buch, in deinem Schlusswort, in deiner Danksagung,
Ali: da schreibst du auch, es gibt all diese RFCs, also die
Ali: Anleitungen, wie das Ganze technisch gedacht ist und wie das Ganze umzusetzen ist,
Ali: aber aus denen ergibt sich jetzt noch nicht direkt ein Lehrbuch,
Ali: mit dem man versteht, was das Ganze ist.
Ali: Und das Buch, das du geschrieben hast über Authentifizierung und Autorisierung
Ali: im Rheinwerk Verlag, das befasst sich ja damit, genau das zu sein.
Ali: Ein Lehrbuch, ein Nachschlagewerk für etwas, das an sich sehr technische Beschreibungen sind.
Ali: Was hast du selbst bei dem Verfassen dieses Buchs nochmal über die entsprechenden RFCs gelernt?
Martina: Das ist tatsächlich eine sehr gute Frage, denn ich muss auch sagen,
Martina: bevor ich das Buch geschrieben habe, habe ich nicht jeden RFCs von oben nach unten durchgelesen.
Martina: Mittlerweile dann schon, weil ich würde natürlich das Buch schon richtig schreiben.
Martina: Aber das war tatsächlich sehr interessant, gerade OAuth 2 hat halt irgendwie 15
Martina: verschiedene RFCs letztendlich.
Martina: Was ich glaube ich daraus gezogen habe, ist, dass es, wie du auch gesagt hast,
Martina: es steht halt irgendwie eine Spezifikation drin und es gibt vor allen Dingen
Martina: im deutschsprachigen Raum aber auch nichts so in die Richtung,
Martina: jetzt erkläre ich es euch mal, wie das funktioniert.
Martina: Und viele Entwickler und Entwicklerinnen wollen halt einfach einen Authorization-Server
Martina: anbinden und wollen einfach nur so einen Access-Token haben.
Martina: Und das leider so ein heikles Thema ist und es aber leider keine vernünftigen
Martina: Ressourcen dazu gibt, wie man es richtig macht, außer die RFCs.
Martina: Neigt man halt dazu, wild rumzuklicken und Trial and Error und halt zu gucken,
Martina: okay, jetzt habe ich endlich den Access-Token.
Martina: Sehr gut. Ich habe irgendeiner dieser Flows ausgewählt, auch wenn es vielleicht
Martina: ein unsicherer war, aber mir jetzt gerade egal, weil ich habe zwei Tage lang
Martina: damit rumgemacht, so ein Access-Token zu bekommen und damit übertreibe ich tatsächlich nicht.
Martina: Und dann ist natürlich auch das Problem, dass alle Identity Provider,
Martina: die auch ein bisschen unterschiedlich implementieren, also kein Identity Provider
Martina: implementiert die RFCs zu 100 Prozent.
Martina: Und sprich, selbst wenn man jetzt die RFCs liest, ist nicht sichergestellt,
Martina: dass das jetzt eins zu eins das ist, was man jetzt in Keycloak,
Martina: in Entra ID, wie auch immer vorfindet,
Martina: weil die dann doch wieder so ein bisschen gesagt haben, wir wissen es aber besser
Martina: und wir machen es vielleicht ein bisschen anders.
Martina: Es gibt zum Beispiel nicht den Token Exchange Flow in Entra ID, der heißt OBO Flow on behalf of User.
Martina: Und der ist ein eigenkreierter Flow, weil sie halt gesagt haben,
Martina: der RFC ist noch nicht so weit und deshalb machen wir jetzt schon mal wieder,
Martina: unser eigenes Süppchen.
Martina: Und was ich halt mit dem Buch versucht habe, ist auch die Unterschiede aufzuweisen.
Martina: Also gerade in dem Implementierungskapitel habe ich halt auch riesige Tabellen
Martina: gemacht, um die gängigsten Identity Provider, wie heißt der Flow da,
Martina: was muss man dafür konfigurieren, damit man diesen Flow einsetzen kann.
Martina: Und das Wichtigste, wenn man sich aber ein bisschen mit den RFCs beschäftigen
Martina: möchte, ist man, glaube ich, gut damit geraten,
Martina: nur noch den OAuth 2.1 RFC durchzulesen und nach alles, was dort beschrieben ist an Requirements and
Martina: Should Have, Must Have, dass man sich eher daran hält, weil OAuth 2.1 ist keine
Martina: wirkliche Weiterentwicklung, sondern mehr so die Zusammenfassung von,
Martina: allem, was man aus OAuth 2.0 gelernt hat.
Ali: Alles klar. Ich glaube, wir haben für das Buch, das ja doch sehr,
Ali: sehr technisch ist, ein Nachschlagewerk, ich glaube, wir haben ein sehr gutes
Ali: Gespräch darüber zusammenbekommen, warum es sich lohnt, reinzuschauen,
Ali: warum der eine oder andere da vielleicht noch
Ali: etwas ausgiebig lernt über die RFCs, die man sonst nur als Handlungsanweisung
Ali: und nicht als Lehrbuch benutzen kann. Danke für deine Zeit.
Martina: Ja, sehr gerne. Hat mir super viel Spaß gemacht.