Deep Dive 207 – Passkeys mit Martina Kraus

Wie hat dir die Folge gefallen?
Gut 👍
Schlecht 👎
(Keine Anmeldung erforderlich)

Lösen Passkeys bald alle unsere Passwörter ab? Martina Kraus ist Application Security Engineer und Expertin für Web-Anwendungssicherheit und spricht mit uns über die sicherere Technologie.

Martina erklärt, wie Passwörter funktionieren und welche Risiken sie bergen. Statt ein „Shared Secret“ zwischen Nutzer:in und Dienstleister:in zu nutzen, arbeiten Passkeys mit Public-Private-Key-Paaren, die vollständig unter der Kontrolle der Nutzer:innen bleiben und damit wesentlich phishing-resistenter sind.

Martina führt Schritt für Schritt durch die technischen Grundlagen: symmetrische vs. asymmetrische Verschlüsselung, digitale Signaturen und die Funktionsweise von Passkeys in der Praxis. Sie zeigt, wie jeder Passkey für eine einzelne Website („Origin“) erstellt wird, wodurch Wiederverwendung ausgeschlossen ist und ein deutlich höheres Sicherheitsniveau entsteht. Außerdem erläutert sie die Unterschiede zwischen hardwarebasierten Passkeys und synchronisierten Passkeys, sowie die Vor- und Nachteile für die Nutzungserfahrung.

Und wie immer sprechen wir in der programmier.bar auch über die Implementierung. Martina empfiehlt, auf Identity Provider wie Keycloak oder Auth0 zu setzen, um Passkeys produktionsreif zu integrieren, und erklärt die Rolle von WebAuthn und Client-to-Authenticator-Protokollen (CTAP2).

Kritisch hinterfragt werden auch Edge Cases und Nutzungsfreundlichkeit: Account Recovery, verlorene Geräte und die Herausforderungen bei hardwaregebundenen Passkeys. Martina erklärt, wie mehrere Passkeys für wichtige Accounts als Backup hinterlegt werden können und welche Best Practices empfohlen werden, um den Ausfall eines Geräts abzufedern.

Abschließend wagt Martina einen Ausblick auf die Zukunft der Authentifizierung: Obwohl Passwörter noch lange nicht verschwinden werden, ist die Entwicklung hin zu passwortlosen Systemen absehbar. Passkeys bieten dabei nicht nur höhere Sicherheit, sondern auch Komfort, sofern die Nutzer:innen die neuen Mechanismen verstehen und akzeptieren.

Schreibt uns!
Schickt uns eure Themenwünsche und euer Feedback: podcast@programmier.bar

Folgt uns!
Bleibt auf dem Laufenden über zukünftige Folgen und virtuelle Meetups und beteiligt euch an Community-Diskussionen.

Bluesky
Instagram
LinkedIn
Meetup
YouTube

Musik: Hanimo

Transcript

SPEAKER_01 0:08

Hallo und herzlich willkommen zu einer neuen Deep Dive-Folge hier in der Programmierbar. Für euch, wie immer hier vor dem Mikrofon, einmal der Jan-Gregor im Getriebel und mit mir live zugeschaltet aus der Saline in Bad Nauheim ist Dave Acker, David Kuschitzki, moin. Und immer wenn Dave im Podcast ist, wissen wir, es geht um was, Dave? Security, Security Dave. So ist es nicht. Ich bin hyped, ich bin hyped. Wir wollen nämlich heute über ein Security-Thema sprechen. Wir wollen nämlich heute über Passkeys sprechen und wie sie sich anschicken, eure Passwörter abzulösen, sozusagen. Oder andersrum formuliert, euch von Passwörtern zu er lösen, je nachdem, worum man das vielleicht sehen mag, ja. Aber weil auch Dave's Security-Wissen seine Grenzen hat. Man mag es kaum glauben, aber auch Dave's Security-Wissen hat seine Grenzen, haben wir uns jemand eingeladen, deren Security-Wissen quasi keine Grenzen kennt. Um mal die Nachte gleich ganz oben hinzulegen. Wir haben uns eingeladen, Martina Kraus. Martina, schön, dass du da bist. Hallo.

SPEAKER_02 1:10

Ja, hallo, ihr beiden. Ich freue mich mega. Ich hoffe, ich kann die Erwartung erfüllen, aber da schauen wir mal.

SPEAKER_01 1:15

Hast du bereits jetzt schon.

SPEAKER_02 1:18

Danke, danke.

SPEAKER_01 1:19

Die richtig harten Programmierbar-Fans werden dich erkannt haben, erkennen von der Programmierkon, wo du auch schon zu Gast warst bei uns im letzten Jahr und auch da schon über Security gesprochen hast. Und ich habe auch gesehen, du hast, also du hast auch auf der Enter-JS über Security gesprochen. Und das triggert erstmal so meine erste Frage, die noch gar nichts mit dem Thema zu tun hat, aber die ich immer stelle, wenn wir Gäste da haben, die häufig auf Konferenzen unterwegs sind. Nämlich, wie suchst du dir die Events aus, auf denen du so sprichst? Wo, wie machst du so aus, was so deine Zeit wert ist am Ende des Tages?

SPEAKER_02 1:54

Also zum einen hängt natürlich auch schon der Ort ein bisschen in der Auswahl zusammen, also wie lange ich dahin brauche letztendlich. Aber ich glaube, ein Hauptfaktor für mich ist es, ob das eine Community-Konferenz ist. Also wie hoch die Ticketpreise sind und ob das jetzt eine riesen Enterprise-Gesponserte Konferenz ist, die leider vielleicht auch die Speaker nur manchmal, um es mal böse zu formulieren, ausnimmt und dann einfach auch die Ticketpreise hochzieht und nichts der Community oder den Speakern dafür zurückgibt. Oder halt natürlich einfach nur Community First und man macht eine angenehme Atmosphäre. Es ist, jeder fühlt sich warm und willkommen. Und wenn ich das irgendwie spüre oder auch das Gefühl habe, oder es gibt auch überhaupt einen Call of Contact, das ist auch etwas, was es in manchen Konferenzen überhaupt gar nicht gibt, um ehrlich zu sein. Krass. Und da dann auch sind eigentlich so meine Hauptfaktoren, wie warm und willkommen man sich da eigentlich fühlt.

SPEAKER_01 2:50

Also um es kurz zu sagen, du warst genau richtig auf der Programmierkonten.

SPEAKER_02 2:56

Also jetzt ohne zu. Ja, genau, ohne jetzt gleich natürlich Euch Honig um den Mund zu schmieren. Aber es hat mir schon wirklich sehr gut gefallen auf eurer Konferenz. Also es war schon, die Location war so cool. Ich war zwar oben, da war das so um den Eck quasi, aber das war, also mir hat es gefallen, also wirklich. Also ich hatte auch, ich habe das damals auch zu eurem Mitarbeiter gesagt, ich weiß leider seinen Namen nicht mehr, weil der sich um den Tech-Support gekümmert hat, als er mich verkabelt hat und so weiter. Ich habe noch nie so eine gute Einweisung bekommen. Also es wurde sich so arg um mich gekümmert. Ich fand das so super cool. Und das sieht man wirklich selten auf Konferenzen. Da ist es manchmal auch einfach so, hier hast du dein Mikro, steckst dir mal selbst an. Irgendwie. Und also jetzt, wie gesagt, es war eine sehr, sehr coole Konferenz. Ich hoffe, dass ihr das auf jeden Fall nochmal macht.

SPEAKER_01 3:48

Und wenn du nicht gerade den ganzen Tag auf irgendwelchen Konferenzen abhängst, was machst du sonst den ganzen Tag?

SPEAKER_02 3:54

Ich arbeite als ein sogenannter Application Security Engineer und bin da eigentlich relativ hands-on bei den Entwicklern und Entwicklerinnen dabei, ihre Web-Anwendungen eigentlich sicherer zu gestalten. Sei es, wir schauen uns mal NIS an oder NIS2, die OVAS Application Security Ferration Standards, also gewisse Standards, um halt die Applikationen nach diesen Standards sicherer zu gestalten. Das kann natürlich sein, wir machen einfach nur ein Audit, wir gehen mal drüber, ich scanne, ich Penteste oder natürlich auch, ich helfe denen dann auch wirklich über Monate hinweg, die gewissen Standards zu erfüllen. Da hat sich so ein bisschen so ein Steckenpferd bei mir rauskristallisiert, und das ist halt Authentifizierungen, Autorisierungen in Web-Anwendungen. Da würde ich mittlerweile behaupten, ist so meine Hauptexpertise, um ein bisschen Eigenwerbung zu machen. Da kommt auch im April ein Buch raus von mir.

SPEAKER_00 4:49

Oh, spannend.

SPEAKER_02 4:50

Ich habe ein Buch tatsächlich geschrieben über genau dieses Thema. In Deutsch natürlich, weil es auch manchmal ein bisschen einfacher ist, das ganze komplexe Thema in Deutsch zu lesen. Genau. Und dahin gehen natürlich auch hier und da ein bisschen Consultants. Also einfach nur mal, man kann mich dann für einen Tag lang buchen. Ich halte Workshops und so in den Themengebieten. Ja.

SPEAKER_01 5:11

Das ist echt auch ein super spannendes Thema. Vielleicht müssen wir da mal einen separaten Podcast machen, wie das so ist, so ein Buch in Tech zu schreiben, wo es ja, also zum einen treffen da, glaube ich, so zwei unterschiedliche Welten aufeinander, so eine sehr schnelllebige Tech-Welt und so eine Verlagswelt, die vielleicht nicht ganz dieses Tempo gewohnt ist, vielleicht. Und aber auch ist es ja, glaube ich, so didaktisch eine sehr andere Art, irgendwie Wissen zu vermitteln, als das, was wir sonst so in Blogs oder auf Konferenzen oder YouTube oder in einem Podcast oder sowas machen. Super spannend, vielleicht kommen wir da am Ende drauf. Oder wir machen die nächste Folge. Wo ist sie?

SPEAKER_02 5:45

Und leider kleiner Funfact, ich musste alles in Word schreiben. Ich konnte nicht Lartisch oder sowas verwenden. Ich habe eine Word-Vorlage bekommen und da musste ich alles reinschreiben. Aber es ging, es war schon ganz gut. Also es war ehrlicherweise weniger Hustle oder Pain, um es mal so zu sagen, als gedacht am Anfang.

SPEAKER_00 6:02

Aber krass, war das direkt eine Vorgabe sogar vom Verlag? Du musst es daran schreiben. Ach krass.

SPEAKER_02 6:07

Ich muss ehrlich sagen, habe ein sehr gutes Template bekommen. Und es war einfach, das Template zu verwenden, muss man schon sagen. Es hat Spaß. Es hat sogar Spaß gemacht, irgendwie.

SPEAKER_01 6:16

Schön. Okay. Wir wollen heute sprechen über Passkeys. Und vielleicht für alle da draußen, die noch nicht wissen, was das ist. Martina, wie würdest du das vielleicht so deinen Eltern erklären, was das ist und warum sie das benutzen sollten?

SPEAKER_02 6:35

Prinzipiell würde ich immer so ein bisschen den Vergleich mit Passwörtern erstmal ziehen, also eher erklären, wie Passwörter funktionieren, um dann ein bisschen den Vorteil oder darüber dann Passkeys zu erklären. Bei Passwörtern würde ich halt einfach anfangen, ja, wir wählen halt irgendeine Zeichenkette aus, irgendein Wort aus. Und mit diesem Wort kann ich mich dann einloggen. Und dieses Wort ist dann halt natürlich auch bei dem Dienstleister hinterlegt. Das liegt in irgendeiner Datenbank. Ich würde ein bisschen, ich würde dann erstmal natürlich auslassen, dass das vielleicht gehasht sein muss, dass man das nicht einfach in Klartext speichert. Darauf können wir ja dann später nochmal zu sprechen kommen. Aber das ist eine Art von Shared Secret und das ist das große Problem leider daran, dass ich halt dieses Wort mir irgendwie sicher abspeichern muss, aber ich muss auch sicherstellen, dass der Dienstleister, wo ich mich einloggen möchte, Google oder Microsoft, ebenfalls dieses Wort sicher verwahrt. Wie es das macht, da können wir ja später, wie gesagt, nochmal drauf sprechen, aber damit würde ich erstmal starten. Und dass man das halt shared secret nennt und dass das halt auf zwei Ebenen halt gefährlich ist. Weil der Nutzer, Nutzerin muss halt irgendwie dieses Wort, wie gesagt, Passwortmanager wäre natürlich das Perfekte, aber die meisten schreiben es sich auch vielleicht auf den Zettel. Meine 95-jährige Oma hat sich das immer auf den Zettel geschrieben. Da kann ich es vielleicht auch ein bisschen nachvollziehen.

SPEAKER_00 7:56

Klassiker, ja.

SPEAKER_02 7:58

Ja, ja. Aber wie gesagt, das ist auch ein bisschen außer meiner Kontrolle, weil halt leider auch der Dienstleister das auf den Zettel schreiben muss. Wenn wir jetzt zu Parskeis kommen, haben wir halt den riesen, riesen Vorteil, dass wir Selbstkontrolle haben über dieses Secret in dem Sinne. Das Coole ist nämlich, dass wir mit etwas arbeiten, was sich Signatur nennt. Und natürlich ist jetzt Signatur oder Public Key Cryptography ein bisschen schwerer zu erklären, wäre ein bisschen komplizierter, meiner Großmutter zu erklären. Aber ich habe einfach etwas, mit dem ich zu 100% beweisen kann, dass ich ich bin und das ist kryptographic abgesichert, ganz ohne dass ich bei dem Dienstleister my password or irgendein Chat-Secret hinterlegen muss. Und alles, was ich da for diesem Dienstleister gaben muss, ist eben ein öffentlicher Schlüssel. Ein öffentlichen Schlüssel. Also ich erkläre das natürlich jetzt sehr oberflächlich, we couldn't jack the rich and all erwähnen. Und nur mit diesem öffentlichen Stück auf dem Server kann jetzt überprüft werden, dass ich tatsächlich. And dahinter steckt natürlich super komplexe cryptographische Verfahren. But that makes it so much sicherer, but I this shared secret, this word not the hand gave. When the Datenbanken from the Dienstleister cloud, then there is not this one. And with these, but this part not to verify that a challenge or a text from me and not for manipulated. And I have the 100% control over my private, the private key, what I mean.

SPEAKER_01 10:18

And I think this is so the point where the one or other who in the softwareentwickling game is als Quereinsteiger inhaltlich aussteigt. So auf einer gewissen Ebene versteht man das so, wie das so irgendwie mathematisch funktioniert. Und es gibt so einen privaten Teil, es gibt einen öffentlichen Teil, und zusammen können sie sich quasi gegenseitig legitimieren. Aber ohne jetzt in die Krypto-Vorlesungen abzusteigen, was ist denn so die kurze Erklärung, warum diese Schlüsselpaare funktionieren? Weil da liegt ja, also darauf baut ja alles andere, über was wir jetzt sprechen, so auf.

SPEAKER_02 10:54

Genau, also es gibt, da muss man vielleicht kurz doch ein bisschen eintauchen, es gibt ja symmetrische und asymmetrische Verfahren. Bei symmetrischen Verfahren hat man bei Verschlüsselungen zum Beispiel. Immer wenn ich mit jemandem sprechen möchte über Signal oder auch Telegram oder sowas, dann ist das meist eine End-zu-End-Verschlüsselung. Sprich, ich habe einen Schlüssel und du hast den aller aller gleichen Schlüssel. Ich verschlüssel das und du kannst es wieder entschlüsseln. Jetzt ist das halt aber ziemlich kompliziert und schwierig, weil wir ja ein und denselben Schlüssel haben. Das heißt, bevor du mit mir reden kannst, muss ich dir diesen Schlüssel erstmal geben. Und das gebe ich dir jetzt unverschlüsselt, da kann ja jeder kommen und den doch irgendwie klauen. This is so ein bisschen risikobehaftet. Was es auch gibt, ist das asymmetrische Verfahren. And we said, not to tie in the cryptographie, but it is einfach mathematical problems. Man nimmt da immer gerne logarithmen, modulo, and elliptische Kurven anders. What two schlüssel miteinander so mathematisch verlinkt, dass wir einen privaten Schlüssel have and around. And then leider so, or it is so with the öffentlichen Schlüssel can I versus. Nur ich als wirklich Eigentümerin von meinem privaten Schlüssel kann diese Nachricht entschlüsseln und lesen. Jetzt nutzen wir bei Parskis aber ein anderes cooles Verfahren und das nennt sich die digitale Signatur. Da haben wir auch genau so einen privaten und öffentlichen Schlüssel. Und da ist der große Vorteil, dass ich nichts verschlüssel, sondern ich erstell eine Signatur. Das heißt, ich hash die Nachricht oder irgendeine Challenge, die ich dir senden möchte. And wir möchten ja mit der digitalen Signatur herausfinden, ob zum einen diese Nachricht dann wirklich, wirklich von mir kam, so wirklich, wirklich von mir kam, und ob sie manipuliert wurde. Und das erreichen wir mit dieser digitalen Signatur. Das heißt, ich erstelle eine Signatur mit dem privaten Schlüssel und gebe dir die Nachricht mit meinem öffentlichen Schlüssel. And das coole ist eben jetzt daran, dadurch, dass die beiden mathematisch verlinkt sind, du kannst nur mit diesem öffentlichen Schlüssel, der wirklich zu mir gehört, diese Signatur verifizieren. Kein anderer öffentlicher Schlüssel oder irgendein anderer Schlüssel der Welt könnte diese Nachricht jetzt verifizieren. Damit habe ich schon automatisch bewiesen, dass die Nachricht von mir kommen muss. Ich habe mich authentifiziert. And da denkt man schon daran, ah, so muss das also irgendwie jetzt zusammenhängen. Der Mechanismus, wenn ich mich identifizieren möchte mit Parsekeys. Ich kann ganz einfach mit diesem mathematischen Linking von diesen beiden Schlüsseln beweisen, ich bin ich bin. Weil nur halt der öffentliche Schlüssel, der dazugehört, diese Signatur verifizieren kann.

SPEAKER_01 14:16

Okay, jetzt, wo wir so das Basic-Verständnis davon haben, lass uns, bevor wir an die Implementierung gehen, noch ein, zwei Facetten von der End-User-Experien vielleicht erklären. Das eine ist, es steht ja immer im Raum, Pastkeys irgendwie deutlich sicherer als Passwörter. Aber am Ende des Tages sind ja Pastkeys genauso nur in Anführungszeichen ein Faktor, wie Passwörter auch nur ein Faktor sind. Also allein durch die Verwendung von Pastkeys führe ich ja keinen zweiten Faktor ein, oder?

SPEAKER_02 14:48

Nein, aber ein zweiter Faktor heißt nicht gleich, dass es Unmengen sicherer ist. Es gibt schon so viele bestätigte Attacken auf Second Factor-Authentifizierung, vor allem wenn sie über SMS erfolgen. Es ist SMS als zweiter Faktor gilt schon längst als eigentlich gebrochen oder auch unsicher. Es ist auf jeden Fall sicherer, als nur ein Faktor zu haben. Aber mit Passkis ist halt die Notwendigkeit eines zweiten Faktors zu haben, braucht man tatsächlich nicht mehr. Also tatsächlich vielleicht auch aufgelöst. Warum gelten Passkeys als so viel sicherer? Vielleicht auch eine Frage zurück an euch. Was nervt euch bei Passwörtern am meisten? Einfach mal so, was fällt euch ein? Was nervt euch an Passwörtern? Fällt euch da direkt irgendwas ein?

SPEAKER_01 15:35

Also das Einzige, was mich nervt, ist, dass ich sie selber vergeben muss oder dass mein Passwortmanager sie vergeben muss und jeder irgendwelche anderen Anforderungen hat, bis hin zu diesen lächerlichen, oh, dieses Passwort ist aber zu lang. Das kannst du hier leider nicht benutzen. So, ja, wo teilweise da die Security noch torpediert wird irgendwie durch die Anwendung.

SPEAKER_00 15:54

Aber ja. Ja, ich würde dir gerne zustimmen. Also Passwortvorgaben, Passwortlänge, dann muss ich irgendwelche Zwei-Faktor-Autorisierungscodes irgendwie aus meiner Mail auch nochmal holen, da bestätigen. Es gibt ja auch Webseiten, da musst du regelmäßig auf dein Passwort erneuern, damit das irgendwie alle drei Monate oder sechs Monate irgendwie eine neue ist. Also insgesamt muss ich sagen, Security ist leider sehr unsexy.

SPEAKER_02 16:15

Ja, also du musst aber schon zugeben, ihr seid ja schon ein bisschen security versiert, dass ihr sowas sagt wie Passwort-Manager. Dann bin ich ja schon ein bisschen glücklich, ehrlicherweise. Neugierigerweise auch eine andere Frage, bei wie viel, wenn ihr schätzen müsst, bei wie vielen Diensten seid ihr eigentlich mittlerweile eingeloggt? Also bei viele Dienste glaubt ihr, haben eine digitale Identität für euch, wo ihr theoretischerweise ein eigenes Passwort vergeben müsst. Was schätzt ihr so? Wie viele das sind?

SPEAKER_01 16:42

Ich weiß es, weil ich neulich erst in mein OnePasswort geguckt habe, weil ich was anderes nachschauen wollte. Da steht ja immer, wie viele Items da irgendwie drin sind. Aber ich kann ja sagen, es sind Hunderte und erschreckend nahe an 1000. Wow, wirklich? Warte, ich hätte jetzt sowas erst so 30, 40 gesagt, das ist jetzt so meine Nummer. No fucking way. Also man glaubt das gar nicht. Aber also ehrlicherweise, ich benutze OnePasswort, denselben Passwortmanager jetzt auch schon seit über zehn Jahren so. Und man löscht da ja ehrlicherweise auch nie was raus. Also selbst wenn du irgendwie einen Account für irgendeine Mini-Pups-Anwendung mal anlegst, du gehst da ja niemals durch und räumst es irgendwie auf. Und ich bin eh so ein Datenmessi, ja. Und dann hordet sich das halt so bei mir.

SPEAKER_02 17:26

Absolut. Und das ist einfach so krass. Ich schaue mir das auch immer wieder an, mein Passwortmanager, und denke mir, das ist ja das ist ja irrsinnig. Und wir benutzen Passwortmanager, aber die meisten benutzen das nicht. Was machen die? Die nehmen überall dasselbe Passwort. Und das ist einfach irrsinnig. Klar, weil man will sich das Passwort nicht merken oder kann sie es nicht merken. Klar, wir haben dann noch sowas wie Single Sign-on, weil wir auch da ein bisschen fatigue sind, nennt man das, für die neue Passworteingabe. Nehmen wir immer vielleicht unser Google-Konto, unser Facebook-Konto, was auch immer, Microsoft-Konto. Aber dann haben wir natürlich das Problem, wenn das Google-Konto einmal komprimiert ist, sind alle anderen Dienste auch weg. Im Prinzip, das ist total hart, wenn man sich das mal vorstellt. Und das ist etwas, was Passkey tatsächlich überhaupt nicht hat. Ein zweites Problem von Passwörtern ist, dass ich beispielsweise, also Entschuldigung, nochmal ein zurückzudern, ich habe gerade einfach nur gesagt, mit Passkeys ist das nicht so. Ich komme gleich dazu, warum das mit Paskeys nicht so ist, aber ich würde erst die ganzen Nachteile von Passwörtern auflisten, damit man so richtig Hass auf Passwörter verspürt, bevor wir dann wirklich zu Passkis übergehen. Nein. Ich meine, was wir bei Passwörtern halt auch haben, Phishing-Attacken. Ich meine, es gibt so viele Firmen, die Milliarden für Awareness-Trainings ausgeben. Und Awareness-Trainings sind wichtig und gut, aber das ist ja, ich muss irgendwie meinen Mitarbeiter und Mitarbeiterinnen klar machen, auf den Link darfst du draufdrücken und auf den nicht. Ich vergleiche das immer mit so einem Haus mit zwei Lichtschaltern anders und sagen, ja, bitte, bohr mal bitte erst mal ein Loch in die Wand. Schau dir mal an, wie die beiden Lichtschalter verkabelt sind, damit du weißt, auf welchen du drauf drücken darfst und auf welchen nicht. Und es ist halt im Internet ähnlich, irrsinnig. Klar, jetzt muss man kein Werkzeug rausholen und ein Loch in die Wand bohren, um herauszufinden, ob ein Link vielleicht zu einer Phishing-Attacke führt oder nicht. Aber es ist trotzdem für jemanden, der sich in der Internetwelt erstmal nicht auskennt, ähnlich komplex. Passkeys sind per Design und Spezifikation, da kommen wir noch phishing-resistent. And das sind alles Vorteile, die eben Passkeys gegenüber Passwörtern haben. Das habe ich auch kurz am Anfang erwähnt, dass wir bei Passwörtern das Password auch zu dem Dienstleister bringen. Das heißt, der muss das irgendwie in seine Datenbank speichern. Natürlich nicht im Klartext, da gibt es dann cryptographische Hashes, am besten irgendwas mit Argon 2, BCrypt gilt ja auch mittlerweile als nicht mehr so sicher. Aber wir müssen halt vertrauen, dass die Webseiten, auf denen wir uns einloggen, die unsere Passwörter sicher verwalten und nicht in Klartext speichern. Und mit einem guten kryptografischen Algorithmus. Und ich weiß nicht, je länger ich in der Security bin, desto paranoider bin ich und desto mehr Kontrolle möchte ich genau haben über die Dinge, die meine Identität ausmachen. Und wenn ich mich irgendwo, ich sage immer, wenn ich mich irgendwo auf KittyCat.org einlogge, dann weiß ich nicht, was die da so mit meinem Passwort machen. Und wenn ich dann noch dieses Passwort wiederverwende, weil ich halt keinen Passwortmanager habe, dann ist das vielleicht auch schnell leider weg. Und das macht halt Passwörter leider ziemlich anfällig.

SPEAKER_00 21:00

Ich würde gerne nochmal kurz auf den Phishing-Punkt näher eingehen. Also ich fasse nochmal ein bisschen zusammen, damit ich das richtig verstanden habe. Also das Problem bei Passwörtern ist, wir haben dieses Shared Secret, so, also wir haben eine Geheimnisübertragung, so und das ist schon mal per se fehleranfällig, so weil ich ja dann dem Hoster vertraue, so, hey, du hast mein Passwort sicher in Kontrolle. Und jetzt mit Parskis haben wir dieses Zusammenspiel von privatem und öffentlichem Schlüssel. Dieser öffentliche Schlüssel, der ist auch nur auf mich gültig und mein Privater dann halt, den habe ich persönlich. So, und jetzt, ich weiß, es ist natürlich jetzt ein sehr hypothetisches Szenario, aber mal angenommen, the schlüssel is irgendwie geleaked and it would irgendwie Zugriff on my computer become. Could an angrier then with this anfan? Or is it not there in this context?

SPEAKER_02 21:47

Also, when you try to private key to stay and the public key from you had, then can manage Theoretisch, man muss noch ein bisschen was außen rum programmieren. Also es gibt halt ein gewisses Protokoll, mit dem communiziert wird. Das müsste man abbilden, sozusagen. Aber theoretischerweise, klar, das würde dann noch gehen. Aber der große Vorteil ist halt, dass du die Verwaltung von dem Private Key hast. Und der liegt auch nicht einfach so bei dir auf dem PC rum, der ist hinterlegt in euren Authenticators, in euren TPMs, in dem Security Inclave, in Windows Hello, in der iCloud Keychain, der ist auf jeden Fall sicher verwahrt, letztendlich in euren Authenticators.

SPEAKER_01 22:41

Da können wir vielleicht nochmal ganz kurz drauf zu sprechen kommen, was da sicher verwahrt heißt an der Stelle. Wenn wir aus anderen Kontexten diese Schlüsselpaare kennen, dann haben die meisten das ja vielleicht so in der Verwendung von SSH oder so. Sie wollen sich irgendwie auf ihren Server connecten, sie haben da ihr Schlüsselpaar für. Und da ist es ja die gute Security-Praxis, dass man eigentlich auf jeder Maschine ein eigenes Schlüsselpaar hat. Mein Schlüsselpaar ist nicht mir als Person zugeordnet, sondern hier mein Laptop hat ein eigenes Schlüsselpaar, um sich zu authentifizieren, hier mein Handy hat ein eigenes, mein Desktop-Rechner hat ein eigenes. Und jetzt ist es ja bei Passkeys so, dass wenn ich mich einmal damit angemeldet habe, du hast gerade schon gesagt, so das landet dann in meiner iCloud oder in meinem Passwortmanager oder sowas. Und das züngt ja wie wild durch die Gegend. Und wenn ich das so sehe, dann denke ich mir immer so, aber also wieso ist es so okay, dass wir diese Passkeys durch die Gegend zünden und bei anderen Stellen versuchen wir immer so Schlüsselpaare, so maschinenbezogen wie möglich zu lassen und bloß nicht irgendwie von der Maschine wegzukommen damit?

SPEAKER_02 23:51

Das ist tatsächlich eine sehr gute Frage und damit sprichst du auch einen kleinen, wunden Punkt an. Man unterscheidet bei Passkeys in synced und hardware-bound Passkeys. Und dem Nutzer oder Nutzerin ist selbst überlassen, wo der Passkey gespeichert ist. Jetzt, wenn wir bei Hardware-Bound Passkeys sprechen, dann könnte es in die Richtung gehen, die du auch gerade gesagt hast, dass ich das einfach nur auf meinem iPhone habe und dann steckt das dort im Secure-Enklave drin. Oder es ist nur mit meinem Android-Phone in einem TPM oder so. Es kann auch nur auf meinem lokalen Authenticator, je nachdem, was das Betriebssystem für einen Local Authenticator eben anbietet. Oder ich habe es auf dem Yubi-Key, auf so einem USB-Token. Das wäre sowas, wie du es jetzt auch gerade beschreibst. Und das ist tatsächlich was, was wir eigentlich empfohlen wird zu haben, wenn wir von Parskeys sprechen. Jetzt ist es aber natürlich so, jetzt, wenn ich jetzt zu meiner Oma gehe und sage, Oma, hier hast du so einen USB-Stick, so ein Parskey, sorry, so ein Yuppie-Key, den musst du immer reinstecken, wenn du dich jetzt einloggst. Dann sagt sie, check ich nicht. Wobei meine Oma ist sehr clever. Ganz ehrlich, meine Oma ist ja clever, die wird es auf jeden Fall verstehen. Aber es ist natürlich wieder so UX-mäßig ein bisschen seltsam. Deshalb gibt es dieses Sync-Passkeys. Deshalb gibt es die Möglichkeit zu sagen, hey, speichere den Passkey, deinen privaten Key und auch ein bisschen was. Es ist eigentlich, was man wirklich speichert, darüber kann man auch noch reden, eine Art JSON. Das ist ein JSON, wohin der Private Key hinterlegt ist und noch so ein paar Meterinformationen. Das ist, wenn wir sagen, wir speichern den Passkey quasi. Und der kann halt eine iCloud Keychain landen oder der ist irgendwie gesynkt auf jeden Fall. Und damit aktiviere ich natürlich die Möglichkeit, dass ich über Device-Grenzen hinaus diesen Passkey gegebenenfalls nutzen kann. Jetzt ist es aber so, du vergleichst es natürlich jetzt mit SSH-Zugang auf einem Production Server. Und da sollte jede Maschine ihr eigenes Paar haben. Mit was wir das aber vergleichen sollten, ist unsere Passwortmanager. Wenn wir, also das sind ja eigentlich unsere Repräsentation für unsere Passwörter, jetzt diese Passkeys. Und wenn wir Passwortmanager haben, also wo liegt denn die Datenbank vom Passwortmanager? Wo liegen denn eure Passwörter? Shared ihr die nicht auch irgendwie? Ist die nicht auch meistens in einer OneCloud oder iCloud oder Google Drive? Die Datenbank liegt auch schon in der Cloud. Und da muss man ein bisschen aufpassen. Ich weiß, ich kriege da oft, oder Passkeys kriegen da oft so dieses Reingehacke, ja, jetzt shared ihr auch im Private Key und es ist total unsicher. Aber im Gegenzug ist es halt nach meiner Meinung, ja, aber wo liegen eure Passwort-Datenbanken? Die liegen doch auch in den Clouds. Und das ist so ein bisschen der Vergleich. Aber nichtsdestotrotz, ich will auf jeden Fall nicht sagen, dass Shared Passkeys gut sind. Was ich nur sagen, also Hardware-Passkeys ist die Empfehlung, aber Security ist ja immer ein UX und Performance versus Sicherheit letztendlich. Und wenn wir halt es wollen, dass wir halt, ich habe jetzt ein iPhone, ich habe von mir noch ein MacBook und noch was anderes. Und wenn ich halt mich überall einloggen möchte, dann habe ich halt ein Sync-Pass-Key. Aber am sichersten wäre, wenn jedes Device seinen eigenen Passkey hat für denselben User-Account. Denn ein User-Account kann mehrere Parskeys registriert oder hinterlegt haben, tatsächlich.

SPEAKER_01 27:38

Okay. Dann ist das vielleicht jetzt ein guter Übergang, um sich mal so ein bisschen um die Implementierung Gedanken zu machen. Und wir steigen einfach direkt ein mit, ich habe hier die programmierbare Webseite, ich möchte gerne irgendwie User anbinden und die sollen sich gerne per Parskey anmelden können. Was brauche ich dafür, um das anbieten zu können?

SPEAKER_02 28:01

Erstmal hängt es natürlich davon ab, was ihr für einen Identity-Provider verwendet oder Authorization Server. Wenn ihr jetzt, angenommen, ihr habt jetzt selbst ein Backend, was irgendwie die ganze Login, Authentifizierung, Autorisierung macht, dann ist es fairerweise gebaut. Dann ist es fairerweise ein bisschen komplizierter, weil dann müsstet ihr eigentlich das Ganze relativ selbst implementieren. Ich würde jetzt erstmal den Weg gehen, dass man Identity Provider hat und dann später darüber gehen, dass man das alles selbst implementiert. Weil da gibt es so ein paar Feinheiten, auf die man da achten muss. Also es gibt drei Möglichkeiten andersrum, es gibt drei Möglichkeiten. Entweder man implementiert alles, alles selbst, davon ist eigentlich abzuraten. Deshalb ist halt die Option ein bisschen, sollte man auf gar keinen Fall machen. Es gibt die Option, dass man halt einen Authorization Server hat. Key Clock bietet Parsey schon seit Jahren an. Key Clock is Open Source, has Parsey Support, and I must mich eigentlich um nicht mehr so viel kümmern. But when we just another IDPs denken, wie Entra ID, Google Identity, O Zero, Authentic, Ping Identity, wie sie alle heißen, die haben alle schon produktionsreifen parsky Support. Und was that bedeutet ist eigentlich nur, zum Beispiel bei Key Glocken aus Zero ist es ein Häkchen, was ich setze. Das sage ich ja, ich möchte auch bitte Parskys haben. Okay, dann muss man sich, wenn man das aktiviert hat, muss man sich leider ein bisschen Gedanken machen, wie bringe ich es jetzt den Nutzern bei. Und das ist der kompliziertere Part, ehrlicherweise die Kommunikation. Das Komplexe ist gar nicht mal mehr so, dass ich das jetzt irgendwie aktivieren muss, weil dafür sollte ich ein IDP verwenden und die unterstützen das. Die bieten mir dann diese ganze Kommunikation mit dem Browser an. Und ich würde auch gerne noch ein bisschen was zu den Protokollen, die da hin und her fließen, müssen wir später noch ein bisschen aufrollen, um zu verstehen, warum Parski überhaupt Phishing-resistent sind. Aber bleiben wir erstmal so bei der generellen Einzelne. Ich will es auf jeden Fall einsetzen. Ich brauche natürlich eine Frontend Library, die ich in React, Angular, View, Svelte, Solid, wie sie alle heißen, einbinden. Da gibt es aber schon zig Visander Mare tatsächlich, die ich einsetzen kann, auch Framework-unabhängig, also auch reine JavaScript Libraries, die ich dann verwenden kann, den ich lediglich die Anbindung an mein IDP ermöglichen muss. Das heißt, es ist ein Frontend SDK, was ich dann jetzt endlich einbaue.

SPEAKER_01 30:42

Aber das ist das ganz normale SDK von dem IDP. Also this is so here mein Out Zero JS oder sowas, was dann Radschpress.

SPEAKER_02 30:50

Genau, genau, genau. This can das SDK von dem IDP sein. Es gibt aber auch tatsächlich schon when we just alles selber machen will, gibt es SDKs, mit denen ich das auch bewerkstelligen kann. Ich würde niemals das von Grund auf implementieren. Es gibt auch SDKs, die Links kann ich auch gerne euch noch geben, dass ihr die auch noch share könnt, wo ich dann halt dessen meine Angle-Anwendung zum Beispiel einbinden kann. Und die halt einen Wrapper bildet um die sogenannte Web Auth N API. Die Web Authenti API ist die JavaScript-API, mit der ich dann Parse Keys verwalten kann, beziehungsweise muss ich ja im Browser etwas haben, mit dem ich dann mit dem Authenticator sprechen kann. Da gibt es so ein Protokoll, das nennt sich Client to Authenticator Protokoll 2, CTAP 2. Das 2 hat tatsächlich einen Hintergrund, aber es ist halt die zweite Version davon. Und dieses Protokoll muss halt vom Browser implementiert werden und das macht diese WebAuth N API. Und das ist diese JavaScript-API. Die kann ich nativ aufrufen, da muss ich dann gewisse Dinge berücksichtigen. Darüber wird automatisch geregelt, welche Authenticator denn zur Verfügung stehen? Das heißt, es gibt so eine Art Discovery-Schnittstelle von meinem Browser.

SPEAKER_01 32:14

Aber wenn ich da mal ganz ketzerisch einspringen darf vielleicht, also wenn es ja schon diese WebAuth-API gibt im Browser, die irgendwie JavaScript zur Verfügung gestellt wird, wozu brauche ich denn dann da noch irgendwie ein SDK oder ein Library drumherum? Wieso kann ich nicht direkt mit der Browserschnittstelle sagen, so hier mach mal Passkey jetzt?

SPEAKER_02 32:36

Kannst du gerne machen, aber warum verwenden wir Solid View React Angular? Wir können doch direkt die DOM API aufrufen und die nativen Events handeln. Und wir lieben es ja, Frameworks zu verwenden, weil die vielleicht schon ein gewisses Wissen haben, uns leichterere Funktionalitäten zur Verfügung stellen und vielleicht schon ein paar Sachen einfach wegkapseln, dass wir nicht mit der Komplexität überfordert sind, sozusagen. Also die uns einfach ein leichteres Interface auch zur Verfügung stellen, als diese API letztendlich. Also es ist ja einfach nur eine Hilfe auch in dem Sinne, die eine leichtere Anbindung macht. Dass ich vielleicht auch in meiner Angular-App, Angular ist ja alles zum Beispiel TypeScript in den meisten Fällen oder eigentlich immer, dass ich halt auch eine TypeScript-NPM-Package habe, weil ich einfach einbinde und nicht jetzt irgendwie plötzlich mit der nativen JavaScript API, WebAuth N API kommunizieren muss. Also es ist einfach nur eine Brücke oder halt natürlich eine Hilfe auf jeden Fall. Und so etwas existiert natürlich auch backend sight. Also es gibt auch für C-Sharp, für Java, für Rust auch Bibliotheken, mit denen ich das selbst verwalten kann, sprich dass ich dann backend sight, kann ich dann validieren, okay, mir wurde zwar jetzt ein Public Key zugestellt, aber gleichzeitig kriege ich auch Metainformationen über den Authenticator. Ich kann backend sight zum Beispiel auslesen, okay, hier wurde mir jetzt ein Public Key zugeliefert und der Authenticator ist ein Thinked Authenticator, also ein Thinked Pass Key. Also der Parskey ist halt etwas, was in die ICL-Keychain zum Beispiel reingegangen ist und so weiter.

SPEAKER_01 34:25

Und das bekomme ich mitgeteilt als.

SPEAKER_02 34:29

Ja, das sind Metadaten, die mitgeliefert werden. Und ich kann natürlich serverseitig sagen, nein, ich erlaube nur Hardware-Bound und Passkeys. Also ich will, ich will nicht. Tatsächlich ist es sogar so krass, man kann sich, jeder Authenticator hat eine Art ID. Diese ID hat einen speziellen Namen, der mir jetzt entfallen ist. Aber es gibt so eine ganz, ganz, es gibt halt eine ID von diesen ganzen Authenticator und ich könnte backendseitig eine Art Whitelist haben, welche Authenticator wirklich erlaubt sind und welche nicht und die dann rejecten.

SPEAKER_01 35:02

Ist das heißt gängige Praxis? Das ist ja alles noch gar nicht so gängig vielleicht, aber ist das, kommt es vor, dass ich so bestimmte Privilegien dann an bestimmte Passkeys knüpfe oder an bestimmte Authenticator, dass ich zum Beispiel sage, du willst dieses Konto, weiß ich, löschen, so, ja, du willst irgendwas sehr Destruktives irgendwie machen. Das geht nur, wenn du nicht angemeldet hast mit einem Passkey, der halt irgendwie hardware-bound ist. So, aber wenn du jetzt nur in dein Konto reingucken willst oder sowas, ja, da kannst du mit Passwort, mit Nimm Sync-Key, mit was auch immer irgendwie alles ankommen.

SPEAKER_02 35:40

Also in der Authentifizierung, Autorisierung trennen wir das ja eigentlich streng. Also möglich ist es sicherlich, wahrscheinlich. Aber wir trennen das ja eher. Haaskeys sind die reine Authentifizierung. Ich bin ich, ich bin die Martina und ich darf da mich jetzt einloggen. Und ich bekomme dann ein Access-Token. Also daraufhin bekomme ich halt einfach nur ein Access-Token und das ist dann die Autorisierung, was darf ich? Okay, ich darf löschen und oder ich darf nicht löschen und so weiter. Es wäre, glaube ich, super komplex, wenn man jetzt sagen würde, okay, die Martina hat sich jetzt mit einem Sync-Passe eingeloggt, deshalb darf sie nicht das Konto löschen, oder die Martina hat sich mit einem Hardware-Bounded Passkear eingeloggt, deshalb darf sie das Konto löschen. Also in der Theorie kann man das ja implementieren, das ist alles mögliche, aber ich glaube, in der Praxis wird man das nie so machen, weil das ja immer schon immer streng getrennt. Wir sagen einfach, das ist eine ist Authentifizierung und das andere ist Autorisierung und das ist eigentlich und Parskys in reine Authentifizierung. Aber ich meine, auszuschließen ist es nicht, weil zum Schluss kann man das ja alles custom-mäßig implementieren und die User können natürlich machen, was sie wollen, um es mal so zu sagen.

SPEAKER_01 36:57

Okay, okay. Okay, dann bekomme ich also dieses ganze Paket zurück. Was mache ich damit?

SPEAKER_02 37:06

Also als Server bekommst du jetzt oder als Client.

SPEAKER_01 37:09

Genau. Naja, als Server, also genau. Da hat sich jetzt der Benutzer angemeldet. Was davon muss ich irgendwie aufheben? Wie gehe ich jetzt damit quasi weiter um?

SPEAKER_02 37:19

Genau, also du brauchst eine Datenbank. Du brauchst eine Datenbank, wo du halt jetzt letztendlich den Public Key reinspeicherst, zusammen mit den Metadaten. Weil es könnte ja auch sein, also wir können ja mal so komplett durchgehen. Wir können ja mal sagen, was passiert bei der Registrierung, was passiert bei der Anmeldung, weil da passiert ein bisschen was anderes. Weil bei der Registrierung wäre ja quasi der Part, wo der Webserver sagen könnte, er akzeptiert diesen Authenticator, er akzeptiert diesen Passkey von diesem Authenticator oder nicht. Und angenommen, er akzeptiert es und es ist alles in Ordnung, dann würde halt, müsste der Server halt diesen Public Key letztendlich speichern, zusammen mit den User-Daten.

SPEAKER_01 38:03

Und den kann ich aber Key-Verfahren sei Dank einfach im Klartext bei mir in die Datenbank werfen. Da muss ich quasi keine besondere Vorkehrung mehr treffen.

SPEAKER_02 38:12

Genau, Public Key ist eigentlich relativ, was heißt egal, aber ja, eigentlich schon. Eigentlich schon relativ.

SPEAKER_01 38:18

Dieser Public Key, den ich bekomme, der wird quasi für mich als Webseite, als Plattform quasi neu kreiert. Das heißt, du, Martina, schickst nicht jeder Webseite denselben Public Key, sondern du erzeugst quasi jedes Mal eine neue Identität, wenn du dich irgendwo anmeldest. Und das sind alles so, in Anführungszeichen, Wegwerfschlüssel.

SPEAKER_02 38:41

Nein, also ja und nein. Wir können ja, also was passiert eigentlich bei der Registrierung? Wir können ja mal diesen kompletten Float doch durchgehen, bevor wir direkt schon im Backend gelandet sind. So, was passiert? Wir besuchen eine Webseite, ich möchte mich da registrieren. Mir wird angeboten, Parsky-Registrierung. Okay, ich klicke da drauf, Parsky-Registrierung. Das kann natürlich auch schon eingeloggt sein mit einem Passwort und kann dann auf einen Button klicken, registriere ein Parsky. Es kann ja beides schon funktionieren, letztendlich. Was passiert dann? Der Server sagt, okay, alles gut, wir können das gerne initiieren, ich kann das. Was dann im Browser passiert über diese Web Authenti API, das erstmal herausgefunden wird, Discovery, was gibt es denn für Authenticators? Wo kann ich ein Passkey erstellen? Und das ist so eine Create-Funktion, nennt sich die. Und dieser Create-Funktion, und das ist ganz wichtig, muss sich so eine Challenge mitgeben, die serverseitig generiert wurde. Weil wir brauchen ja etwas, was wir signieren können. Das ist dieses Challenge-Response Verfahren. Also der Server hat für einen Client, für einen speziellen Client, ein einmaliges Token kreiert mit einer gewissen Entropie, dass das nicht erratbar ist und so weiter und so fort. Okay, das geht jetzt über diese WebAuth N API, über dieses Client-Authenticator-Protokoll zu dem Authenticator, den der Nutzer vielleicht ausgewählt hat. Es kann ja sein, dass ich zwei Yubi-Keys angesteckt habe. Und dann sage ich, ich will den aber hier auf den Yubi-Key erstellen. Was passiert in dem Authenticator? Der Authenticator muss FIDOTO ready sein. FIDOT2 sind quasi die Technologien, die dahinter stecken. Und dann erstellt mein Authenticator dieses Schlüsselpaar. Einmalig, einmalig für, und das ist ganz wichtig, diese Origin. Für diese Origin, und das wird mitgespeichert als Metadaten im Authenticator, wird jetzt dieser Private Public Key Par erstellt und noch ein paar Metadaten, wie zum Beispiel the Origin. Jetzt signiere ich als Authenticator this challenge, die mir gesended with the private key. I signere also this challenge. What is the work on the server? That's the authenticator spread with the browser and says, Yeah, here, thank you for the infrage. I have to signiered challenge and a public key. The browser schicktes on the server. The server can surprise if I this authenticator erstelled Parsky accepted. Yeah, nein. This is the where we have been. And when I this challenge erfolgreich validieren can, then we will, that this is public key is to the private key, who this challenge has. Also alles good. I speicher it. Super, passkey registries. Just lock it in and it was a new private public key ergot, but what before it is, that the server challenge errors and over the webbrowser on the passing authenticator this challenge schickt. Dazu passiert in the measure of an Auswahlfeld. Also the browser über the Web of N API discovered with the authenticators that for dieser Origin, und this is jetzt der wichtigste Schritt, wer hat Passkeys für diese Origin? Wie so ein Broadcast eigentlich. Hey Leute, ihr seid ja alle Authenticators, die gerade da connected sind. Wer hat für diese Origin einen Parsey? Und dann melden sich vielleicht ein paar, weil ich kann ja, wie gesagt, für eine Origin mehrere Parsekeys theoretischerweise haben. Und dann kann ich auswählen, okay, ich habe jetzt gerade einen YuPI-Key, ich möchte jetzt, dass der Parsekey erstellt wird, äh, sorry, nicht erstellt wird, Entschuldigung, genutzt wird, den ich auf diesen YuPIKey erstellt habe. Dann wähle ich das Aufsatznutzer, es geht wieder zu meinem Authenticator. Im Authenticator legt er mein Private Key, und mit dem Private Key wird die Challenge erneut signiert, geht wieder alles zurück über den Browser an den Server. Und der Server muss nichts anderes tun, als den Public Key, den er in der Datenbank ja sowieso schon gespeichert hat, zu nutzen, um diese Signatur zu überprüfen. Und damit weiß der Server, coole Sache, das ist der Nutzer, das ist der Nutzer Herbert, den habe ich hier schon oft gesehen, den lassen wir jetzt mal rein.

SPEAKER_01 43:25

Okay, das hat aber glaube ich meine Frage nicht beantwortet oder ich habe es nicht mitgehört. Okay, Entschuldigung. Nein, alles, alles, alles gut, wir haben uns einfach missverstanden. Der Public Key, den der Herbert an den Server schickt, wird der pro Origin quasi neu erzeugt? Oder hab ich auf meinem oder bringt der Yubi-Key so eine Identity zum Beispiel mit, bringt mein Authenticator eine Identity mit, die dann immer verwendet wird, um mich bei allen möglichen Plattformen anzumelden? Also meine Frage zielt eigentlich so ein bisschen darauf ab, wenn ich jetzt mehrere Plattformen betreibe, Ich bin Facebook und ich habe hier Instagram und WhatsApp und keine Ahnung, irgendwie alle. Und du meldest dich bei jedem Service einzeln an. Könnte ich über den Public Key merken, dass du immer dieselbe Person bist, weil du mir jedes Mal denselben Public Key schickst, oder wird quasi der Public Key für jeden Fall neu erzeugt?

SPEAKER_02 44:20

Immer dann, wenn ich, also um es kurz zu machen, es gibt immer einen neuen Parskey für jede Origin. Wenn ich mich auf Facebook mal eingeloggt habe und sage, add a parsey, wird ein neuer Parsey erzeugt, ein neues Private Public Key. When I then off Google gear and make my passkey, will be out a newer passkey erzeugt, public private key. And this is all the point. Passwords can share and reuse. Password can even passkey is laut specification and design technique unmost to verwend. That's not it. Also I meld with a passkey by the same origin. Also, I verwend every private key, um, but um a passkey to registries, it was completely new erst. Also, it's a public private key. And that Parsekeys not.com many parskeys hinterlegen, while I have a hardware-bound parsey with a Yupi Key, vielleicht have my smartphone a passkey. But they are in falling. You can many parseys have. Tatsächlich ist es die Web Auth N API, also ja, beides. Also ja, also wenn ich jetzt die Webh N API schickt ja quasi diese Broadcast-Nachricht, sagt, hey, ich habe hier Facebook.com, Origin, wer hat alles Passkeys für mich? Und klar, ein Authenticator meldet sich dann oder meldet sich dann nicht. Das heißt, es sind beide Parteien in dem Sinne. Aber also denen vertraue ich mehr als so manchen Nutzern. Oder nutzen es nicht.

SPEAKER_01 46:45

Alles ich wollte auch gar nicht unterstellen, dass jetzt irgendeiner von denen Schindluder treibt. Ich wollte ja nur immer sagen, am Ende ist ja immer, wenn wir bei Security davon reden, dass es nicht möglich ist, in Anführungszeichen, ist es ja quasi basierend auf dieser Implementierung. Und da kann ja immer auch mal, also von Vertrauen ganz abgeschrieben, kann einfach ein Fehler drin sein. Aber ich meine.

SPEAKER_00 47:06

Martina, korrigiere mich gerne, falls ich dir falsch liege, aber mal angenommen, mein Tool meldet sich jetzt, also WebAuth N, und gibt das, also versucht dieses Rätsel zu lösen, dann bringt das doch eigentlich in dem Kontext trotzdem eh nichts, weil für die reale Webseite, für die ich halt gefischt werden sollte, fehlt ja trotzdem der Public Key, oder? An der Stelle. Also es sollte dann trotzdem nichts bringen, selbst wenn er sich fälschlicherweise meldet. Habe ich das richtig verstanden?

SPEAKER_02 47:34

Ja, tatsächlich. Ja, du hast vollkommen recht. Also, genau, also ja, du hast vollkommen recht. Also nur, also du hast absolut recht, aber nur vom Traditionellen.

SPEAKER_01 47:46

Ich sag's nicht so oft, sonst passt dein Ego nach in der Tür, wenn man jetzt wechseln gerade.

SPEAKER_03 47:50

Nee, nee, nee, nee, alles gut.

SPEAKER_02 47:53

Ich habe nur gerade, ich bin jetzt gerade von dem Traditionellen, man wird auf eine andere Origin geführt und da gibt das Passwort ein, aber das bringt ja so oder so nichts, weil der hat nicht den Public Key, also man ist ja ähnlich eingeführt.

SPEAKER_03 48:05

Genau.

SPEAKER_02 48:06

Ja, du hast vollkommen recht.

SPEAKER_01 48:08

Cool. Okay, jetzt, wo wir den Happy Path durchgespielt haben, so, wie läuft hier die Anmeldung und die Registrierung ab? Gibt es ja vielleicht noch den ein oder anderen Edge Case, den man aus Betreibersicht sich irgendwie mal anschauen müsste und gucken müsste, ob es da Probleme geben würde, wenn ich jetzt auf Pathkeys migrieren will. Wie sind denn so Sachen wie Account Recovery, Passwort-Reset, also wir kennen das ja alle aus der Support-Welt, so, ja, Kunden machen manchmal Probleme. So, Produktentwicklung wäre viel einfacher, wenn wir keine Kunden hätten. Und wenn jetzt, wenn jetzt der Herbert von eben ankommt und sagt, ich kann mich nicht mehr anmelden, ich habe mein Yubi-Key verloren, ich habe ein neues Handy bekommen, wo meine Ecredentials drauf sind, keine Ahnung, was mache ich denn jetzt so? Wie aufgeschmissen sind denn Leute, wenn eben die Passeys mal abhanden gekommen sind?

SPEAKER_02 49:01

Ja, das ist natürlich immer der Part, über den man nicht gerne redet, wenn man gehypt ist von einer Technologie. Deshalb bedanke ich mich, dass ich eingeladen war. Nee, also natürlich auf jeden Fall gibt es auch bei Passkeys ein paar Probleme. Also zum einen ist das BSI um die Ecke gekommen und hat gesagt, dass Think-Passkeys gefährlich sind, nutzt sie nicht. Das BSI empfiehlt nur Hardbounded Passkeys. Dann haben wir schon das kleine Problem, dass ich nicht jedem Nutzer und Nutzerin auch zutrauen möchte, jetzt halt sich, das ist ein UX-Overhead, da wird niemand jetzt, das ist super nervig. Und es wird tatsächlich vom BSI empfohlen, das noch nicht so zu verwenden. Vor allen Dingen nicht im Medizinsektor. Da hatte ich auch letztens eine sehr lange Diskussion mit einem Arzt tatsächlich. Also, oder mit einem Arzt, der auch in der IT beschäftigt ist, oder sich da auskennt, zumindest. Aber ein anderes großes Problem hast du natürlich angesprochen: Account Recovery und Passwort und Reset von einem Parsey. Klar, du hast jetzt einfach nur ein Hardware-Bounded Parskey auf dem Smartphone und wenn dein Smartphone verloren ist, ist das eigentlich ähnlich wie mit dem zweiten Faktor, dann hat man erstmal ein Problem tatsächlich. Das ist weg. Du kannst dich dann erstmal nicht einloggen. So, jetzt gibt es die Seite von Entwicklern oder Entwicklerinnen oder auch die FIDO-Allianz, die hinter Parskey-Entwicklung steckt, die halt sagen: Ja, zu jedem wichtigen Account solltest du halt deshalb mehrere Parskeys hinterlegen. Am besten tust du bei jedem wichtigen Account ein Yubi-Key nehmen und kaufen für 200 Euro. Ich glaube, so teuer sind sie nicht, aber die sind natürlich auch schon ein bisschen teurer. Und halt für jeden Account halt so einen hardware-basierten Yubi-Key halt hinterlegen. Und die legst du dann in den Tresor, weil dann hast du das Problem natürlich nicht. Weil wenn dann dein irgendwas verloren geht, dann kannst du deinen Yubi-Key noch einschließen.

SPEAKER_01 51:01

Also ich muss auch sagen, so habe ich das gemacht. Ich habe hier meinen Yubi-Key an meinem Keychain so, ja. Und ich habe an der Stelle, die ich jetzt natürlich nicht in der Kamera zeige. Einen zweiten Yubi-Key. Und jedes Mal, wenn ich den einen Yubi-Key irgendwo registriere, registriere ich den anderen halt auch gleich mit. Weil den einen habe ich immer bei mir, den kann ich rein theoretisch verlieren, der hängt am Schlüsselbund, der kann kaputt gehen, runterfallen, auch wenn diese Dinge eigentlich unzerstörbar sind, so, ja. Aber also genau das mache ich und ich muss sagen, ich würde mich schon als so ein bisschen security-affin bezeichnen. Und selbst für mich ist es ein Pain in the Ass, so irgendwie mit zwei Keys zu hantieren. Und wenn ich jetzt an meine Eltern denke oder so, ja, an denen sagen, okay, übrigens, das ist jetzt dieser USB-Stick, den benutzt du irgendwie jedes Mal, wenn du dich anmeldest. Und übrigens, hier ist noch ein zweiter und mit dem machst du die ganze Arbeit bitte nochmal. So. Und pass bloß auf, dass du sie nicht am selben Ort aufwachst. Also das ist ja eigentlich realitätsfern, wenn man nicht so paranoid ist wie wir.

SPEAKER_02 52:00

Ja, ja, absolut. Genau. Und das finde ich auch so erschreckend, dass das so manchmal als offizielle Empfehlung gegeben wird, wo ich denke, das ist nicht realitätsnah. Ich meine letztendlich ist das noch ein ungelöstes Problem oder Herausforderung. Jeder muss mit einer Art Custom-Lösung daherkommen. Also es ist viele, was ich schon gesehen habe, viele Unternehmen machen dann auch einfach einen One-Time-E-Mail-Magic-Link sozusagen, der auf eine E-Mail-Adresse zugesendet wird. Also, dass ich dann mich darüber, also Recovery-Strategien, die wir auch schon bei Passwörtern gesehen haben. Dafür brauche ich natürlich die Sicherstellung über eine verifizierte E-Mail-Adresse. Also muss natürlich sicher sein, dass dann wenigstens die E-Mail-Adresse derart zweite Faktor ist, wenn man so sagt, wenn man es so sagen kann, wo halt dann dem Nutzer wirklich gehört, wo ich dann vielleicht auch ein One-Time-Passwort, vielleicht, ein OTP oder sowas, halt hinchecken kann. Halt irgendwas, womit sich der Nutzer dann halt einfach nochmal authentifizieren kann.

SPEAKER_01 53:00

Vielleicht da auch noch eine Rückfrage. Das geht ja gerade so ein bisschen davon aus, dass du meine E-Mail-Adresse quasi schon hast, um jetzt so einen Recovery-Prozess starten zu können. Und bei den allermeisten Systemen da draußen ist es ja so, weil wir melden uns immer an mit der Kombination aus E-Mail-Adresse und Passwort. Weil nur Passwort wäre ja so ein bisschen sehr trivial irgendwie, ja. Aber das ist ja für ein Pastkey eigentlich nicht notwendig, oder? Das heißt, wenn ich mich anmelde bei programmier.bar und sage, ich will ein Pastkey nehmen, dann zwingt mich als Plattform ja niemand erstmal dazu, die E-Mail-Adresse mitzuerfassen, oder?

SPEAKER_02 53:34

Ja, absolut richtig. Ist per Spezifikation auch nicht notwendig. Aber macht halt unter dem Recover-V-Sinn-Mechanismus, dass man nicht mehr macht.

SPEAKER_01 53:43

Genau, aber ich muss es halt so mitdenken. Ich krieg es nicht mehr so als Benefit automatisch mit. Ich muss mich quasi darum kümmern, so okay, diese E-Mail-Adresse brauchen wir jetzt trotzdem auch, auch wenn du hier schon irgendwie angemeldet bist und sowas alles.

SPEAKER_02 53:55

Genau, genau. Und das ist halt von mir aus das, was jetzt halt noch ein bisschen schwierig ist, weil es gibt keine standardisierte Lösung dafür. Jeder macht es halt irgendwie so ein bisschen wie halt halt immer Custom-Lösungen. Aber und man nimmt sich halt Hilfe aus den bekannten Szenarien oder wie Kawa wie Strategien, die man halt bei Passwordern ist, schon hat. Aber klar, man braucht plötzlich Dinge, dann doch wieder, die man ja eigentlich laut Spezifikation nicht mehr braucht. Ein anderer, oh ja, sorry, du hast noch was. Ich wollte zum neuen Punkt gehen, deshalb kannst du gerne.

SPEAKER_01 54:32

Ich auch, aber dann nehmen wir deinen zuerst. Das ist schon besser.

SPEAKER_02 54:35

Ein Punkt, ein Hauptpunkt ist natürlich die Adaption der Nutzer und Nutzerinnen. Also man muss halt natürlich klar machen, dass jetzt Paskeys vielleicht cooler sind. Und das kann man natürlich jetzt tun, indem man euren Podcast anhört zu Passkys, damit man ein bisschen versteht, wie PayPal.

SPEAKER_01 54:53

Immer die richtige Lösung auf jedes Problem. Einfach programmierbar hören.

SPEAKER_02 54:58

Wie Paskeys funktionieren. Aber es ist halt schon ein komisches Gefühl. Also ich habe ja anfangs so ein bisschen gescherzt mit, oh ja, KittyCram.org und den traue ich meinen Passwörter nicht und keine Ahnung. Aber wenn ich auf Kitticram.org gehe, auf Registrieren klicke und plötzlich meldet sich mein Authenticator, meine iCloud-Keychain und sagt, oh ja, okay, hier, bitte mach das mal, dann fühlt sich das nicht so gut an. Zumindest wenn ich keine Ahnung habe, was da eigentlich passiert halt hinten dran. Dann ist es ja auch wieder ein Bruch in der UX, dass ich gehe plötzlich vom Browser irgendwie weg, ein anderes Fenster öffnet sich. Das sind, muss ich fairerweise zugeben, ich bin keine UXlerin und UIlerin. Mir ist es eigentlich egal, ob sich da jetzt ein anderes Fenster öffnet oder nicht, aber ich kenne viele Leute, die stören sich daran. Und das ist eigentlich so das hauptsächliche Problem. Lustigerweise gar nicht so die Technologie hintendran, sondern wie sich die Nutzer und Nutzerinnen jetzt dabei fühlen. Und da muss man halt sehr viel Aufklärungsarbeit tatsächlich bringen. Auch irgendwie beweisen oder auch zeigen, ja, hey, ihr braucht aber keine Scherz, keine Passwörter mehr auszudenken. Ihr müsst ja gar nichts mehr ausdenken. Ihr könnt einfach nur euch mit, das ist dann gespeichert, vielleicht irgendwie hardware-basiert oder irgendwie nur iCloud Keychain und ihr könnt es einfach benutzen. Aber auch das fühlt sich natürlich komisch an, auch wie so ein kleiner Kontrollverlust. Weil beim Passwort gebe ich es ja immer noch selbst ein und ich habe dann so das Gefühl, ja, ich weiß, was ich tue. Und ich achte genau drauf, wo ich das eingebe oder so. Und das sind das sind eher alles psychologische Sachen, die da plötzlich eher eine Rolle spielen. Was es aber gibt, was auch über die WebOth n API angeboten wird in den Webbrowsern, dass ich zumindest beides gleichzeitig verwenden kann. Also es gibt die Möglichkeit, dass ich so ein Input-Feld habe und wenn ich da reinklicke, gibt es so ein Auto-Fill-Feature. Das ist tatsächlich so ein WebOuth N-Attribut an meinen Inputs. Und dann bekomme ich auch automatisch hinten dran vorgeschlagen, wenn ich ein, angenommen, ich hätte ein Passkey für diese Origin, also für die Webseite, dann kann ich das auch sofort autofillen. Oder wenn ich das halt noch nicht möchte, dann kriege ich auch weiterhin mein Passwort vorgeschlagen, vielleicht bei meinem Passwortmanager. Das heißt, es gibt da schon so ein bisschen Unterstützung, damit die Adaption ein bisschen attraktiver ist. Tatsächlich.

SPEAKER_00 57:22

Ja, ich finde das interessant, ich habe mich bei all dem, was du gerade gesagt hast, richtig selbst wiedererkannt. Also weil bei Google ist ja mittlerweile auch so, die bieten das ja an. Also es ist natürlich jetzt nicht irgendwie hardbound an der Stelle. Aber dann so vor allem, hey, nutzt doch mal Parskis, du musst dein Passwort nicht eingeben und es ja, oh, nerv nicht. Nee, man hat gesagt, ja, okay, komm, ich mach jetzt ein Parskis und dann habe ich mich damit auseinandergesetzt und muss sagen, also das ist ja super spannend, die Technologie dahin und wie sehr mir das alles so vereinfacht. Also ich finde es halt irgendwie schon geil. Aber trotzdem, eigentlich war es bei mir so aus einem Nervpunkt heraus und ich glaube, du hast da echt voll das Thema angesprochen, diese mentale Barriere, die man da irgendwie durchbrechen muss, ist, glaube ich, so wirklich eines der größten Aufgaben, so diese Akzeptanz dafür zu schaffen. Weil eben auch dieses so, okay, am Ende habe ich ein Passwort und das ist nur in meinem Kopf und keine Maschine kann mir irgendwie was wegnehmen. Das ist das Einzige, was ich habe. Und von daher, diesen Ansatz, den du am Ende gesagt hast, man beides hat. Du hast ein Passwort notfalls, mit dem du dich auch sowieso anmelden kannst, ohne mal Passkis, ich glaube, das ist ein sehr guter, irgendwie so eine sehr gute Abwägung. Von wegen, lasst mal bitte in die Richtung von Passkis eine Transition machen. Also ja, voll valider Punkt. Aber geht euch das auch so?

SPEAKER_01 58:27

Also ich beobachte Passkeys in the Wild ja tatsächlich eher so als zusätzliche Option. Aber ich sehe es ehrlicherweise noch sehr selten bei so einer initialen Registrierung. Also ich habe es meistens eher so, lege hier dein Konto an, E-Mail-Adresse, Passwort und dann kommst du den nächsten Schritt, hey, willst du auch gleich irgendwie ein Pastkey mit hinterlegen? Aber ich hab, also ich müsste jetzt hart überlegen, aber ich glaube, ich habe noch nie irgendwie so als primäre Option gesehen bei der Accounterstellung, jetzt hier direkt mit Pastkey und Go for it.

SPEAKER_02 58:58

Ich glaube, ich glaube, das ist so eine Wahrnehmungssache, so ein bisschen. Aber ich habe auch, weil ich auch so ein bisschen, ich hatte die Zahlen nicht im Kopf, aber ich habe ein paar Zahlen mitgebracht, so ein paar Statistiken bezüglich der Verbreitung und Adoption, weil ich das auch super spannend fand. Und stand Mai 2025, das ist zwar jetzt schon wieder ein bisschen her, aber das fand ich trotzdem spannend, sind 69% der Nutzer haben mindestens ein Parskey. Und das fand ich schon.

SPEAKER_00 59:32

Das ist ja krass.

SPEAKER_02 59:33

Das fand ich super krass. Ich kann auf die Statistiken, ich schicke die euch, ich schicke die euch, dann könnt ihr die, dann könnte ich die natürlich verlinken. Weil ich haue ja jetzt irgendwelche Zahlen raus.

SPEAKER_03 59:42

Genau. Wir glauben dir mal.

SPEAKER_02 59:44

Ja, ja, genau, genau. Und das fand ich schon ziemlich krass. Aber auch.

SPEAKER_01 59:49

Diese Erhebung wurde gesponsert von der Fido 2 Alliance.

SPEAKER_02 59:54

Also ja, die ist von der Fido 2 Alliance, muss man tatsächlich auch sagen. Aber das heißt ja nicht, dass sie falsch ist.

SPEAKER_00 1:00:02

Ja, genau. Die sehen eben so, die wissen ja, was da abgeht.

SPEAKER_02 1:00:06

Aber die haben es auch begründet, weil im Mai 2025 wurde Microsoft oder hat Microsoft Parski zur Standardanmeldemethode halt quasi für alle neuen Microsoft-Konten halt eingeführt. Und wenn Microsoft das halt, ich weiß, gerade in vielen Unternehmen oder so, ist ja Microsoft immer noch der Platz hier. Und wenn Microsoft das macht, dann erst dann kann es ja was Gutes sein. Und ich glaube, dass das schon eine große Rolle gespielt hat. Eine andere Zahl, die ich super interessant fand, ist, dass Logins, also das Einloggen mit Passkey im Schnitt 8,5 Sekunden schneller sind.

SPEAKER_03 1:00:46

Geil.

SPEAKER_02 1:00:46

Als der Login mit Passwörtern. Das fand ich krass, das fand ich super interessant. Kann ich mir auch nur daher erklären, wir müssen ja das Passwort normalerweise noch hashen wieder. Also wir haben ja einen Hash-Algorithmus, einen kryptografischen Hash-Algorithmus wie B-Crypt, S-Script, Argon 2. Und wenn sich jemand mit dem Passwort einloggt, dann muss man ja exakt denselben Hash nochmal ausführen, zusammen mit dem Salt und so weiter, um zu vergleichen, ob das jetzt dasselbe Hash ist, der in der Datenbank liegt. Und ich glaube, dass das halt das Anmelden mit Passwörtern manchmal stark in die Länge ziehen kann. Und das braucht man halt bei Passkeys nicht. Tatsächlich.

SPEAKER_01 1:01:27

Meinst du wirklich, das kommt durch den Hashing-Algorithmus? Die sind doch auch mittlerweile so fixiert. Ich hätte eher gedacht, das kommt durch diesen ganzen UX-Pi-Tipps. Ja, also eintippen alleine für. Du musst dein Passwort eintippen oder du musst das raussuchen oder deinen Passwortmanager aufmachen oder keine Ahnung. Und bei einem Passkey sagst du halt, los.

unknown 1:01:46

Genau.

SPEAKER_01 1:01:46

Also ich hätte eher gedacht, dass der Teil vorher viel ausschlaggebender ist als der Kryptografie-Teil hinten dran, aber ist ja nicht meine Statistik.

SPEAKER_02 1:01:57

Könntet ihr natürlich auch recht haben. Wobei tatsächlich ist schon häufiger, also wie gesagt, B-Crypt ist ja mittlerweile auch ein zu schneller Hash-Algorithmus geworden, der zu schnell mit gerade so GPUs und was weiß ich verteilten Grafikkartenclustern auch gebrochen werden kann. Aber genau, und deshalb werden ja Hash-Algorithmen immer langsamer gemacht. Und ich hätte gedacht, dass es sicherlich vielleicht auch damit ein bisschen zusammenhängt. So weißt du? Aber.

SPEAKER_00 1:02:26

Ich hätte ja nochmal einen anderen Punkt aufgemacht, also der auch mit dem zu tun hat. Von wegen, also weil wir ja über die Akzeptanz in einer breiten Masse irgendwie gerade angesprochen haben. Aber ich muss sagen, mir fehlt es auch so ein bisschen, also gut, du hast gesagt, 69% haben schon einen, das fand ich jetzt sehr krass. Aber tatsächlich würde ich sagen, das sind einfach die großen Unternehmen, die gerade drauf setzen. Also wenn ich Kontakt hatte mit Parskeis so, weil das immer im Kontext Microsoft, Google natürlich, Apple, auf GitHub und so, also wirklich die großen Fische, aber mir ist auch so sonst auf kleineren Webseiten, wo man sich sonst anmeldet, ist das irgendwie noch gar nicht vorhanden. Also ich habe das Gefühl, auch so von Betreibersicht heraus, werden die gerade nicht so häufig irgendwie als mögliches Anmeldeverfahren benutzt.

SPEAKER_02 1:03:11

Angeboten.

SPEAKER_00 1:03:12

Genau, genau, genau.

SPEAKER_02 1:03:13

Also angeboten, ja. Also kann ich irgendwie nicht so ganz bestätigen. Also wenn ich irgendwie auf Amazon, Google, Microsoft, PayPal, auch TikTok die ganzen, so die ganzen großen bieten Parski schon seit irgendwie mehreren Jahren an, tatsächlich. Gut, Microsoft ist dazu jetzt erst letztes Jahr gekommen. Aber auch so klein, es gibt eine coole Webseite, die nennt sich Parsky Discovery, kann ich auch nochmal verlinken und euch schicken. Da sieht man auch, welche Webseiten alle schon mit Parsky-Support tatsächlich ausgestattet sind. Und wenn man da reinguckt, keine Ahnung, auch so Spotify, Twitch, auch die ganzen Unternehmen oder auch Dienstleister, die unterstützen alle schon Parskis. Und da gibt es, und die Liste ist ein bisschen cool, weil eine Liste kann man sogar auch eintragen, wenn man möchte, dass ein Unternehmen unbedingt Parskis unterstützen soll. Das ist immer so ein kleines Ranking irgendwie. Aber es ist auch eine Liste, aber Adobe, wie sie alle heißen, Slack, Discord, kriegt man eine ziemlich gute Übersicht, wer schon alles Parskis unterstützt und das ist definitiv schon die Mehrheit. Okay. Letztendlich. Also in meiner Bubble, so ein bisschen, habe ich ein anderes Bild.

SPEAKER_01 1:04:31

Okay.

SPEAKER_02 1:04:32

Tatsächlich.

SPEAKER_01 1:04:35

Wenn wir schon bei den Leuten sind, die Paskeys anbieten und implementieren müssen, vielleicht sprechen wir noch einmal ganz kurz darüber, was können die denn so alles falsch machen? Ich meine, wir haben in den letzten Jahrzehnten viel darüber gelernt, wie man so Passwörter richtig handeln muss und dass man die verschlüsselt und mit einem Säul dran schmeißt und sowas alles. Gibt es denn bei Passkeys was, was ich auf Plattformseite überhaupt falsch machen kann?

SPEAKER_02 1:05:02

Ja, also deshalb wäre es natürlich cool, einfach ein IDP zu verwenden, auf den man sich verlassen kann. Ein ganz dummes Beispiel ist der Algorithmus, mit dem der Public Private Key erstellt wurde. Der kryptografische Algorithmus. Denn genauso wie ich gerade gesagt habe, B-Crypt gilt schon als gebrochen, kann man natürlich auch einen schwachen kryptografischen Algorithmus verwenden für die Generierung der beiden Schlüsselpaare. Also der Schlüsselpaar ist Public Private Key. Das ist, ich meine, kryptografische Fehler ist auch wieder eine Oberst Top Ten leider mit drin. Und es ist tatsächlich so, dass viele ältere Authenticator natürlich auch keinen Support mehr haben für zum Beispiel, es gibt etwas, das nennt sich elliptische Kurven, Diffie Hellman, Digital Signatur. Das ist ein bisschen moderner, ist auch ein bisschen schneller. Und es kann halt passieren, dass ältere Authenticator Das halt nicht unterstützen. Und es macht doch definitiv Sinn. Das ist aber auch etwas, was vom Server kommt. Also, der Server kann bei der Erstellung des Passkeys mitgeben, ja, ich möchte aber bitte, dass der Passkey mit diesem Algorithmus erstellt wird. Das ist dann beispielsweise minus 7. Und wir wissen ja alle, für was minus 7 steht. Also, das steht dann einfach nur, okay, ich möchte bitte, dass der Public Key mit minus 7 erstellt wird. Und minus 7 steht einfach nur für elliptische Kurven, Digital Signature Algorithm. Das steht irgendwo toll in der Spezifikation drin. Das ist halt was, was man dann halt beachten muss. Und dann könnte es natürlich sein, dass die Web N API kein Authenticator findet, der jetzt ein Parsey mit diesem Algorithmus erstellen kann. Aber das sind halt gewisse Whitelisten. Ich habe es auch vorhin schon angesprochen, auch was Whitelisten von Authenticator angeht. It macht natürlich Sinn, auch da vielleicht tatsächlich erstmal zu sagen, vielleicht nur hardware-basierte Parsekeys. Das kann man dann auch über diese Challenge, die man dann letztendlich an den Authenticator schickt, senden lassen. Was ganz wichtig ist, wenn ich mich anmelde, kann ich immer wieder mitschicken, ob der Nutzer sich nochmal gegenüber den Authenticator authentifizieren muss. Ob ich das als Pflicht mache, weil wenn der sich nicht mehr authentifizieren muss, dann würde der Authenticator einfach, ohne dass ich es vielleicht mitbekomme oder so, jetzt einfach halt sich mit dem Parskey einloggen. Was dann theoretischerweise passieren könnte, jetzt angenommen, ich habe einen NFC-Passey, also da liegt auf meinem Handy und ich kann mein Parsekey über NFC, also mein Authenticator über NFC aufrufen, dann könnte ich ja theoretischerweise als Angreifer oder Angreiferin auf eine Webseite gehen und einfach so mal ganz kurz ganz nah an meinem Opfer mit dem Handy vorbeilaufen. And when dann halt der Authenticator über NFC quasi zugreifbar ist, dann sagt der Authenticator, okay, cool, guck mal, ich bin doch da, here, ich habe ein Parse Key, okay, ich logge dich jetzt mal ein. Also über dieses Challenge Response Verfahren. Weil halt der Nutzer nicht nochmal bestätigen muss, yeah, ich allow dem Authenticator jetzt diese Challenge zu signieren, quasi mit dem Part, mit dem Private Key, der dem Authenticator liegt. Und das ist, das nennt sich User Verification. Das kann man auf optional setzen oder halt auf Required setzen. Und es ist definitiv zu empfehlen, dass man das immer auf Required setzt. Dann gibt es natürlich auch noch das Problem mit Updates. Ich kann natürlich auch irgendwann auf Serverseite oder soll doch irgendwann auf Serverseite vielleicht obsolete Passkeys quasi löschen. Also, angenommen, jetzt nur ein bisschen sehr hypothetisch, but we have plotted post-quantum computer. Then all Parseys, die with RSA oder elliptische Kurven erstellt wurden, natürlich haben wir ein ganz, ganz großes Problem. Das heißt, I must then server-seitig all the löschen. And I must then, sobald sich the Nutzer versucht anzumelden, can ich eine Whitelist ebenfalls an den Browser senden und den Browser mitzuteilen, Aliber Browser, du darfst aber nur die Authenticator für mich zum Einloggen nutzen. And dann würde halt keiner mit drin stehen. Also in dem Fall, wenn ich alle gelöscht habe, Server-Side, ich würde halt in der Whitelist keinen Authenticator mehr drin stehen. Sprich, demzufolge würde der Nutzer, Nutzerin wieder aufgefordert werden, einen neuen zu erstellen. Aber ich kann dahingehend natürlich diese Passkeys auch whitelisten, welche denn jetzt für die Anmeldung überhaupt verwendet werden dürfen. Auch wenn ich gegebenenfalls schon mal einen Passkey erstellt habe, aber der dann halt gegebenenfalls obsolet ist oder nicht mehr sicher ist.

SPEAKER_01 1:10:12

Ich fand das sehr erfrischend, als du gerade gesagt hast, naja, da gibt es schon so neuere Verfahren und elliptische Kurven und sowas. Wenn man sonst so nur in diesen AI-News hier bei uns sitzt und sich ja quasi alle Monate irgendwie alles über den Haufen wirft, muss man sich jetzt im Security-Bereich einfach mal so zuguteführen, dass elliptische Kurven, ich glaube, aus den 80ern oder den 90ern sind oder sowas. Also die sind jetzt ja auch nicht mehr so Rocket Science oder so, ja. Und trotzdem hat man noch so dieses Problem mit, ja, hoffentlich kommen die bald mal überall an.

SPEAKER_02 1:10:41

Ja, ja, ja, das stimmt. Ich habe, also keine Ahnung, so SSH-Keys mit elliptischen Kurven sind erst so seit ein paar Jahren irgendwie im Rennen. Also es war, also vor sieben Jahren oder so hat jeder noch RSA Public-Private Keys verwendet oder letztendlich verwendet.

SPEAKER_01 1:10:59

Same, ja. Also ich will mich da ja gar nicht rausnehmen, aber ich finde es halt so krass, wenn wir so bei manchen Stellen in dieser Branche irgendwie so jedem Trend hinterherrennen und dann so bei Security, naja, so Kurven, die sind jetzt 30 Jahre abgehangen, es wird Zeit, dass wir die mal benutzen.

SPEAKER_02 1:11:12

Verwenden, ja, ja, absolut. Ja, ja. Ich meine, die große Angst auch mit Post Quantum ist ja, ist ja tatsächlich real. Und da bin ich auch mal gespannt. Dann haben wir ein riesen Problem.

SPEAKER_01 1:11:27

Ja, aber das Tolle ist ja in der Situation, dass da ganz andere Leute noch viel größere Probleme haben. Und das ist das, was mich dann so nachts wieder schlafen lässt, sodass da viel mehr Leute, viel größere Fische im Teich sind, die das lösen müssen und ich dann da einfach auf der Lösung mitreiten kann, hoffentlich.

SPEAKER_02 1:11:42

Ja, ja. Ich meine, man kann auch ganz kurz noch neuere Entwicklungen oder es gibt noch eine ganz große Herausforderung von Parseys. Und das ist quasi das Teilen über Vendorgrenzen hinweg. Also dass ich, ich möchte jetzt einen Parsey, habe ich bei Windows Hello zum Beispiel drin, und ich möchte den Parskey bitte auch auf meinem MacBook verwenden. Es gibt keine Möglichkeit, oder es gab es ja sehr lange keine Möglichkeit, dass ich den da sharen kann, außer ich nutze den Parsey mit einem Passwortmanager, der auf allen Betriebssystemen läuft. Das würde gehen. Das würde natürlich gehen, auf jeden Fall. Aber man arbeitet aktuell tatsächlich gerade an, das nennt sich dann Credential Exchange Protocol, CXP, an einer Art von Protokoll, mit dem ich dann Passeys auch über Betriebssystemgrenzen hinweg scheren kann oder auch exportieren kann. Das heißt, man überhaupt nicht.

SPEAKER_01 1:12:40

Was ja vielleicht auch dieses End-User-Problem löst, dass man mit Parskeys quasi keine geteilten Accounts haben kann. Ich kann dir jetzt nicht einfach mein Passwort geben, damit du nicht da mal irgendwo einloggen kannst.

SPEAKER_02 1:12:51

Ja, jetzt bezeichnest du das als Problem. Es ist ja, ist ja schon okay. Oder andersrum gesagt, es ist ja gar nicht so cool, dass ich jetzt meiner Freundin, mein Freund einfach das Netflix-Passwort in WhatsApp mal eben so schicken kann. Ist ja eigentlich eher was Negatives.

SPEAKER_01 1:13:10

Wenn du Netflix bist, ja, ist das nicht so cool. Aber wenn du natürlich deine drei Freunde bist, die freuen sich natürlich.

SPEAKER_02 1:13:17

Ich habe das auch schon gemacht. Das macht das, ich kenne das. Also es ist alles gut. Also ich habe das zwar nicht über WhatsApp gemacht, aber über einen anderen Kanal oder so.

SPEAKER_01 1:13:26

Über SMS haben wir ja eingangs gehört, dass das der allersicherste Kanal ist.

SPEAKER_02 1:13:30

Ja, ja. Also ich kann das auch vollkommen verstehen. Ich glaube zwar nicht, dass es jetzt mit dem CXP, als mit dem Credential Exchange Format ähnlich leicht wird wie Passwort über WhatsApp, aber es ist auf jeden Fall leichter, jetzt den, wie wir nennst du es mal hat gesagt, den Private Key über von einem Betriebssystem auf das andere Betriebssystem rüberzuschieben. Aber das ist gerade so die nächste Entwicklung, das ist gerade noch so der nächste Standard, weil da ist Apple ein bisschen vorgeprescht. Apple hat einfach irgendwas entwickelt, mit dem es funktionieren könnte. Und Windows und auch Linux haben gesagt: Was willst du denn jetzt? Wir machen erstmal einen Standard, den implementieren wir mal alle zusammen und dann können wir mal darüber reden, dass wir das dann schön alle zusammen und gemeinsam so definieren, wie jedes Betriebssystem es haben möchte.

SPEAKER_01 1:14:30

Ach ja, das ist so die Geschichte des Internets. Irgendeiner baut es halt erstmal und dann wird so geguckt, wie man das standardisieren kann.

SPEAKER_02 1:14:37

Ja, es gab auch einen riesen Artikel, Apple killed Parskeys, weil das dann irgendwie die anderen Vendor, also Vendor wie Windows, die waren dann auch ein bisschen beleidigt, also Microsoft. Es war ein riesen Gezetare. Es war, es war ganz, ganz schlimm. Deshalb bin ich ziemlich glücklich, dass die Entwicklung jetzt kommt, dass man sich auf ein Format, also es gibt ein CXF, das Grid Engine Exchange Format, also das ist halt auch einfach nur ein JSON, was dann halt definiert, quasi, wie halt dann, um es mal so zu sagen, der Private Key dann von einem zum anderen geschoben wird. Und dann gibt es natürlich auch wieder ein cooles Protokoll dazu. Und das wird gerade entwickelt, da freue ich mich tatsächlich drauf. Das ist so ein bisschen dann Zukunftsmusik. Aber da findet gerade die Adaption statt.

SPEAKER_01 1:15:25

Ich fand das so krass, dass du gesagt hast, so man sollte das so alles über einen Identity Provider zu machen. Ich hatte so ein bisschen die Hoffnung, dass es gar nicht so schlimm ist, wenn man das alles irgendwie selber bauen will.

SPEAKER_02 1:15:36

Es ist halt krass, auf was man, was man da halt alles achten muss. Also, wie gesagt, alleine schon, wie du Passwörter abspeicherst. Second Factor, also ich will den, ich will nicht Multifaktor-Authentifizierung selbst implementieren, server-seitig. Also klar, du kannst, und dann machst du automatisch Abstriche, weil du sagst, boah, das ist voll komplex, das lassen wir lieber mal. Oder diesen Verifikationsstep, der die Spezifikation vorschreibt, boah, der ist ja, boah, das ist Holler, die Waldfee, den lassen wir mal weg.

SPEAKER_01 1:16:09

Ja, dann, aber glaubst du, das ist draußen, also ich komme halt, also ich meine, wir sind alle hier schon so ein bisschen länger im Business, ja, und so irgendwie Passwort-Login bauen, das hat ja, also das hat ja niemand früher so ausgelagert, das hat ja jeder irgendwie selber gemacht. Manche mehr schlecht als recht, aber jeder hat das so gebaut. Und sind wir jetzt da schon, dass Leute wirklich dann so, wenn sie jetzt was bauen, sagen, okay, so Identity ist so, das geben wir komplett weg und dann nutzen wir halt nur Okta oder nur Single-Sign-Ist es tatsächlich so, ich bin schon so ein bisschen raus aus diesem Produktding. Deswegen weiß ich nicht, wie das Leute machen, die halt heute auf der grünen Wiese anfangen.

SPEAKER_02 1:16:45

Ja, also ich kenne kaum, ich kenne eigentlich kein Projekt, wo nicht mindestens Key Clock verwendet wird. Also das, man, also ich kann dir gar nicht aufzählen, wie viel falsch man da machen kann. Man muss jetzt nicht Okta für eine Million kaufen mit Enterprise Support. Keychlock ist komplett Open Source. Key Clock ist von Red Hat, das kann man mit einem Docker-Container hochziehen und dann ist und die wissen halt.

SPEAKER_01 1:17:13

Aber sie betreiben es quasi alle oder die meisten dann halt doch irgendwie selbst?

SPEAKER_02 1:17:17

Genau, es ist self-hosted, also du musst es self-hosten. Aber die ganze Kryptografie und die ganzen Verifizierungsschritte und alles Mögliche ist halt in Keychlock drin. Und das, also ich das will man nicht selbst implementieren. Du sagst dann bei KeyClock einfach nur, okay, ich habe einen Nutzer, der hat die Rollen und wenn er auf diesen Service zugreifen will, den ich halt auch kurz bei Key Clock registrieren muss, dann muss er diese Rolle haben und Keychlock stellt mir so ein schönes Access-Token aus und fertig. Und ich will das nicht selbst machen, ehrlicherweise.

SPEAKER_01 1:17:49

Also ich verstehe das voll. Ich frage mich dann bei sowas halt immer nur so: Key Cloak als so Tool, wie sehr kann ich mir damit halt auch irgendwie in den Fuß spawnen, wenn ich es halt irgendwie falsch benutze, weil nur dadurch, dass wir das haben, ist das Problem noch nicht gelöst. Ich muss es ja auch richtig in Anführungszeichen benutzen.

SPEAKER_02 1:18:09

Ja, klar, dafür gibt es dann natürlich die Consultants, die fünf Tage Key Clock-Workshops anbieten und Tagesatz für 5000 Euro haben. Nee, also hast du natürlich recht. Ich würde aber nichts trotzdem behaupten, dass die Konfiguration von Keychlock nicht so viel konfiguriert werden kann, wie du das falsch implementieren könntest, in worst case. Also ich weiß, this is halt in the rich thing, dually implemented a password-hashing self. And this will halt out, daffunce an SDK or so. And gerade by authentifizier and authorisation gibt es halt so viele Schritte. Also, wie gesagt, alleine wenn du irgendwie Singles-N-On haben möchtest, was halt heutzutage der Standard ist. Wenn du sagst, okay, wir haben halt Passworder, du willst einen Second Factor haben. Du willst dann gut biometrischen Second Faktor ist ja meistens dann über dein Client geregelt oder so, du kriegst ja nur gewisse Daten. Aber das musst du ja alles selbst verwalten. Das ist, das, also ja, also ja, es ist halt auch ein bisschen in meiner Bubble habe ich nicht gesehen, dass das jetzt jemand geradezu noch irgendwie selbst implementiert.

SPEAKER_01 1:19:36

Ich hab als Passwörter noch, der heiße Scheiß waren, hab ich auch mal so Systeme gesehen, die dann sowas machen wie, wir speichern zwar dein Passwort nur gehasht, aber in dem Moment, wo du dich anmeldest, haben wir es ja einmal ganz kurz im Klartext und wir nutzen dein Klartext-Passwort, um irgendwie deine User-Daten nochmal zu verschüsseln mit deinem Passwort als Schlüssel quasi. So, damit wir selber nicht mal addressed an deine Sachen drankommen können. Gibt es irgendwie dazu so einen Analog in der Parskey, weil ich bekomme ja eigentlich gar nichts, außer so die Bestätigung, dass du du bist, oder? Ich kann ja gar nicht mehr damit machen eigentlich.

SPEAKER_02 1:20:17

Ja, das stimmt tatsächlich. Ich glaube, sowas hat man dann konkret nicht mehr. Ich muss kurz nachdenken. Wir brauchen ja einfach nur eine Konstante, die nur der Nutzer hat. Das ist ja eigentlich der Punkt.

SPEAKER_01 1:20:31

Und das Passwort bietet sich halt an, weil er es eh übertragen musste, sozusagen.

SPEAKER_02 1:20:36

Und man überträgt ja eigentlich nur noch die signierte Challenge. Von mir ist noch ein paar Metadaten. Noch nicht mal die Authenticator-ID, könntest du verwenden, weil die könnte auch wechseln. Also du hast schon recht, ich glaube, so, das müsste man sich wieder selbst konstruieren. So per se gibt es das nicht mehr. Tatsächlich.

SPEAKER_00 1:20:56

Dave, du wolltest noch eine Frage zu deiner Glaskugel stellen. Genau, und zwar, man hat am Anfang so ein bisschen deine Aversion gegenüber Passwörtern mitbekommen. Und deswegen hier die Frage an dich, ist es für dich so, dass dieses Systempasswort irgendwie kaputt ist und irgendwie in Zukunft komplett irgendwie aussterben wird, dass wir jetzt nur noch dann in Zukunft Passis verwenden oder was, wie sieht die Zukunft für dich aus, was Security angeht?

SPEAKER_02 1:21:24

Ist natürlich eine sehr spannende Frage und hängt natürlich von so vielen Faktoren ab. Das eine ist so ein bisschen, was ich mir wünschen würde, und das andere, was ich aber glaube. Also ich kann mir, also ich würde mir wünschen, dass die Zukunft passwortlos ist. Und dafür steht ja auch FIDO, Fast Identity Online, Passwortless Authentication. Die tun ja, versuchen ja seit über 16 Jahren nichts anderes, als das endlich wahr werden zu lassen. Ich glaube aber, dass so aktuell noch zu viele Nutzer und Nutzerinnen an dieser User Experience kennen und auch dieses, wir machen das schon seit 30 Jahren so, dass ich da mein Passwort eingebe und fertig. Und ich glaube, es braucht vielleicht doch eher so einen neuen Wind. Also ich sag mal, dass vielleicht auch die Entwickler und Entwicklerinnen oder Nutzerinnen, die Passwörter noch erlebt haben, vielleicht auch in Rente gehen, oder halt irgendwie, dass man halt nur noch halt diese Passkey-Era halt letztendlich kennt. Weil es ist halt, Passwörter haben halt den Vorteil, ich kann sie eben mal schnell jemandem geben. Ich schreibe sie auf den Zettel. Oh, ich habe mein Passwort vergessen. Dann schreibe ich kurz, wie es, wie es, ich glaube, das war das Samsung CTO einmal, meiner Sekretärin eine E-Mail und sag, schick mir mal bitte das Passwort über E-Mail. Ich habe mein Passwort vergessen. Und dann wurden die E-Mails leider offen gelegt, durch lustigerweise einen anderen Hack und schon hatte man sein Passwort. War aber auch sehr lustig damals. Und das ist Sony war das, glaube ich, nicht Siemens. Sony war das damals. Genau, ich glaube, Passwörter sind nicht tot zu kriegen in naher, mittelnaher Zukunft. Nichtsdestotrotz bin ich aber überzeugt, dass in längerer Zukunft Pass überwiegen werden und mehr und mehr Leute auch von den Vorteilen letztendlich profitieren werden und es auch merken und deshalb auch Passkis einsetzen werden. Weil ich denke auch, auch jemand, der überhaupt nicht technisch affin ist, nervt es, dass man sich ständig Passwörter ausdenken muss. Deshalb benutzt ja jeder oder jede Anwenderin und Anwender das Passwort immer wieder neu, weil es nervig ist. Also immer wieder für andere Dienste, weil es halt einfach nervig ist. Und dann muss man einfach, glaube ich, noch ein bisschen Aufklärungsarbeit leisten. Vielleicht nochmal so ein paar Sachen standardisieren, wie Passkey, Recovery, wie kann man das machen? Vielleicht auch ohne, dass man unbedingt das mit einer E-Mail verknüpft oder so. Ich glaube, da braucht man noch ein bisschen Aufräumarbeiten, ein paar Fragen müssen geklärt werden. Aber dann sehe ich die Zukunft auf jeden Fall grundlegend passwortless.

SPEAKER_01 1:24:15

Wunderbar. Das wäre fast schon ein schönes Schlusswort gewesen.

SPEAKER_02 1:24:19

Aber.

SPEAKER_01 1:24:19

Aber, Dave, was?

SPEAKER_00 1:24:22

Was haben wir noch? Das Schweinchen des Tages, richtig? Das war? Das Schweinchen des Tages? Achso, Pick of the Date.

SPEAKER_01 1:24:28

Das ist ein bisschen gedauert, ja.

SPEAKER_00 1:24:29

Oh Gott.

SPEAKER_01 1:24:49

So, wie immer haben wir noch ein paar Picks of the Day für euch am Ende der Folge. Und ich sag mal, Dave fängt an, weil er bestimmt WoW Midnight picken will diese Woche. Oh, gar nicht, gar nicht. Ich hab wirklich, ich hab wirklich einmal vorhersagen, was du machst.

SPEAKER_00 1:25:08

Aber guter Gedanke, nee, seitdem meine Schulter wieder funktioniert, habe ich den Weg wieder ins Real Life gefunden und bin komplett raus, was WoW angeht. Erstmals, erstmal. Aber ich habe tatsächlich was anderes, es ist auch tatsächlich ein Game, das ich mitgebracht habe, weil ich es einfach von der Idee her sehr cool fand. Und zwar ist es Reverse Snake. Das ist ein Spiel, das irgendjemand mal entwickelt hat. Und ich fand es vom Gedanken halt sehr cool. Es ist halt also eine Schlange einfach und die Schlange verfolgt dich und du bist der Apfel. Und du musst wegrennen. Und das ist halt irgendwie von der Idee so gut gemacht irgendwie. Und das ist auch schon interessant. Da gibt es verschiedene Level und es wird natürlich immer schwieriger und sowas.

SPEAKER_01 1:25:44

Du bist ja auch immer kürzer.

SPEAKER_00 1:25:47

Also so komplett re war es halt. Ja, weiß ich gerade nicht mehr so aussehen. Ich habe das vor ein paar Wochen immer gemacht und fand es auf jeden Fall sehr unterhaltsam. Also es wird auf jeden Fall merklich schwieriger. Also es gibt verschiedene Level und es wird immer von Level zu Level schwieriger. Und es ist irgendwie schon interessant zu sehen, wie die Schlange dann sich ihren Weg zu dir bahnen möchte. Und das ist gar nicht mal so einfach dann später. Fand ich auf jeden Fall eine super lustige Idee. Ich mag es, wenn man so einen kreativen Twist einfach in irgendwie bekannte Spielprinzipien reinbringt. Und von daher ist das Mind Pick of the Day. Ich fand es sehr, sehr unterhaltsam und lustig. Okay, damit habe ich überhaupt nicht geregelt. Wow Midnight versus Snake.

SPEAKER_01 1:26:25

Triple A-Titel, hunderte Millionen. Nein. Beides, wir spielen. Beides Triple A.

SPEAKER_02 1:26:31

Aber FSK 18, weil das tot alles.

SPEAKER_01 1:26:37

Jetzt hätte ich bei Martina schon fast gesagt, so mit dem Hintergrund, das muss irgendwas mit Pokémon sein, bietet sich auch diese Woche an, aber ich traue mich jetzt nicht mehr, nochmal einen Forecast zu machen. Deswegen frage ich einfach, was hast du als Pick of the Day dabei?

SPEAKER_02 1:26:48

Das stimmt, es ist natürlich ein bisschen zu einfach und ich habe natürlich Pokémon schon durchgesuchtet, aber mein Pick of the Day kam zu einer ähnlichen Zeit raus, denn ich liebe Horrorspiele.

SPEAKER_01 1:27:02

Es gibt noch Pokémon. Nein.

SPEAKER_02 1:27:04

Als damals Silent Hill F raus kam, habe ich das durchgesuchtet. Und jetzt kam aber gerade Ende Februar das neue Resident Evil raus.

SPEAKER_00 1:27:15

Requiem.

SPEAKER_02 1:27:16

Ja, was ich halt jetzt tatsächlich mir teilweise vorher schon Let's Plays und die Spieldynamik. Und das ist ja ziemlich cool. Also Resident Evil ist hier so Zombies und man knallt die ab und das ist so ein kleiner Background-Story. Man muss immer Töchter von irgendwelchen Präsidenten retten und so. Und diesmal ist es halt so, dass man zwei Charactere immer wieder abwechselnd spielt, was ich super spannend finde. Was mir aber so ein bisschen Probleme macht. Weil so the one character, this is Tisa Leon, this is the hauptcharakter, and mitem kann man rumballern und Zombies töten. And with the other character, this is quite so eine FBI-agent, mit der man dann. Grace, genau. And die hat halt nicht so viele Ressourcen, und mit der Schwester, der hat sich das nicht mehr Da muss man immer schleichen und vorsichtig sein. Und also Ressourcen mit, man hat nicht so viele Patronen, man hat nicht Waffen und keine Ahnung. Und ich bin so schlecht im Ressourcenumgang. Wenn ich irgendwas sehe, will ich immer draufballern und es einfach nur töten. Ich bin halt nicht so die Versteckerin und vorsichtig und Geduld haben und sorgfall, das ist nichts für mich. Deshalb ist das ziemlich herausfordernd. Aber macht Spaß bisher, auf jeden Fall.

SPEAKER_00 1:28:27

Ich finde es, by the way, also ich habe es mir auch sofort geholt. Ich würde sagen, ich bin Resident Evil Ultra, also jeden Teil so vor dem Messentag gespielt. Und ich muss sagen, die kriegen das erstaunlich gut hin. Dieses, weil, also die Serie war damals Horror, dann hat sich in eine Action-Richtung bewegt und ist dann wieder zu Horror zurückgekommen. Und die haben jetzt beides kombiniert, diese Action-Reiche und dieses Horrorartige. Und das ist halt wirklich super gelöst durch diese zwei Charaktere, die in einem ähnlichen, in ähnlichen Räumen halt sind. Und irgendwie ist das so gefühlt, wenn du Leon spielst, so jagst du die Zombies und wenn du Grace spielst, wirst du von den Zombies gejagt. Und das ist irgendwie kriegen das wahnsinnig gut hin. Also wirklich Hut ab.

SPEAKER_02 1:29:02

Ja, ja, und das Coole, aber noch im Einsatz sozusagen, was ich besonders cool finde, ist, man stellt sich das vielleicht erstmal voll schlimm und langweilig vor, dass du denselben Weg zweimal abgehst. Also, und ja, am Anfang ist es so, er ist er in so einem Krankenhaus und dann geht die Craze erstmal vor und danach kommt der Leon nach. Und die laufen schon teilweise dieselben Wege, aber das kommt einem nicht so vor. Weil man halt ganz anders, man muss halt mit der Craze vorsichtig sein und sich verstecken und man läuft ganz anders oder man erkundet das ganz anders. Und mit dem Leon geht man einfach durch und ballert alles ab. Da kann man dann endlich die dummen Zombies, die einen gejagt haben, dann einfach abknallen. Also das ist nicht so monoton, wie das erstmal klingt. Das finde ich halt super cool, was sie da kreiert haben. Also ja, ich bin noch nicht so weit, ehrlicherweise, weil ich natürlich die Zeit lieber mit euch in einem Podcast verbringe, als jetzt Resident Evil zu spielen, aber wahrscheinlich heute Abend werde ich mal wieder ein bisschen reinschauen.

SPEAKER_01 1:30:01

Wunderbar. Ich habe noch einen ganz kleinen Pick of the Day dabei. Und zwar hatten wir uns hier vor ein paar Wochen alle so ein bisschen sehr intensiver mit Open Claw beschäftigt und irgendwelchen komischen AI-Agents, die Amok laufen können auf deinen Kisten. Und ich dachte, ich mache das sehr vorbildlich und ich installiere den hier bei mir auf so einem eigenen kleinen Mac Mini, den ich noch rumliegen hatte, und irgendwie alles schön isoliert und abgekapselt und so. Und dann habe ich so ein bisschen Panik bekommen und dachte, okay, aber der muss ja auch in meinem Netzwerk. So, weil der muss ja ans Internet irgendwie so ran. Und das war mir irgendwie auch schon zu viel, den überhaupt nur in meinem Netzwerk zu haben, weil ich hab ehrlicherweise, also ich hab so ein Anti-Zero-Trust-Network bei mir zu Hause. Wenn du einmal drin bist in meinem Netzwerk, dann ist alles offen. Da kannst du am Smart Home rumschrauben, unter Medienserver und an der Haussteuerung und so, ist alles egal. Solange du einmal irgendwie physisch Access hast, also Dave, wenn du mal vorbeikommst, einfach Air J45 irgendwo in die Wand, zack, hat immer Guest. Und da ist, okay, nee, niemals kann der hier irgendwie alleine rumlaufen, weil es steht ja irgendwie Tür und Tor offen. Da war so die Frage, okay, wie kriege ich den halt hier irgendwie isoliert? Und ich habe jetzt nicht so einen krassen Unify-Switch oder sowas, wo ich Hardware-V-Lans irgendwie aufmachen kann und das irgendwie auf der Ebene alles trennen kann. Aber dann habe ich ein bisschen recherchiert und was ganz Cooles gefunden, das ist jetzt mein Pick of the Day, lange Vorgeschichte. Wer zu Hause eine Fritzbox nutzt, der kann die Fritz-Box so einstellen, dass der LAN-Anschluss Nummer 4 isoliert von allen anderen Netzwerk-Ports betrieben werden kann. Das ist so Poor Mans V-Netz sozusagen. Du hast genau ein Gerät, was du anschlepseln kannst, was von allen anderen getrennt betrieben wird. Und das habe ich dann genommen und sage so, okay, hier mein Open Clower Mac Mini, der verkabel an dem Port dran und der sieht den ganzen Rest nicht. Ich habe ihn dann wieder mit ordentlichem Zero Trust über Tailscale in mein Netzwerk eingebunden, so, aber da kann ich sehr genau steuern, wo er ran kann und wo nicht. Aber der Hack war erstmal Fritzbox Port Nummer 4 und überhaupt keinen Zugriff auf gar nichts. So, ganz, ganz kleiner Pick of the Day. So Minischwein.

SPEAKER_02 1:32:10

Ist aber auch sehr vorbildlich, weil die meisten hauen einfach Open Claw ins Netz und dann go for the.

SPEAKER_01 1:32:17

Die allermeisten installieren das wahrscheinlich einfach schon mal auf ihre eigenen Kiste.

SPEAKER_00 1:32:20

So, da fängt es ja schon mal an. Ich habe auch gerade schon gesagt, Martina, so als Security-Profi hier und du hörst direkt so Open Claw nicht so, oh nein, oh nein, oh nein, was kommt jetzt, was kommt jetzt?

SPEAKER_01 1:32:30

Ja, da könnte man eigentlich noch eine ganz eigene Folge drüber machen, wie dieses Experiment gelaufen ist und sowas alles.

SPEAKER_02 1:32:36

Ich glaube, das ist auch super, also ich glaube, das wäre super spannend. Ich würde es mir definitiv anhören. Also jetzt wirklich aufrichtig, ich fände es super spannend.

SPEAKER_01 1:32:44

Ja, vielleicht machen wir das tatsächlich noch. Wir haben so ein paar Leute hier, die damit so rumexperimentiert haben und tatsächlich auch in den verschiedensten Abstufungen. Also ich war, glaube ich, der Allerparanoideste, sag ich mal so. Wir hatten hier Leute, Gareth, ich will keine Namen nennen, Mock, der so auf seinem Desktop einfach drauf installiert, go for it. Dann haben wir Leute, die das irgendwie auf in einem V-Server irgendwie ganz woanders hin installiert haben, so, ja. Und das sind alles sehr unterschiedliche Erfahrungen, die man damit machen kann. Je nachdem, wie viele Daten da drauf sind, ob das deine Kiste ist, ob das Ding Headless läuft, wie isoliert das halt ist, weil natürlich, ohne diese Podcast-Folge jetzt schon zu machen, aber je ordentlich in Anführungszeichen du ihn einrichtest, desto weniger kann er halt am Ende auch tun. Und das ist dann wieder diese Abwägung, was wir vorhin auch schon gehört haben. Security ist immer so dieses Dreieck zwischen Security, Convenience und Kosten und so. Aber ja, also merkt es euch, Fritzbox, Port Nummer 4, wenn ihr irgendwann mal Leute im Netzwerk habt, denen ihr nicht traut, die könnt ihr da gerne anschließen.

SPEAKER_02 1:33:50

Ja, sehr cool.

SPEAKER_01 1:33:51

Sehr cool. Wunderbar. Dann Martina, danke dir für die Zeit, die du dir uns genommen hast, um auf dein Resident Evil zu verzichten für uns anderthalb Stunden. Wunderbar. Danke, Dave, dass du wieder mit am Start warst, jetzt wieder mit vollem Akku. Und wir hören und sehen uns dann nächste Woche im Podcast wieder. Wenn ihr Fragen, Anmerkungen, Kritik, Kommentare habt, dann entweder immer gerne an podcast.programmier.bar oder ihr hinterlasst uns einen Kommentar und einen Daumen hoch in dem Podcast Player eurer Wahl. Einfach in die Shownotes gucken. Und da findet ihr dann schon das Feedback. Bis dahin, ciao, ciao, und bis zum nächsten Mal. Vielen Dank.

SPEAKER_00 1:34:34

Bis dann, tschüssi.

SPEAKER_02 1:34:35

Danke, ciao, ciao.