Deep Dive 207 –

Passkeys mit Martina Kraus

12.05.2026

// Podcast
// Deep Dive 207

Shownotes

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.

Download

/transkript/programmierbar/deep-dive-207-passkeys-mit-martina-kraus

Jan: Hallo und herzlich willkommen zu 1 neuen Deep Dive Folge hier in der programmier.bar. Für euch wie immer hier vor dem Mikrofon einmal der Jan Gregor Imgetriebe. Und mit mir live zugeschaltet aus der Saline in Bad Nauheim ist
Dave: Dave Acker, David Koschitzky. Moin.
Jan: Und immer wenn Dave im Podcast ist, wissen wir, es geht was, Dave?
Dave: Security. Security, Dave. So ist es nämlich. Ich bin hyped, ich bin hyped.
Jan: Wir wollen nämlich heute über ein Security Thema sprechen. Wir wollen nämlich heute über Paskeys sprechen und wie sie sich anschicken, eure eure Passwörter abzulösen sozusagen. Oder andersrum formuliert, euch von Passwörtern zu erlösen, je nachdem, warum man das vielleicht sehen mag, ja. Aber weil auch Daves Security Wissen seine Grenzen hat. Man mag es kaum glauben, aber auch Daves Security Wissen hat seine Grenzen, haben wir uns jemand eingeladen, deren Security Wissen quasi keine Grenzen kennt, so, ja, mal die dachte gleich ganz oben hinzulegen. Wir haben uns eingeladen, Martina Kraus. Martina, schön, dass Du da bist. Hallo.
Martina: Momo. Ja, hallo ihr beiden. Ich freu mich mega. Ich hoffe, ich kann die Erwartung erfüllen, aber das schauen wir mal.
Dave: Hast Du bereits jetzt schon.
Martina: Danke, danke.
Jan: Die richtig harten programmier.bar Fans werden dich erkannt haben, erkennen von der Programmiercon, wo Du auch schon zu Gast warst bei uns im letzten Jahr und auch da schon über Security gesprochen hast. Und ich hab auch gesehen, Du hast also Du hast auch auf der NTJS haben wir auch gesehen über Security gesprochen. Und das triggert erst mal so meine erste Frage, die doch gar nix 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?
Martina: Also zum einen hängt natürlich auch schon der Ort 'n bisschen in der Auswahl zusammen, also wie lange ich da hinbrauch letztendlich. Aber ich glaub, 'n 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 gesponorte Konferenz ist, die leider vielleicht auch die Speaker nur manchmal, 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 hab oder es gibt auch überhaupt 'n Call of Contact, das ist auch etwas, was es in manchen Konferenzen überhaupt gar nicht gibt, ehrlich zu sein. Krass. Und da dann auch sind eigentlich so meine Hauptfaktoren, wie wie warm und willkommen man sich da eigentlich fühlt.
Jan: Also, es kurz zu sagen, Du warst genau richtig auf der Programmierkonten, so. Na ja, okay. Ja, wenn man also jetzt jetzt
Dave: ohne Recklovion.
Martina: Ja, genau, ohne jetzt gleich natürlich Eukonik den Mund zu schmieren. Aber es
Jan: hat mir schon wirklich sehr gut
Martina: gefallen auf eurer Konferenz. Also es war schon, die die Location war so cool. Ich war zwar oben, da war das so den Eck quasi, aber das war Also mir hat's gefallen, also wirklich. Also ich hatte auch, ich hab das damals auch zu eurem Mitarbeiter gesagt, ich weiß leider, dass sein Namen nicht mehr bei der sich den Techsupport gekümmert hat, also mich verkabelt hat und so weiter. Ich hab noch nie sone gute Einweisung bekommen. Also es wurd sich so arg mich gekümmert. Ich fand das so super cool und das sieht man wirklich selten auf Konferenzen. Das ist manchmal auch einfach so, hier aus so dein Mikro steckst Du dir mal selbst an irgendwie. Und also jetzt, wie gesagt, es war war eine sehr, sehr coole Konferenz. Ich hoffe, dass ihr das auf jeden Fall noch mal macht.
Jan: Und wenn Du nicht gerade den ganzen Tag auf irgendwelchen Konferenzen abhängst, was machst Du sonst den ganzen Tag?
Martina: Ich arbeite als ein sogenannter Application Security Engineer und bin da eigentlich relativ hands on bei den Entwickler und Entwicklerinnen dabei, ihre Webanwendungen eigentlich sicherer zu gestalten. Sei es, wir schauen uns mal NIS an oder NIS 2, die OWAS Application Security für Education Standard, also gewisse Standards, halt die Applikationen nach diesen Standards sicherer zu gestalten. Das kann natürlich sein, wir machen einfach nur 'n 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 son bisschen son Steckenpferd bei mir rauskristallisiert und das ist halt Authentifizierung, Autorisierungen in Webanwendungen. Da würde ich mittlerweile behaupten, ist so meine Hauptexpertise, ein bisschen Eigenwerbung zu machen, da kommt auch im April ein Buch raus von mir.
Dave: Oh, spannend.
Martina: Hab 'n Buch tatsächlich geschrieben über genau dieses Thema. In Deutsch natürlich, weil es manchmal 'n bisschen einfacher ist, das ganze komplexe Thema in Deutsch zu lesen. Genau, das das und dahin gehen natürlich auch hier und da 'n bisschen Consultant, also einfach nur mal Man kann mich dann für 'n Tag lang buchen, ich halte Workshops und so in den Themengebieten. Ja.
Jan: Das ist echt auch 'n superspannendes Jahr. Vielleicht müssen wir da mal 'n separaten Podcast drüber machen, wie das so ist, son son Buch in Tech zu schreiben, wo's ja, also zum einen treffen da, glaub ich, so 2 unterschiedliche Welten aufeinander, sone sehr schnelllebige Tech Welt und sone Verlagswelt, die vielleicht nicht ganz dieses Tempo gewohnt ist vielleicht, ja. Und aber auch ist es ja, glaub ich, so didaktisch eine sehr andere Art, irgendwie Wissen zu vermitteln als das, was wir sonst so in in Blogs oder auf Konferenzen oder Youtube oder in 'nem Podcast oder so was machen. Superspannend. Vielleicht kommen wir da am Ende.
Martina: Ende. Ja, klar. Kurz noch
Jan: oder wir haben eine Folge. Grüß Sie.
Martina: Und leider kleiner Funfact, ich musste alles in Word schreiben. Ich konnte nicht oder sowas verwenden. Ich hab eine Wordvorlage bekommen und da musste ich alles reinschreiben. Aber es ging, es war es war schon ganz gut. Also es war ehrlicherweise weniger hustle oder pain, es mal so zu sagen, als gedacht am Anfang.
Dave: Aber krass, war das direkt eine Vorgabe sogar vom Verlag? Mhm. Du musstest das darüber schreiben, ach krass. Ja.
Martina: Ich muss ehrlich sagen, haben 'n 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. Ja. Schön, okay. Ja.
Jan: Wir wollen heute sprechen über Paskys 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?
Martina: Prinzipiell würde ich immer son bisschen den Vergleich mit Passwörtern erst mal ziehen, also eher erklären, wie Passwörter funktionieren, dann bisschen den Vorteil oder darüber dann Paskeys 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 'n bisschen, ich würde dann erst mal natürlich auslassen, dass das vielleicht gehashed sein muss, dass man das nicht einfach in Klartext speichert. Darauf können wir ja dann später noch mal zu sprechen kommen. Aber das ist die halt 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 noch mal drauf sprechen, aber damit würde ich erst mal starten und dass man das halt shad Secret nennt und dass das halt auf 2 Ebenen halt gefährlich ist, weil der Nutzer, Nutzerin muss halt irgendwie dieses Wort, wie gesagt, Passwortmanager wär natürlich das Perfekte, aber die meisten schreiben sich's auch vielleicht auf 'n Zettel. Meine fünfundneunzigjährige Oma hat sich das immer auf 'n Zettel geschrieben. Da kann ich's vielleicht auch 'n bisschen nachvollziehen.
Dave: Klassiker, ja.
Martina: Ach ja, ja. Und aber wie gesagt, das ist auch 'n bisschen außer meiner Kontrolle, weil halt leider auch der Dienstleister das auch 'n Zettel schreiben muss. Wenn wir jetzt zu Passkis kommen, haben wir halt den riesen Riesenvorteil, dass wir selbst Kontrolle 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 zu zu 100 Prozent beweisen kann, dass ich ich bin und das ist kryptografisch abgesichert, ganz ohne, dass ich bei dem Dienstleister mein Passwort oder irgendeinen Chat Secret hinterlegen muss. Und alles, was ich da für diesen Dienstleister geben muss, ist eben einen öffentlichen Schlüssel, ein ein Stück kryptografisches Token könnte man es nennen, 'n öffentlichen Schlüssel. Also ich erkläre das natürlich jetzt sehr oberflächlich, wie jetzt würde ich das meiner Oma erklären. Wir können ja gleich die richtigen Begriffe und alles erwähnen. Und nur mit diesem öffentlichen Stück auf dem Server kann jetzt überprüft werden, dass ich tatsächlich ich bin. Und dahinter steckt natürlich superkomplexe kryptografische Verfahren, aber das macht's halt so viel sicherer, weil ich dieses Shared Secret, dieses Wort nicht aus der Hand gebe. Wenn jetzt jemand die Datenbanken von dem Dienstleister einfach klaut, dann kriegt der nur dieser öffentlichen Schlüssel und mit diesen öffentlichen Schlüsseln kann niemand was anfangen. Man kann mir wiederum verschlüsselte Liebesbriefe schreiben tatsächlich damit, aber sonst kann man damit nichts machen, weil dieser öffentliche Part halt nur dazu da ist, zu verifizieren, dass irgendeine Challenge oder irgendein Text wirklich, wirklich von mir kommt und nicht verändert wurde und manipuliert wurde. Und ich hab die hundertprozentige alleinige Kontrolle über meinen privaten Teil davon, den private Key, wie man ihn nennt.
Jan: Mhm. Jetzt hast Du ja schon so dieses Thema Schlüsselpaare angesprochen. Und ich glaube, das ist so der Punkt, wo der ein oder andere, der so in die Softwareentwicklung gekommen ist, als Quereinsteiger, dann inhaltlich aussteigt. So, also ne, auf 'ner einen, auf soner gewissen Ebene versteht man das so, ne, 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 in die Kryptovorlesung 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.
Martina: Genau, also es gibt, da muss man vielleicht kurz doch 'n bisschen eintauchen, es gibt ja symmetrische und asymmetrische Verfahren. Bei symmetrischen Verfahren hat man bei Verschlüsselung 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 hab 'n Schlüssel und Du hast den aller aller gleichen Schlüssel. Ich verschlüssel das und Du kannst es wieder entschlüsseln. Jetzt ist es halt aber ziemlich kompliziert und schwierig, weil wir ja ein und denselben Schlüssel haben. Das heißt, bevor Du mit mir mit mir reden kannst, muss ich dir diesen Schlüssel erst mal geben. Ja, und das gebe ich dir jetzt unverschlüsselt, da kann ja jeder kommen und den doch irgendwie klauen. Das ist das ist son bisschen risikobehaftet. Was es auch gibt, ist das asymmetrische Verfahren und wie gesagt, nicht zu tief in die Kryptografie eintauchen, aber es gibt einfach gewisse mathematische Probleme. Man nimmt da immer gerne Logarithmen und Modulo, unelliptische Kurven und ganz fancy Sachen. Was 2 Schlüssel miteinander so mathematisch verlinkt, dass wir einen privaten Schlüssel haben können und einen öffentlichen Schlüssel. Und jetzt ist es aber leider so oder es ist einfach nur so, mit dem öffentlichen Schlüssel kann ich verschlüsseln, der hat nur die Aufgabe, dass ich was verschlüsseln kann und mit dem privaten Schlüssel kann ich was entschlüsseln. Das ist schon mal 'n bisschen cooler, weil jetzt, wenn Du mit mir reden möchtest, mir eine Nachricht schicken möchtest, dann gebe ich dir einfach meinen öffentlichen Schlüssel. Aber mit dem öffentlichen Schlüssel kannst Du mir nur irgendwelche Geheimnachrichten schreiben. Du kannst nichts entschlüsseln. Nur ich als wirklich Eigentümerin von meinem privaten Schlüssel kann diese Nachricht entschlüsseln und lesen. Jetzt nutzen wir bei Passkys aber ein anderes coolen 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 erstelle eine Signatur. Das heißt, ich hasche die Nachricht oder irgendeine Challenge, die ich dir senden möchte und 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 gib dir die Nachricht zusammen mit meinem öffentlichen Schlüssel. Und 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 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 der von mir kommen muss. Ich habe mich authentifiziert und da denkt denkt man schon daran, ah, so muss das also irgendwie jetzt zusammenhängen. Der Mechanismus, wenn ich mich authentifizieren möchte mit Parskys. Ich kann ganz einfach mit diesem mathematischen Linking von diesen beiden Schlüsseln beweisen, ich bin ich, weil nur halt der öffentliche Schlüssel, der dazugehört, diese diese Signatur verifizieren kann.
Jan: Okay. Jetzt, wo wir so das Basic Verständnis davon haben, lass uns, bevor wir an die Implementierung gehen, noch ein, 2 Facetten von der von der User Experience vielleicht erklären, ja. Das eine ist, es steht ja immer im Raum, passkeys irgendwie deutlich sicherer als Passwörter, aber am Ende des Tages sind ja passkeys genauso nur in Anführungszeichen ein Faktor, wie Passwörter auch nur ein Faktor sind. Also allein durch die Verwendung von Paskeys führe ich ja keinen zweiten Faktor ein, oder?
Martina: Nein, aber ein zweiter Faktor heißt nicht gleich, dass es Unmengen sicherer ist. Es es gibt schon so viele bestätigte Attacken auf Second Faktor 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 Paskies ist ist halt die Notwendigkeit 1 zweiten Faktor zu haben, braucht man tatsächlich nicht mehr, also tatsächlich vielleicht auch aufgelöst. Warum gelten Paskies als so viel sicherer? Vielleicht auch eine zu eine Frage zurück an euch. Was was nervt euch bei Passwörtern am meisten? Einfach mal so, was was fällt euch ein, was nervt euch an Passwörtern? Fällt euch da direkt irgendwas ein?
Jan: 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 wo teilweise da die Security noch torpediert wird irgendwie durch die Anwendung. Aber ja.
Dave: Ja. Ja, ich würd da gern zustimmen, also Passwortvorgaben, Passwortlänge, dann muss ich irgendwelche 2 Faktor Autorisierungscodes irgendwie aus meiner Mail auch noch mal holen, da bestätigen. Es gibt ja auch Webseiten, da musst Du regelmäßig auch dein Passwort erneuern, damit das irgendwie alle 3 Monate oder 6 Monate irgendwie eine neue ist. Also es Insgesamt muss ich sagen, Security ist leider sehr unsexy, so.
Martina: Ja, also muss aber schon zugeben, ihr seid ja schon 'n bisschen Security versiert, dass ihr sowas sagt wie Passwortmanager. Dann bin ich ja schon 'n bisschen glücklich, ehrlicherweise. Neugierigerweise auch eine andere Frage, bei wie viel, wenn ihr schätzen müsst, bei wie viel Diensten seid ihr eigentlich mittlerweile eingeloggt? Also bei wie viel wie viel Dienste glaubt ihr, haben eine digitale Identität für euch, wo ihr theoretisch ein eigenes Passwort vergeben müsst? Was schätzt ihr so, was was wie viele
Jan: das sind? Ich weiß es, weil ich neulich erst in meinem one Passwort geguckt hab, weil ich was anderes nachschauen wollte und da steht ja immer, wie viele Items da irgendwie drin sind. Aber ich kann ja sagen, das sind Hunderte und erschreckend nah an 1000.
Dave: Mhm. Wow, wirklich? Warte, ich hätte ich hätte so was erst so 30, 40 gesagt. Das ist jetzt
Jan: so meine meine Nummer. Also man glaubt das gar nicht. Aber also ehrlicherweise, ich benutz onePasswort denselben Passwortmanager jetzt auch schon seit also über 10 Jahren so, ja. Und man löscht da ja ehrlicherweise auch nie was raus, ne. Also selbst wenn Du irgendwie 'n Account für irgend eine Mini Pupsanwendung mal anlegst, Du gehst da ja niemals durch und räumst das irgendwie auf. Und ich bin son Datenmessy, ja, und dann hornt sich das halt so bei mir. Absolut
Martina: und das ist einfach so krass. Ich hab das, ich schau mir das auch immer wieder an, mein Passwortmanager, ohne denk mir,
Jan: das ist ja das ist
Martina: ja irrsinnig. Und Wir benutzen Passwortmanager,
Jan: aber
Martina: die meisten benutzen das nicht. Was machen die? Die nehmen überall dasselbe Passwort. Und und das das das ist ein das ist einfach irrsinnig. Klar, weil man will sich das Passwort nicht merken oder kannst sie es nicht merken. Klar, wir haben dann noch sowas wie Single Sign On, wir weil wir auch da 'n 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 kompromittiert ist, sind alle anderen Dienste auch weg im Prinzip. Das ist das ist total total hart, wenn man sich das mal vorstellt und das ist etwas, was Paskey tatsächlich überhaupt nicht hat. Ein zweites Problem von Passwörtern ist, dass ich beispielsweise, also Entschuldigung noch mal zurück zu rudern, ich hab gerade einfach nur gesagt, weil mit Paskeys ist das ist das nicht so. Ich komm gleich dazu, warum das mit Paskies nicht so ist, aber ich würd erst die ganzen Nachteile von Passwörtern auflisten, damit man so richtig Hass auf Passwörter verspürt, bevor wir dann wirklich zu zu Paskies übergehen. Nein, ich mein, was wir bei Passwort dann halt auch haben, Phishing Attacken. Ich meine, es gibt so viel Firmen, die Milliarden für Awareness Trainings ausgeben. Und Awareness Trainings sind wichtig und gut, aber das ist ja, ich muss irgendwie meinen Mitarbeiter, Mitarbeiterin klarmachen, auf den Link darfst Du draufdrücken und auf den nicht. Ich vergleiche das immer mit sonem Haus mit 2 Lichtschaltern und und sag denen, ja bitte, boah, mal bitte erst mal 'n Loch in die Wand. Schau dir mal an, wie die beiden Lichtschalter verkabelt sind, damit Du weißt, auf welchen Du draufdrücken darfst und auf welchen nicht. Und es ist halt im Internet ähnlich irrsinnig. Klar, jetzt jetzt muss man kein Werkzeug rausholen und 'n Loch in die Band bohren, herauszufinden, ob ein Link vielleicht zu der Fishingertage führt oder nicht, aber es ist trotzdem für jemanden, der sich in der Internetwelle erst mal nicht auskennt, ähnlich komplex. Paskeys sind per Design und Spezifikationen, da kommen wir noch phishing resistent. Und und das sind alles Vorteile, die die eben Paskeys gegenüber Passwörtern haben. Das hab ich auch kurz zum Anfang erwähnt, dass wir bei Passwörtern ja, muss müssen wir das Passwort auch zu dem Dienstleister bringen. Das heißt, der muss das irgendwie in seiner Datenbank speichern. Natürlich nicht im Klartext, da gibt's dann kryptografische Hheshes, am besten irgendwas mit Argon2. BCrypt gilt ja auch mittlerweile als nicht mehr so sicher. Aber wir müssen halt vertrauen, dass dass die Webseiten, auf denen wir uns einloggen, dass die unsere Passwörter sicher verwalten und nicht 'n 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 sag immer, wenn ich mich irgendwo auf Kiddycat dot org einlogge, dann dann weiß ich nicht, was die da so mit meinem Passwort machen. Ich wenn ich und wenn ich dann noch dieses Passwort wieder verwende, weil ich halt keinen Passwortmanager habe, dann ist das vielleicht auch schnell leider weg. Und das macht halt Passwörter leider ziemlich anfällig.
Dave: Ich würd gern noch mal kurz auf den Phishing Punkt näher eingehen. Also ich ich fass noch mal 'n bisschen zusammen, damit ich das richtig verstanden habe. Also das Problem bei Passwörtern ist, wir haben dieses Share 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 haben wir dieses Zusammenspiel von privatem und öffentlichen Schlüssel. Dieser öffentliche Schlüssel, der ist auch nur auf mich gültig und mein Privater dann halt, den hab ich persönlich. So. Und jetzt, ich weiß, ist natürlich jetzt 'n sehr hypothetisches Szenario, aber mal angenommen, der öffentliche Schlüssel wird irgendwie geleakt und es wird irgendwie Zugriff auf meinen Computer dann doch irgendwie bekommen. Könnten Angreifer dann mit dem Zusammenspiel doch noch was anfangen? Oder ist es auch da in dem Kontext dann sicher?
Martina: Also wenn es jemand schafft, deinen privaten Key zu stehlen und gleichzeitig auch den von dir hat, dann dann kann man sich theoretisch, man muss noch 'n bisschen was außen rum programmieren. Also es gibt halt 'n gewisses Protokoll, mit dem kommuniziert wird. Das müsste man abbilden sozusagen, aber theoretischer 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 aufm PC rum, der ist hinterlegt in euren Authenticators, in euren TPMs, in dem Security Enklav, in in Windows Hello, in der iCloud Keychain, der ist auf jeden Fall in sicher verwahrt, letztendlich in euren Authenticators.
Jan: Da können wir vielleicht noch mal kurz kurz drauf zu sprechen kommen, was da sicher verwahrt heißt an der Stelle, ja? Wenn wir aus anderen Kontexten diese Schlüsselpaare kennen, dann haben die meisten das ja vielleicht so im in der Verwendung von SSH oder so, ne. Sie wollen sich ja irgendwie auf ihren Server connecten, sie haben da ihr Schlüsselpaar für. Und da ist es ja die gute Security Practice, dass man eigentlich auf jeder Maschine ein eigenes Schlüsselpaar hat. So, ne. Mein Schlüsselpaar ist nicht mir als Person zugeordnet, sondern hier mein Laptop hat ein eigenes Schlüsselpaar, sich zu authentifizieren. Hier mein Handy hat 'n eigenes, mein Desktop Rechner hat 'n eigenes, so. Und jetzt ist es ja bei bei Passkys so, dass wenn ich mich einmal damit angemeldet hab, Du hast grad schon gesagt, so das landet dann in in meiner iCloud oder in meinem Passwortmanager oder so was. Und das sinkt ja wie wild durch die Gegend. So. Und wenn ich wenn ich das so so sehe, dann denk ich mir immer so, aber also wieso ist das so okay, dass wir diese diese Passkys 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?
Martina: Mhm. Das ist tatsächlich eine sehr gute Frage und damit sprichst Du auch 'n kleinen wunden Punkt an. Man unterscheidet bei Parskys in Zink- und Hardwarebound Parskys und dem Nutzer oder Nutzerin es selbst überlassen, wo der Paskey gespeichert ist. Jetzt, wenn wir bei Hardware bound Parskys sprechen, dann könnte es in die Richtung gehen, die Du auch grad gesagt hast, wie's dass ich das einfach nur auf meinem iPhone habe und dann steckt es dort im Security Enklave drin oder es ist nur mit meinem Android Phone in dem TPM oder so. Es kann auch nur auf meinem lokalen Authenticator, je nachdem, was das Betriebssystem für 'n Lokal Authenticator eben anbietet oder ich hab's aufm Yubicki, auf sonem USB Token. Das sind so, das das wär so was, wie Du es jetzt auch gerade beschreibst und das ist tatsächlich was, was eigentlich empfohlen wird zu haben, wenn wir von Passkys sprechen.
Jan: Mhm.
Martina: Jetzt ist es aber natürlich so, jetzt, wenn ich jetzt zu meiner Oma gehe und sage, Oma, hier hast Du son USB Stick, son Paski, er ist, sorry son Juppie, den musst Du immer reinstecken, wenn Du dich jetzt einloggst. Dann sagt sie, checky Shit. Wobei meine Oma ist sehr clever. Ganz ehrlich, meine Oma ist sehr clever, die wird's die wird's auf jeden Fall verstehen. Aber es ist natürlich wieder so U-X-'-mäßig 'n bisschen seltsam. Ja. Deshalb gibt es dieses. Deshalb gibt's die Möglichkeit zu sagen, hey, speicher den, deinen privaten Key und auch 'n bisschen was, ist eigentlich, was man wirklich speichert, darüber kann man auch noch reden, ist eine eine Art JSON, das ist 'n JSON, wohin der hinterlegt ist und noch son paar Meteinformationen. Das das ist, wenn wir sagen, wir speichern den Parskey quasi. Und der kann halt in der iCloud Keychain landen oder der ist irgendwie gesinkt auf jeden Fall. Und damit aktiviere ich natürlich die Möglichkeit, dass ich über Devicegrenzen hinaus diesen Passky gegebenenfalls nutzen kann. Jetzt ist es aber so, hier Du vergleichstest natürlich jetzt mit SSH Zugang auf 'nem Server. Und da sollte jede Maschine ihr eigenes ihr eigenes Paar haben. Mit was wir das aber vergleichen sollten, ist unsere Passwortmanager. Wenn wir, also es sind es sind ja eigentlich unsere Präsentationen für unsere Passwörter jetzt diese Passkeys. Und wenn wir Passwortmanager haben, ich also wo liegt 'n wo liegt 'n die Datenbank vom Passwortmanager? Wo wo liegen denn eure Passwörter? Shared ihr die nicht auch irgendwie? Ist die nicht auch meistens in 'ner OneCloud oder iCloud oder Google Drive? Die Datenbank liegt auch schon in der Cloud und da muss man 'n bisschen aufpassen. Ich weiß, ich krieg da oft oder Paskys kriegen da oft so dieses reingehacke, ja jetzt shared ihr auch in Private Key und das ist ja 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 son 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 Version UX und Performance versus Sicherheit letztendlich. Und wenn wir halt es wollen, dass wir halt, ich bin hab jetzt 'n iPhone, ich hab von mir erst noch 'n MacBook und noch was anderes und wenn ich halt mich überall einloggen möchte, dann habe ich halt 'n Sync Passky. Aber am sichersten wäre, wenn jedes Device seinen eigenen Passky hat für denselben Useraccount, Denn ein Useraccount kann mehrere Passkys registriert oder hinterlegt haben tatsächlich.
Jan: Okay, dann ist das vielleicht jetzt 'n guter Übergang, sich mal son bisschen die Implementierung Gedanken zu machen. Und wir wir steigen einfach direkt ein mit, ich habe hier die programmier.bar Webseite, ich möchte gerne irgendwie User anbinden und die sollen sich gerne per Passki anmelden können so. Was brauche ich dafür, das anbieten zu können?
Martina: Erst mal hängt's natürlich davon ab, was ihr fürn Identity Provider verwendet oder auch Server. Wenn ihr jetzt Angenommen, ihr habt jetzt selbst ein Backend, was irgendwie die ganze Log in Authentifizierung Autorisierung macht.
Jan: Ja, aber Dann ist es fairerweise
Martina: dann ist es fairerweise 'n bisschen bisschen komplizierter, weil dann müsstet ihr eigentlich das Ganze relativ selbst implementieren. Ich würde jetzt erst mal den Weg gehen, dass man Identity Provider hat und und dann später darüber gehen, dass man das alles selbst implementiert, weil da gibt's son paar Feinheiten, auf die man da achten muss. Es Also es gibt 3 andersrum, es gibt 3 Möglichkeiten. Entweder man implementiert alles, alles
Jan: selbst, davon ist eigentlich abzuraten, deshalb
Martina: ist halt die Option bisschen, sollte man auf gar keinen Fall, abzuraten, deshalb ist halt die Option bisschen, sollte man auf gar keinen Fall machen. Es gibt die Option, dass man halt 'n aus der Operation Server hat. Keycloge bietet Passky schon seit Jahren an. Keycloge ist Open Source, hat Passky Support und ich muss mich eigentlich nicht mehr so viel kümmern. Aber auch wenn wir jetzt an andere IDPs denken wie N3D, Google Identity, All Zero, Authentic, Ping Identity, wie sie alle heißen, die haben alle schon Produktionsreifen Parsk key Support. Und was das dann bedeutet, ist eigentlich nur zum Beispiel bei Key Globen no Zero ist es 'n Häkchen, was ich setze. Da sage ich, ja, ich möchte auch bitte Parskies haben. Okay, dann muss man sich, wenn man das aktiviert hat, muss man sich leider ein bisschen Gedanken machen, wie bringe es jetzt den Nutzern bei? Und das ist der kompliziertere Part ehrlicherweise, die Kommunikation. Die das Komplexe ist gar nicht mal mehr so, dass ich das jetzt irgendwie aktivieren muss, weil dafür sollte ich 'n IDP verwenden und die unterstützen ist. Die bieten mir dann dieses diese ganze Kommunikation im Browser an und ich würde auch gerne noch 'n bisschen was zu den Protokollen, die da hin- und herfließen, müssen wir später noch 'n bisschen aufrollen, zu verstehen, warum Paski überhaupt Phishing resistent sind. Aber bleiben wir erst mal so bei der generellen Einzige, ich will's auf jeden Fall einsetzen. Ich brauch natürlich eine Frontend Library, die ich in Projekt, Angular, View, Svelt, Solid, wie sie alle heißen einbinden. Da gibt es aber schon zig Visanter Meer tatsächlich, die ich einsetzen kann, auch Frameworkunabhängig, also auch reine JavaScript Library, die ich dann verwenden kann, den ich lediglich die Anbindung an mein IDP ermöglichen muss. Das heißt, es ist 'n Frontend SDK, was ich dann letztendlich einbaue.
Jan: Aber das ist das ganz normale SDK von dem IDP, also das ist so hier mein Genau. Zero JS oder so was, was ich da da reinsprays.
Martina: Genau, genau. Genau. Das ist das das kann das SDK vom von dem IDP sein. Es gibt aber auch tatsächlich schon, wenn ich jetzt alles selber machen will, gibt's 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 sharen könnt, wo ich dann halt erst mal meine Engelanwendung zum Beispiel einbinden kann und die halt 'n Rapper bildet die sogenannte WebouthN API. Die WebouthN API ist die Javascript API, mit der ich dann Haskys verwalten kann beziehungsweise muss ich ja im Browser etwas haben, mit dem ich dann mit dem Authenticator sprechen kann. Da gibt's son Protokoll, das nennt sich Client to Authenticator Protokoll 2, Seatub 2. Das 2 hat tatsächlich den Hintergrund, aber ist halt die zweite Version davon und dieses Protokoll muss halt vom Browser implementiert werden und das macht diese Webouth 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 sone Art Discovery Schnittstelle von meinem Browser.
Jan: Aber wenn ich da mal ganz ketzerisch einspringen darf vielleicht, also wenn wenn es ja schon diese Webouth API gibt im Browser, die irgendwie JavaScript zur Verfügung gestellt wird, wozu brauch ich denn dann da noch irgendwie 'n SDK oder 'n Library drumrum? Wieso kann ich nicht direkt mit der Browserschnittstelle sagen, so hier, mach mal mach mal Paski jetzt?
Martina: 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 'n gewisses Wissen haben, uns leichterere Funktionalitäten zur Verfügung stellen und vielleicht schon 'n paar Sachen einfach wegkapseln, dass wir nicht mit der Komplexität überfordert sind sozusagen. Also die uns einfach 'n leichteres Interface auch zur Verfügung stellen als diese API letztendlich. Also 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 hab, was ich einfach einbinde und nicht jetzt irgendwie plötzlich mit der nativen JavaScript API, Webport N API kommunizieren muss. Also ist einfach nur eine Brücke oder halt natürlich eine Hilfe auf jeden Fall.
Jan: Okay.
Martina: Und sowas existiert natürlich auch backendseitig. Also es gibt auch für C-Sharp, für Java, für Rust auch Bibliotheken, mit denen ich das sess verwalten kann, sprich, dass ich dann backendseitig kann ich dann validieren, okay, mir wurde zwar jetzt 'n zugestellt, aber gleichzeitig kriege ich auch Metainformationen über den Authenticator. Ich kann backendseitig zum Beispiel auslesen, okay, hier wurde mir jetzt 'n zugeliefert und der Authenticator ist 'n, also 'n, also der ist halt etwas, was in die ICOL Keychain zum Beispiel reingegangen ist und so weiter.
Jan: Und das das bekomm ich mitgeteilt als
Martina: Das sind Metadaten. Ja, das sind Metadaten, die mitgeliefert werden und ich kann natürlich serverseitig sagen, nein, ich erlaube nur Hardware bounded Parskys. Also ich ich will, ich will nicht. Tatsächlich ist es sogar so krass, man kann sich jeder Authenticator hat eine Art ID. Diese ID hat 'n speziellen Namen, der mir jetzt entfallen ist, aber es gibt sone ganz, ganz es gibt halt eine ID von diesen ganzen Authenticator und ich könnte backendseitig eine Art Witelist haben, welche Authenticator wirklich erlaubt sind und welche nicht und die dann recheckten.
Jan: Ist das Was heißt gängige Praxis? Das ist ja alles noch gar nicht so gängig vielleicht. Aber ist das, kommt das vor, dass ich sone so bestimmte Privilegien dann an bestimmte Passkys knüpfe oder an bestimmte Authenticator, dass ich zum Beispiel sage, Du willst dieses Konto, weiß nicht, löschen so, ja? Du willst irgendwas sehr destruktives irgendwie machen. Das geht nur, wenn Du dich angemeldet hast mit 'nem, der halt irgendwie hardwarebount ist, so. Aber wenn Du jetzt nur in dein Konto reingucken willst oder so was, ja, da kannst Du mit Passwort, mit 'nem Sync key, mit was auch immer irgendwie alles ankommen.
Martina: Also in der Authentifizierung, Autorisierung trennen wir das ja eigentlich streng. Also möglich ist es sicherlich wahrscheinlich, aber wir trennen das ja eher. Haskies 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 'n 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, superkomplex, wenn man jetzt sagen würde, okay, die Martina hat sich jetzt mit dem Sync Pasaske eingeloggt, deshalb darf sie nicht das Konto löschen, oh, die Martina hat sich mit 'nem Hardware bounded Paskey eingeloggt, deshalb darf sie das Konto löschen. Also in der Theorie kann man das ja implementieren, ist alles möglich, aber ich glaube, in der Praxis wird man das nie so machen, weil es ja immer, das ist schon immer streng getrennt. Wir sagen einfach, also das ist eine ist Authentifizierung und das andere ist Autorisierung und das ist eigentlich und Paskeys sind reine Authentifizierung. Aber ich mein, auszuschließen ist es nicht, weil zum Schluss kann man das ja alles custommäßig implementieren und die User können natürlich machen, was sie wollen, muss man sozusagen.
Jan: Okay, okay. Okay, dann dann bekomme ich also dieses dieses ganze Paket zurück. Was mache ich damit?
Martina: Also als Server bekommst Du jetzt oder als Klein.
Jan: Genau, nein, nein, als als Server, so genau, ne? Hat's jetzt der Benutzer hat sich jetzt angemeldet. Was davon muss ich irgendwie aufheben? Wie gehe ich jetzt damit quasi weiter
Martina: Genau, also Du brauchst eine Datenbank. Du brauchst eine Datenbank, wo Du halt jetzt letztendlich den Public Key reinspeicherst, zusammen mit den Metadaten, weil das könnt ja auch sein Also wir wir 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 'n bisschen was anderes. Weil bei der Registrierung wär ja quasi der Part, wo der Webserver sagen könnte, er akzeptiert diesen Authenticator, er akzeptiert diesen 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 lieply key letzten Endes speichern zusammen mit den Userdaten.
Jan: Und den kann ich aber, Keyverfahren sei Dank, einfach im Klartext bei mir in die Datenbank werfen. Da muss ich quasi keine besondere Public Forschung mehr treffen.
Martina: Genau und Public Key ist eigentlich relativ, was heißt egal, aber ja eigentlich schon. Relativ.
Jan: Und dieser dieser Public Key, den ich bekomme, der wird quasi für mich als Webseite, als Plattform quasi neu kreiert. Das heißt, der 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.
Martina: Jein, also ja und nein. Wir können ja, also was passiert eigentlich bei der Registrierung? Wir können ja mal diesen kompletten Flow doch durchgehen, bevor wir direkt schon im Backend gelandet sind. So, was passiert? Wir besuchen eine Webseite. Ich möcht mich da registrieren. Ich mir wird angeboten, Paskey Registrierung. Okay, ich klick da drauf, Paskey Registrierung. Das geht natürlich, kann natürlich auch schon eingeloggt sein mit 'nem Passwort und kann dann auf ein Button klicken, registriere ein Paskey. 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 Webouth N API, das erst mal herausgefunden wird, Discovery, was gibt es denn für Authenticators? Wo kann ich ein Parskey erstellen? Und das ist sone create Funktion nennt sich die und dieser create Funktion und das ist ganz wichtig, muss ich sone 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 ein einmaliges Token kreiert mit 'ner gewissen Entropie, dass das nicht erwartbar ist und so weiter und so fort. Okay, das das geht jetzt über diese WebBotn API, über dieses Client to Authenticator Protokoll zu dem Authenticator, den der Nutzer vielleicht ausgewählt hat. Es kann ja sein, dass ich 2 UP Keys angesteckt habe und dann sage ich, ah, nee, ich will den aber hier auf den UP Key erstellen. Was passiert in dem Authenticator? Der Authenticator muss fido twwo really sein. Fido twwo ist ist quasi die Technologien, die dahinter stecken Und dann erstellt mein Authenticator dieses Schlüsselpaar. Einmalig, einmalig spür und das ist ganz wichtig, dieser Origin. Für diese Origin und es wird mitgespeichert als Metadaten, eben eben wird jetzt dieser erstellt und noch 'n paar Metadaten wie zum Beispiel die Origin. Jetzt signiere ich als Authenticator diese Challenge, die mir gesendet wurde mit dem private Key. Ich signiere also diese Challenge. Was jetzt zurück an den Server geht über den Browser natürlich, das heißt Authenticator spricht wieder mit dem Browser und sagt ja, hier, danke für die Anfrage, ich hab dir jetzt was erstellt. Hier hast Du eine signierte Challenge und den. Der Browser schickt beides an den Server. Der Server kann überprüfen, ob er diesen Authenticator erstellten Passkey akzeptiert, ja nein, das ist da, wo wir gerade auch schon waren und und würde dann die Challenge natürlich validieren, also die Signatur validieren, weil sie ist ja signiert mit dem public key. Und wenn ich diese Challenge erfolgreich validieren kann, dann weiß ich ja, dass das der public key ist zu dem private Key, der diese Challenge signiert hat. Also alles gut. Ich speicher es jetzt. Super, Passkey registriert. Jetzt logge ich mich ein und es wird jetzt keinen neuen erstellt, sondern was beim Einloggen einfach nur passiert ist, dass der Server wieder sone Challenge erstellt und über dem Webbrowser an den passenden Authenticator diese Challenge Challenge schickt. Dazu passiert in den meisten Fällen noch wieder ein Auswahlfeld. Also der die der Browser über die Webbot NAPI discovered wieder alle alle Authenticators, die für diese Origin und das ist jetzt der wichtigste Schritt. Wer wer wer hat Pascies für diese Origin? Wie ist son Broadcast eigentlich? Hey Leute, ihr seid ja alle Authenticators, die grad da connected sind. Wer hat für diese Origin 'n Passkey? Und dann melden Sie sich vielleicht 'n paar, weil ich kann ja wie gesagt für eine Origin mehrere Parskys theoretischer Weise haben und dann kann ich auswählen, okay, ich hab jetzt gerade 'n UPi Key, ich ich möchte jetzt, dass der Parsky erstellt wird, sorry nicht erstellt wird, Entschuldigung genutzt wird, den ich auf diesen UPi Key erstellt habe. Dann wähle ich das auch als Nutzer, es geht wieder zu meinem Authenticator. Im Authenticator liegt ja 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 Heat, den er in der Datenbank ja sowieso schon gespeichert hat, zu nutzen, diese Signatur zu überprüfen. Und damit weiß der Server, coole Sache, das ist der Nutzer. Es ist der Nutzer Herbert, den habe ich hier schon oft gesehen, den lassen wir jetzt mal rein.
Jan: Okay, das hat aber, glaube ich, meine Frage nicht beantwortet oder ich hab's nicht mitgehört.
Martina: Okay, Entschuldigung.
Jan: Alles alles alles gut, wir haben uns einfach missverstanden. Der public key, den der Herbert an den Server schickt, ist der wird der pro Origin quasi neu erzeugt oder hab ich auf meinem oder bringt der Ubi Key so eine Identity zum Beispiel mit, bringt mein Authenticator eine Identity mit, die dann immer verwendet wird, mich bei allen möglichen Plattformen anzumelden. Also meine Frage zielt eigentlich son bisschen darauf ab, wenn ich jetzt mehrere Plattformen betreibe, ja? Ich bin ich bin Facebook und ich hab hier Instagram und Whatsapp und und keine Ahnung, irgendwie alle. Und Du meldest dich bei jedem Service einzeln an. Könnte ich über den merken, dass Du immer dieselbe Person bist, weil Du mir jedes Mal denselben schickst? Mhm. Oder wird quasi der für jeden für jeden Fall neu erzeugt?
Martina: Immer dann, wenn ich, also es kurz zu machen, es gibt immer einen neuen Parsky für jede Origin. Wenn ich mich wenn ich mich auf Facebook mal eingeloggt habe und sage, edda ein Passkey, wird ein neuer Passkey erzeugt, ein neues private public key. Wenn ich dann auf Google gehe und sag, leg mir ein Passkey an, wird auch 'n neuer Passkey erzeugt, public private key. Und das ist auch der Punkt, Passwörter können stern re use, Passwörter können immer wieder verwendet werden. Passky ist lautspezifikation und designtechnisch unmöglich zu wieder zu verwenden. Das geht nicht. Also ich melde mich dann immer wieder mit dem Passky bei derselben Origin ein. Also ich verwende den immer wieder denselben private Key, diese Challenge zu signieren, aber ein Passky zu registrieren erst mal, er wird komplett neu erstellt. Also es ist 'n ganz anderer, ganz anderes public private Keeper und genau deshalb sind de facto können Parskys nicht wiederverwendet werden. Es kann, also ich kann natürlich, wie bereits gesagt, ich kann auf Facebook dot com mehrere Parskys hinterlegen, weil ich ja vielleicht einen Hardlet Bounded Passky hab mit dem Yupy Key. Vielleicht hab ich in der, hab ich vielleicht auch auf einem Smartphone noch 'n Passky, aber die werden auf keinen Fall wiederverwendet. Also eine Origin kann mehrere Passkys haben, ein Passky ist immer streng gebunden an eine einzige Origin. Was mich jetzt ganz kurz, wenn wir darüber nämlich schon reden, zu den Phishing Attacken bringt.
Jan: Mhm.
Martina: Es ist unmöglich, dass ich eine URL habe und darauf klicke und dann den dafür verwende, ist unmöglich, weil der der Authenticator und die Web API checkt ja ganz genau, dass das nicht dieselbe Origin ist.
Dave: Ja. Also
Jan: Also wenn unmöglich im Sinne von, solange Du deinem Authenticator vertraust. Ja, weil der ist ja derjenige, der das am Ende sicherstellen muss, ne?
Martina: Tatsächlich ist es die Webout N API, also ja, beides, also ja. Also, wenn ich jetzt die Webout N API schickt ja quasi diese Broadcastnachricht, sag, hey, ich hab hier Facebook dot com, Origin, wer hat alles Passkeys für mich und die Ja. Ja und klar, 'n Authenticator meldet sich dann oder meldet sich dann nicht. Das heißt, es sind beide Parteien in dem Sinne, aber Also den vertraue ich mehr als als so manchen Nutzern oder Nutzern
Jan: Nee, alles nicht. Ich wollte auch gar nicht unterstellen, dass jetzt irgendeiner von denen Schindlutertreibt. Ich wollt 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 diese Implementierung, so, ne. Und da kann ja immer auch mal, also von Vertrauen ganz abgesehen kann man einfach 'n 'n Fehler drin sein, so. Aber Also ich mein
Dave: Martina korrigier mich gerne, falls Du's dir falsch liege, aber mal angenommen, mein mein mein Tool meldet sich jetzt, also web und und gibt das, also versuch dieses Rätsel zu lösen, dann bringt das doch eigentlich in dem Kontext trotzdem nichts, weil für die reale Webseite, für die ich halt gefischt werden sollte, fehlt ja trotzdem der oder an der Stelle? Also es sollte dann trotzdem nichts bringen, selbst wenn er sich fälschlicherweise meldet. Hab ich das richtig verstanden?
Martina: 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 Ich muss Sag's
Jan: nicht so oft, sonst passt dein irgendwo nach wie. Nee, nee, nee,
Martina: nee, nee, alles gut. Ja. Du hast vollkommen recht.
Jan: Ach, cool.
Martina: Ja. Ja. Nee, nee.
Jan: Okay, jetzt jetzt, wo wir diese den den durchgespielt haben so, ja, wie läuft hier die Anmeldung und die die Registrierung ab, gibt's da vielleicht noch den ein oder anderen Edge Case, den man aus Betreibersicht sich irgendwie mal anschauen müsste und gucken müsste, ob's da Probleme geben würde, wenn ich jetzt auf migrare migrieren will? Wie sind denn so Sachen wie, weiß nicht, Account Recovery, Passwort Reset, also keine Kunden hätten. Und wenn jetzt wenn jetzt der Herbert von eben ankommt, sagt, ich kann mich nicht mehr anmelden, ich hab meinen Ubi Key verloren, ich hab 'n neues Handy bekommen, wo meine Equreditials raus sind, keine Ahnung. Was mache ich denn jetzt so? Wie aufgeschmissen sind denn Leute, wenn eben die Parskys mal abhandengekommen sind?
Martina: Ja, das ist natürlich immer den Part, über die man nicht gerne redet, wenn man gehypt ist von 1 Technologie. Deshalb bedank ich mich, dass ich eingeladen war und ich Nein. Nee, also natürlich, auf jeden Fall gibt's auch bei Paarskies 'n paar Probleme. Also zum einen ist das BSI die Ecke gekommen und hat gesagt, dass gefährlich sind, nutzt sie nicht. Das BSI empfiehlt nur Hardbourne und Pass Keys. Dann haben wir schon das kleine Problem, dass ich nicht jeden Nutzer, Nutzerin auch zutrauen möchte, jetzt halt sich das ist das ist 'n UX Overhead, da wird niemand jetzt, das ist supernervig. 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 'nem Arzt tatsächlich. Also oder mit 'nem Arzt, der auch in der IT beschäftigt ist oder sich da auskennt zumindest. Ja, aber ein anderes großes Problem hast Du natürlich angesprochen, Account Recovery und Passwort und Reset von 'nem Passki. Klar, Du hast jetzt hast jetzt einfach nur 'n Hardware boundet Passky aufm Smartphone und wenn dein Smartphone verloren ist, ist das eigentlich ähnlich wie mit dem zweiten Faktor, dann hat man erst mal 'n Problem tatsächlich. Das ist weg. Du kannst dich dann erst mal nicht einloggen. So, jetzt gibt es die Seite von von Entwicklern oder Entwicklerinnen und auch die Fidu Allianz, die hinter Parsky Entwicklung steckt, die halt sagen, ja, zu jedem wichtigen Account solltest Du halt deshalb mehrere Parskis hinterlegen. Am besten tust Du bei jedem wichtigen Account ein Ubi Key nehmen und kaufen für 200 Euro. Ich glaub, so teuer sind sie nicht, aber die sind natürlich auch schon 'n bisschen teurer und halt für jeden Account halt son hardwarebasierten Ubi Key halt hinterlegen Und die legst Du dann in Tresor, weil dann hast Du das Problem natürlich nicht, weil wenn dann dann irgendwas verloren geht, dann kannst Du dein Ubi Key noch einschließen.
Jan: Also ich muss auch sagen, so hab ich das gemacht. Ich hab, warte mal, was hier?
Martina: Ich hab
Jan: hier meinen meinen Ubi Key an meinem Keychain so, ja? Und ich hab Oh, Austerhstall, der Du dich jetzt natürlich nicht in der Kamera zeig, meinen zweiten Ubi Key. Und jedes Mal, wenn ich den einen Ubi Key irgendwo registrier, registrier ich den anderen halt auch gleich mit. So. Ja. Weil den einen hab ich immer bei mir, den kann ich rein theoretisch verlieren. Der hängt am Schlüsselbund, der kann kaputtgehen, runterfallen, kann auch wenn diese Dinge eigentlich unzerstörbar sind so, ja. Aber also genau das mach ich und ich muss sagen, ich würde mich schon als son bisschen security affin bezeichnen. Und selbst für mich ist das 'n so irgendwie mit 2 Kies zu hantieren. Ja. Ja. Und wenn ich jetzt an an meine Eltern denk oder so, ja, denen dann sagen, okay, übrigens, das ist jetzt dieser USB Stick, den benutzt Du irgendwie jedes Mal, wenn Du dich anmeldest. Und übrigens, hier ist noch 'n Zweiter und mit dem machst Du die ganze Arbeit bitte noch mal. So und pass bloß auf, dass Du dir nicht am selben Ort aufbewahren und Also das ist ja eigentlich realitätsfern, so, wenn man nicht so paranoid ist wie wir.
Martina: Ja, ja, absolut. Genau und das und das finde ich auch so erschreckend, dass das so manchmal als offizielle Empfehlung gegeben wird, wo ich denke, das ist nicht Realität, ja, das ist nicht realitätsnah. Ich mein, letztendlich ist es noch 'n ungelöstes Problem oder Herausforderung, jeder muss mit 'ner Art Custom Lösung daherkommen. Also es viele, was ich schon gesehen hab, viele Unternehmen machen dann auch einfach 'n one time Magic Link sozusagen, der auf eine E-Mail-Adresse zugesendet wird. Also, dass ich dann mich darüber, also Recoveryy Strategien, die wir auch schon bei Passwörtern gesehen haben. Mhm. 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 wenn man so sagen kann, wo halt dann dem Nutzer wirklich gehört, wo ich dann vielleicht auch 'n one time Passwort vielleicht, 'n 0TP oder so was halt hinchecken kann, halt irgendwas, womit sich der Nutzer dann halt einfach noch mal authentifizieren kann.
Jan: Vielleicht da auch noch eine Rückfrage. Das geht ja grade son bisschen davon aus, dass Du meine E-Mail-Adresse quasi schon hast, ne, jetzt son Recoveryprozess 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är ja son bisschen sehr trivial irgendwie, ja. Aber das ist ja fürn Passki eigentlich nicht notwendig, oder? Das heißt, wenn ich mich anmelde bei Programmier Punkt bar und sag, ich will 'n Passki nehmen, dann zwingt mich als Plattform Plattform ja niemand erst mal dazu, die E-Mail-Adresse mitzuerfassen,
Martina: oder? Ja, absolut richtig. Ist per Spezifikation auch nicht notwendig, aber macht halt oder den Reccover, wie's sind, Mechanismus, das muss
Jan: Genau, aber ich muss es halt so mitdenken. Ich krieg's nicht mehr so als Benefit automatisch mit. Ich muss Ja. 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 so was alles.
Martina: Genau, genau. Und das das ist halt von mir aus das, was jetzt halt noch 'n bisschen schwierig ist, weil es gibt keine strategisierte Lösung dafür. Jeder macht's halt irgendwie son bisschen wie halt halt nicht immer Custom Lösungen, aber und man nimmt sich halt Hilfe aus den bekannten Szenarien oder wie Coverway Strategien, die man halt per Passwort dann letztendlich schon hat. Aber klar, man braucht man braucht plötzlich Dinge dann doch wieder, die man ja eigentlich laut Spezifikation nicht mehr braucht. 'N anderer, oh ja, sorry.
Jan: Nein, mach ich erst mal deinem deinem Ja.
Martina: Fertig. Ich ich wollt ich wollt 'n zu 'nem neuen Punkt gehen, deshalb kennst Du gerne.
Jan: Ich auch, aber dann nehmen wir deinen zuerst, das ist schon besser.
Martina: Ja. 'N Punkt, 'n Hauptpunkt ist natürlich die Adaption der Nutzer und Nutzerinnen. Also man muss halt natürlich klarmachen, dass jetzt Passkys vielleicht cooler sind. Und das kann man natürlich jetzt tun, indem man euren Podcast anhört zu Passkys, 'n bisschen versteht, wie
Jan: Immer die richtige Lösung. Ja. Auf jedes Problem, einfach programmier.bar hören.
Martina: Ja, wie Paarskys funktionieren, aber es ist halt schon 'n komisches Gefühl. Also ich hab ja anfangs son bisschen gescherzt mit, oh ja, Kiddy Cram und den trau ich meinen Passwörter nicht und keine Ahnung, aber wenn ich auf Kiddycrime dot org gehe, auf Registrieren klicke und plötzlich meldet sich mein Authenticator, mein meine iCloud Keychain und sagt, oh ja, okay, hier bitte macht das mal, dann dann fühlt sich das nicht so gut an. Zumindest wenn ich keine Ahnung hab, was da eigentlich passiert halt hinten dran, dann ist es ja auch wieder 'n Bruch in der UX, dass ich geh plötzlich vom Browser irgendwie weg, 'n anderes Fenster öffnet sich. Das sind, muss ich fairerweise zugeben, ich bin keine Yüxlerin und Uilerin. Ich mir ist das eigentlich egal, ob sich da jetzt 'n anderes Fenster öffnet oder nicht, aber ich kenne viele Leute, die stören sich daran.
Jan: Mhm.
Martina: Und das das ist eigentlich so das hauptsächliche Problem, lustigerweise gar nicht so die Technologie hinten dran, 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 noch iCloud Keychain und ihr könnt es einfach benutzen. Aber auch das fühlt sich natürlich komisch an, auch wie son kleiner Kontrollverlust. Ja. Weil beim Passwort geborene ich's ja immer noch selbst ein und ich hab 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 Webport n API angeboten wird in den Webbrowsern, dass ich zumindest beides gleichzeitig verwenden kann.
Jan: Also es gibt die Möglichkeit, dass
Martina: ich son Input Feld habe und wenn ich da reinklicke, gibt's son Autofill Feature. Das ist tatsächlich so ein Web of n Attribut an meinen Inputs und dann bekomme ich auch automatisch hinten dran vorgeschlagen, wenn ich ein angenommen, ich hätte 'n Paski für diese diese Origin, also für die Webseite, dann kann ich das auch sofort Auto füllen. 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 son bisschen Unterstützung, damit die Adaption 'n bisschen attraktiver ist tatsächlich.
Dave: Ja, ich finde das interessant. Ich hab 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 ist natürlich jetzt nicht irgendwie hard bount an der Stelle, aber dann so vor dem, hey, nutz doch mal Paskys, Du musst dein Passwort nicht eingeben. Wo ich so, oh, nervt nicht. Und dann hab ich mich damit auseinandergesetzt und muss sagen, also das ist ja superspannend, die Technologie dahin und wie sehr mir das alles so vereinfacht. Also ich find's halt irgendwie schon geil. Aber trotzdem eigentlich, weil es bei mir so aus 'nem Nervpunkt heraus. Und ich glaub, Du hast da echt voll das Thema angesprochen, diese mentale Barriere, die man da irgendwie durchbrechen muss, ist, glaub ich, so wirklich 1 der der der größten Aufgaben, so diese Akzeptanz dafür zu schaffen. Weil ne, eben auch dieses so, okay, am Ende hab ich ein Passwort und das ist nur in meinem Kopf und keine Maschine kann mir irgendwie was wegnehmen. So, das ist das Einzige, was ich habe. Und von daher dieser diesen Ansatz, den Du am Ende gesagt hast, dass man beides hat, ne, Du hast 'n Passwort notfalls, mit dem Du dich auch sowieso anmelden kannst ohne mal Passkis. Ich glaub, das ist 'n sehr guter, irgendwie sone sehr gute Abwägung, von wegen, lass mal bitte in die Richtung von Passkis eine Transition machen. Also ja. Vollvallieder Punkt.
Jan: Aber geht euch das auch so? Also ich beobachte Paskeys in the wild ja tatsächlich eher so als zusätzliche Option. Aber ich seh es ehrlicherweise noch sehr selten bei soner initialen Registrierung. Also ich hab's meistens eher so, lege ich hier dein Konto an, E-Mail-Adresse, Passwort und dann kommt so im nächsten Schritt, hey, willst Du auch gleich irgendwie 'n Paskey mit hinterlegen? Aber ich hab, also ich müsste jetzt hart überlegen, aber ich glaub, ich hab noch nie irgendwie so als primäre Option gesehen bei der Account Erstellung, jetzt hier direkt mit Paskey und und. Ich glaub, oder?
Martina: Ich glaube, das ist sone Wahrnehmungssache son bisschen, aber ich hab auch, weil ich auch son bisschen, ich hatte die Zahlen nicht im Kopf, aber ich hab 'n paar Zahlen mitgebracht, son paar Statistiken bezüglich der Verbreitung und Adoption, weil ich das auch superspannend fand und Stand Mais Stand Mai 20 25, das ist zwar jetzt schon wieder 'n bisschen her, aber das fand ich trotzdem spannend, sind 69 Prozent der Nutzer haben mindestens ein. Und das fand ich schon
Jan: Das ist ja krass.
Martina: Das fand ich superkrass. Ich kann auch die Statistiken, ich ich schick die euch, ich schick die euch, dann könnt ihr die, dann könnt ihr die natürlich verlinken, weil ich hau ja jetzt irgendwelche Zahlen raus.
Dave: Genau. Wir glauben dir mal.
Martina: Ja, ja, genau, genau. Und das das fand ich schon ziemlich krass, aber auch
Jan: Diese Erhebung wurde gesponsert von der Fido 2 Alliance, so.
Martina: Also ja, die ist von der Fiido 2 Alliance, muss man das ja jetzt auch sagen. Aber das heißt ja nicht, dass sie falsch ist.
Jan: Ja, genau. Die heilt den Hallen, so.
Dave: Die wissen ja, was
Jan: da abgeht, genau. Also
Martina: Aber aber aber die haben sie auch begründet, weil im Mai 20 25 wurde Microsoft oder hat Microsoft Passky zur Standardanmeldemethode halt quasi für alle neuen Microsoft Konten halt eingeführt Und wenn Microsoft das halt, ich weiß in grad in vielen Unternehmen oder so ist ja Microsoft immer noch Ja. Der Platzhirsch und wenn Microsoft das macht, dann erst dann kann's ja was Gutes sein. Und ich glaube, dass das schon eine große Rolle gespielt hat. Eine andere Zahl, die ich superinteressant fand, ist, dass dass Logins, also das Einloggen mit Passki im Schnitt 8.5 Sekunden schneller sind.
Jan: Geil. Als
Martina: der Log in mit Passwörtern. Das fand ich krass. Das fand ich superinteressant. Ja. Kann ich mir auch nur daher erklären, wir müssen ja das Passwort normalerweise noch hashen wieder. Also wir wir haben ja 'n Hash Algorithmus, 'n kryptografischen Hash Algorithmus wie b crypt, SSSSSSSSSS und wenn sich jemand ein Passwort einloggt, dann muss man ja exakt denselben Hash noch mal ausführen, zusammen mit dem salt und so weiter, zu vergleichen, ob das jetzt dasselbe ist, der in der Datenbank liegt. Und ich glaube, dass deshalb das Anmelden mit Passwörtern manchmal stark in die Länge ziehen kann und das braucht man halt bei Passkys nicht, tatsächlich.
Jan: Meinst Du, also meinst Du wirklich, das kommt durch das durch den Haching Algorithmus? Die sind doch auch mittlerweile Ja. Sicher eher gedacht, das kommt durch
Dave: diesen ganzen UX Ja, also so eintippen alleine, oder?
Jan: Du musst dein Passwort eintippen, oder Du musst das raussuchen oder deinen Passwortmanager aufmachen oder keine Ahnung. Und bei 'nem Pascie sagst Du halt, los. Genau. Also ich hab eher gedacht, dass der Teil vorher viel ausschlaggebender ist als der der Kryptografietal hinten dran, aber ist ja nicht meine Strategie oder so.
Martina: Ja, könnte könntet könntet ihr natürlich auch recht haben. Wobei tatsächlich ist schon häufiger, also wie gesagt, b crypt ist ja mittlerweile auch 'n zu schneller Hash Algorithmus geworden, der der zu schnell mit grad so GPUs und was weiß ich, verteilten Grafikkartenclustern auch gebrochen werden kann. Aber genau und deshalb werden ja Hash Algorithmen immer langsamer maggemacht und ich hätt gedacht, dass es sicherlich vielleicht auch damit 'n bisschen zusammenhängt. Aber
Dave: Ich ich ich ich hätt gern noch mal 'n anderen Punkt aufgemacht, also der auch mit dem zu tun hat, von wegen, also weil wir ja über die Akzeptanz in 'ner breiten Masse irgendwie grade angesprochen haben. Aber ich muss sagen, mir mir fehlt's auch son bisschen, also gut, Du hast gesagt, 69 Prozent haben schon einen, das fand ich jetzt sehr krass. Aber tatsächlich würd ich also sagen, das sind einfach die großen Unternehmen, die grade drauf setzen. Also wenn ich Kontakt hatte mit Parskys so, war das immer im Kontext Microsoft, Google natürlich, Apple auf GitHub und so, also wirklich die die großen Fische. Aber mir ist aufgefallen so, sonst auf kleineren Webseiten, wo man sich sonst anmeldet, ist das irgendwie noch gar nicht dran. Also ich hab das Gefühl, auch so von Betreibersicht heraus werden die grade nicht so häufig irgendwie als mögliches Anmeldeverfahren benutzt.
Martina: Als angeboten?
Dave: Genau, genau, genau.
Martina: Also angeboten, ja. Ja. Mhm. 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 Passky schon seit
Jan: Mhm.
Martina: Irgendwie mehreren Jahren an tatsächlich. Gut, Microsoft ist dazu jetzt erst letztes Jahr gekommen, aber auch so klein es gibt, es gibt eine coole Webseite, die nennt sich Passki Discovery, kann ich auch noch mal verlinken und euch schicken. Das sieht man auch, welche Webseiten alle schon mit Parskys 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 Parskys. Und da gibt's und die die Liste ist weil eine Liste kann man sogar auch eintragen, wenn man möchte, dass ein Unternehmen unbedingt Parskys unterstützen soll. Das ist immer son kleines Ranking irgendwie. Aber es ist auch eine, aber es aber und das taucht Adobe, Visualizen, Slack, Discord kann man eigentlich kriegt man eine ziemlich gute Übersicht, wer schon alles Parskys unterstützt und das ist definitiv schon die Mehrheit Okay. Letztendlich. Also in in meiner Bubble son bissel hab ich 'n anderes Bild.
Dave: Ah okay. Ja, ja. Tatsächlich.
Jan: Wenn wir schon bei den Leuten sind, die Passkys anbieten und implementieren müssen, Vielleicht sprechen wir noch einmal ganz kurz darüber, was können die denn so alles falsch machen? So, ja, ich mein, wir haben in den letzten Jahrzehnten viel darüber gelernt, wie man so Passwörter richtig händeln muss und dass man die verschlüsselt und mit 'nem Soll dran schmeißt und so was alles. Gibt es denn bei Paskies was, was ich auf Plattformseite überhaupt falsch machen kann?
Martina: Ja, also deshalb wär's natürlich cool, einfach 'n IDP zu verwenden, auf den man sich verlassen kann. Ein ein ganz dummes Beispiel ist der Algorithmus, mit dem der public Private Key erstellt wurde, der kryptografische Algorithmus. Denn genauso, wie ich gerade gesagt hab, b crypt, es gilt schon als gebrochen, kann man natürlich auch 'n schwachen algorityptografischen Algorithmus verwenden für die Generierung der beiden Schlüsselpaare, also der des Schlüsselpaars. Mhm. Das ist, ich mein, kryptografische Fehler ist auch wieder in der obersten 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 so etwas, das nennt sich elliptische Kurven, Divi Hellmann, Digital Signatur, das arbeitet, das ist 'n bisschen moderner, ist auch 'n bisschen schneller und es kann halt passieren, dass ältere Serndicator das halt nicht unterstützen und es macht doch definitiv Sinn. Und das ist das ist aber auch etwas, was vom Server kommt. Also der Server kann bei der Erstellung des mitgeben, ja, ich möchte aber bitte, dass der Passki mit diesem Algorithmus erstellt wird.
Jan: Mhm.
Martina: Das ist dann beispielsweise minus 7 und wir wissen ja alle, für was minus 7 steht. Also da steht dann einfach nur, okay, ich möchte bitte, dass der mit minus 7 erstellt wird. Und minus 7 steht einfach nur für elliptische Kurven, digital Signature Algorithmen. Das steht irgendwo toll in der Spezifikation drin. Das ist halt was, was man dann halt beachten muss. Und dann könnt's natürlich sein, dass die Web eine API kein Authenticator findet, der jetzt 'n Paarsky mit diesem Algorithmus erstellen kann. Aber das das sind halt gewisse Whitelisten. Ich hab's auch vorhin schon angesprochen, auch was Whitelisten von Authenticator angeht. Es macht natürlich Sinn, auch da vielleicht tatsächlich erst mal zu sagen, vielleicht nur Hardware basierte Parskys. Das kann man dann auch über diese Challenge, die man dann letztendlich an den Authenticator schickt, senden lassen. Was ganz wichtig ist, es gibt, wenn ich mich anmelde, kann ich immer wieder mitschicken, ob der Nutzer sich noch mal gegenüber den Authenticator authentifizieren muss. Ob ich das als Pflicht mach, weil es, weil wenn der sich nicht mehr authentifizieren muss, dann würde der Authenticator einfach, ohne dass ich's vielleicht mitbekomme oder so, jetzt einfach halt 'n sich mit 'nem Passky einloggen. Was dann theoretischerweise passieren könnte jetzt angenommen, ich hab 'n NFC Passky, also der liegt auf meinem, das liegt auf meinem Handy und ich kann mein Passky über NFC, also meinen Authenticator über NFC aufrufen, dann könnte ich ja theoretischer als Angreifer oder Angreiferin auf eine Webseite gehen und einfach so mal ganz kurz, ganz nah an meinem Opfer mit dem Handy vorbeilaufen. Und wenn dann halt der der Authenticator über NFC quasi zugreifbar ist, dann dann sagt der Authenticator, okay cool, guck mal, ich bin doch da, hier, ich hab 'n paar Ski. Okay, ich logg dich jetzt mal ein. Also über dieses Challenge Response Verfahren. Weil halt der Nutzer nicht noch mal bestätigen muss, ja, ich ich erlaube dem Authenticator jetzt diese Challenge zu signieren, quasi mit dem mit dem Private key, der dem Authenticator liegt. Und das ist, das das nennt sich User Verification, das kann man auf optional setzen oder halt auf equired setzen und es ist definitiv zu empfehlen, dass man das auf immer immer auf Wequirard 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 obsolierte Pasce Keys quasi löschen. Also angenommen jetzt jetzt nur 'n bisschen sehr hypothetisch, aber wir haben plötzlich Postquant Computer. Dann sind ja alle, die mit RSA oder ethischen Kurven erstellt wurden, natürlich, da haben wir 'n ganz, ganz großes Problem. Das heißt, ich müsste dann serverseitig die alle löschen und ich müsste dann über diese, sobald ich den Nutzer versucht an anzumelden, kann ich eine Whitelist ebenfalls an den Browser senden, den Browser mitzuteilen, ey lieber Browser, Du darfst aber nur für mich zum Einloggen nutzen. Und dann würde halt keiner mit drinstehen, also in in dem Fall, wenn ich alle gelöscht hab, Serversite, ich würde halt in der Whiteist kein Authenticator mit drinstehen, sprich demzufolge würde der Nutzer, Nutzerin wieder aufgefordert werden, einen neuen zu erstellen. Aber ich kann dahingehend natürlich diese Passkeys auch witelisten, welche denn jetzt für die Anmeldung überhaupt verwendet werden dürfen. Auch wenn ich gegebenenfalls schon mal einen Parsky erstellt habe, aber der dann halt gegebenenfalls obsolet ist oder nicht mehr sicher ist.
Jan: Mhm. Ich fand das sehr erfrischend, als Du grad gesagt hast, na ja, da gibt's schon so neuere Verfahren und elliptische Kurven und so was. 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 zugute führen, dass elliptische Kurven, ich glaub, aus den Achtzigern oder den Neunzigern sind oder so was. Also die sind jetzt ja auch nicht mehr so Rocket Science oder so, ja? Und trotzdem hat man doch so dieses Problem mit, wir haben, hoffentlich kommen die bald mal überall an, ja?
Martina: Ja, ja, ja, das stimmt. Ich hab, also keine Ahnung, so SS Hakis, mit elliptischen Kurven sind erst so seit 'n paar Jahren irgendwie im Rennen. Also es war, also vor vor 7 Jahren oder so hat jeder noch RS a public private Keys verwendet oder er Ja,
Jan: also same, ja, also ich will mich da ja gar nicht rausnehmen, aber ich find's halt so krass, wenn wir so bei manchen Stellen in dieser Branche irgendwie so jedem Ja. Jedem Trend hinterherrennen und dann so bei Security, na ja, so Kurven, die sind jetzt 30 Jahre abgehangen. Das wird Zeit, dass wir die mal benutzen.
Martina: Aber verwenden. Ja, ja, absolut. Ja, ja. Ja. Ich mein, die große Angst auch mit Post Quantum ist ja ist ja tatsächlich real und da da bin ich auch mal gespannt. Dann haben wir ein Riesenproblem.
Jan: 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.
Martina: Ja, ja. Ich mein, man kann auch ganz kurz noch neuere Entwicklung oder oder es gibt noch eine ganz große Herausforderung von Parskys und das ist quasi das Teilen über Wendorgrenzen hinweg. Also dass ich, ich möchte jetzt 'n Parsky, hab ich bei Windows Hello zum Beispiel drin und ich möchte den Parsky bitte auch auf meinem MacBook verwenden. Es gibt es gibt keine Möglichkeit, dass oder es gab sehr, sehr lange keine Möglichkeit, dass ich den da sharen kann, außer ich nutze den Passky mit 'nem Passwortmanager, der auf allen Betriebssystem Genau. Läuft. Das das das würde gehen. Das das würde natürlich gehen auf jeden Fall, aber man arbeitet aktuell tatsächlich grad an, das nennt sich dann Credential Exchange Protokoll, CXP, eine an 1 Art von Protokoll, mit der ich dann Passkys auch über Betriebssystemgrenzen hinweg sharen kann oder auch exportieren kann. Das heißt, man über Was
Jan: ja vielleicht auch dieses Enduser Problem löst, dass man mit Passkeys quasi keine geteilten Accounts haben kann. So, ne? Ich kann dir jetzt nicht einfach mal 'n Passwort geben, damit Du dich da mal irgendwo einloggen kannst.
Martina: Ja, jetzt bezeichnest Du das als Problem. Es ist ja ist ja schon okay. Es 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.
Jan: Wenn Du Netflix bist, ja, ist das nicht so cool, aber wenn Du natürlich deine 3 Freunde bist, die freuen sich natürlich. Ja, ja. Das das Ich
Martina: hab das auch schon gemacht. Das macht das Ich kenn das, also ich ist alles gut. Also ich hab das zwar nicht über Whatsapp gemacht, aber das aber über 'n anderen Kanal oder so, es ist natürlich
Jan: Über SMS, da haben wir ja eingangs gehört, dass das der der sicherste Kanal ist. Ja, ja.
Martina: Also das das, ich kann das auch vollkommen verstehen. Ich glaube zwar nicht, dass es jetzt mit dem SEIXPIR, also mit dem predential Exchange Format ähnlich leicht wird wie Passwort über Whatsapp, aber es ist auf jeden Fall leichter jetzt dem, in Vivienenzes man hat hat gesagt, den private Key über von einem Betriebssystem auf das andere Betriebssystem rüber zu schieben. Da wird aber das ist das ist grad so die nächste Entwicklung, das ist grad noch so der nächste Standard, weil da ist Apple 'n bisschen vorgeprescht. Apple hat einfach irgendwas entwickelt, mit dem es funktionieren könnte und und Windows und auch Linux haben gesagt, ich Was was willst Du denn jetzt? Wir haben Wir wir machen erst mal 'n Standard, den implementieren wir mal alle zusammen und dann ist 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.
Jan: Ach ja, das ist so die Geschichte des Internets, das ist so irgendeine Bauzeit erst mal und dann wird so geguckt, wie man das standardisieren kann.
Martina: Ja, es gab auch einen Riesenartikel, Apple Kilparskys, weil weil das dann irgendwie die anderen, also wie Windows, die waren dann auch 'n bisschen beleidigt, also Microsoft. Es war ein riesen Gezetere. Es war es war
Jan: ganz, ganz schlimm. Deshalb bin ich ziemlich glücklich, dass
Martina: die Entwicklung jetzt kommt, dass man sich ja auf 'n Format Also es gibt 'n CXF, das Greet engine Exchange Format, also das ist halt auch einfach nur 'n JSON, was dann halt definiert quasi, wie halt dann, es mal sozusagen der private Key dann von einem zum anderen geschoben wird und und dann gibt's 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 wird findet gerade die Adaption statt.
Jan: Ich fand das so krass, dass Du gesagt hast, so man sollte das so alles über 'n Identity Provider zu machen. Ich hatte son bisschen die Hoffnung, dass es gar nicht so schlimm ist, wenn man das alles irgendwie selber bauen will.
Martina: Es ist halt krass, was man was man da halt alles achten muss. Also wie gesagt, alleine schon, wie Du Passwörter abspeicherst. Second Faktor, also ich ich will den ich will nicht Multifaktor Authentifizierung selbst implementieren, serverseitig. Also klar, Du kannst Und und dann machst Du automatisch Abstriche, weil Du sagst, boah, das ist voll komplex, das lassen wir lieber mal. Oder diesen Verifikation Step, der die Spezifikation vorschreibt, boah, der ist ja boah, das ist holler, die bald für den lassen wir mal weg. Und und Ja. Dann
Jan: Aber glaubst Du, das ist draußen? Also ich komm halt, also ich mein, wir sind ja alle schon son bisschen länger im Business, ja und so irgendwie Passwort Logging bauen. Das hat ja, also das hat ja niemand früher so ausgelagert, ne. Das hat ja jeder irgendwie selber gemacht, so. Manche 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 was bauen, sagen, okay, so Identity ist so, das geben wir komplett weg und dann nutzen wir halt nur Okta oder nur Single, also ne, ne. Ist es tatsächlich so? Ich bin schon son bisschen raus aus diesem Produktding, deswegen weiß es nicht, wie das Leute machen, die halt heute auf der grünen Wiese anfangen.
Martina: Ja, also ich kenn kaum, ich kenn eigentlich kein Projekt, wo nicht mindestens Keyclock verwendet wird. Also, dass man Also ich kann dir gar nicht ausziehen, wie viel falsch man da machen kann. Das ist ein Man will Man muss jetzt nicht Okta für 1000000 kaufen mit Enterprise Support. Keylogge ist komplett Open Source. Du Key Clock ist von Redhead, das kann man mit 'nem Docker Container hochziehen und dann ist und die wissen das
Jan: Aber Sie betreiben das quasi alle oder die meisten dann halt doch irgendwie selbst?
Martina: Du hast es self hostet, also Du musst das Du musst das self hosten, aber die ganze Kryptografie und die ganzen Territierungsschritte und alles Mögliche ist halt in KeyClock drin und das also ich das will man nicht selbst implementieren. Du sagst dann bei KeyClock einfach nur, okay, ich hab 'n Nutzer, der hat die Rollen und wenn er auf diesen Service zugreifen will, den ich halt auch kurz bei Keylog registrieren muss, dann muss er diese Rolle haben und Keylog stellt mir son schönes Access Token aus und fertig. Und und das und ich will das nicht selbst machen ehrlicherweise.
Jan: Also ich versteh das voll. Ich frag mich dann bei so was halt immer nur so, als als so Tool, wie sehr kann ich mir damit halt auch irgendwie in den Fuß bohren, wenn ich's halt irgendwie falsch benutze? Weil, ne, nur nur dadurch, dass wir das haben, ich das Problem noch nicht gelöst. Ich muss es ja auch richtig in Anführungszeichen benutzen.
Martina: Ja, klar. Dafür gibt's dann natürlich die Consultants, die 5 Tage Keylog Workshops anbieten und
Jan: Ah, ach, ach, issig.
Martina: Tagessatz für 5000 Euro haben. Nee, also also hast Du natürlich recht. Ich würde aber nichtdestotrotz behaupten, dass die Konfiguration von KeyClock nicht so viel konfiguriert werden kann, wie Du das falsch implementieren könntest im Worst Case.
Jan: Mhm.
Martina: Also also es kann mit 'ner fehlerhaften Kegel Konfiguration kann nicht so viel kaputtgehen, wie wenn Du fehlerhaft selbst implementiert hast. Also ich weiß nicht, dass das das geht halt in die Richtung, Du implementierst 'n Passworthaching selbst und das will man halt auch nicht machen, dafür verwende ich 'n SDK oder so was. Und gerade bei Authentifizierung, Autorisierung gibt's halt so viele Schritte. Also wie gesagt, alleine, wenn Du irgendwie Singles and on haben möchtest, was halt heutzutage der Standard ist. Wenn Du sagst, okay, wir haben halt Passwörter, willst 'n Second Faktor haben. Du willst dann gut biometrischen Sekten 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, ja so ja. Ist halt auch 'n bisschen in meiner Bubble habe ich nicht gesehen, dass das jetzt jemand geradezu noch irgendwie selbst implementiert.
Jan: Ich hab als als Passwörter noch der heiße Scheiß waren, hab ich auch mal so Systeme gesehen, die dann so was machen wie, wir speichern zwar dein Passwort nur gehasht, ne, aber in dem Moment, wo Du dich anmeldest, haben wir's ja einmal ganz kurz im Klartext und wir nutzen dein Klartextpasswort, irgendwie deine Userdaten noch mal zu verschlüsseln mit deinem Passwort als Schlüssel quasi so, damit wir selber nicht mal addressd an deine an deine Sachen drankommen können. Gibt's irgendwie dazu son son analog in der in der Pasckey? Weil weil ich bekomm ja eigentlich gar nichts, außer so die Bestätigung, dass Du Du bist, oder? Ich kann kann ja gar nicht mehr damit machen eigentlich.
Martina: Ja, das stimmt tatsächlich. Ich glaube, so was hat man dann konkret nicht mehr. Ich muss kurz nach, Ich über, mir braucht ja einfach nur eine Konstante, die nur der Nutzer hat. Das ist ja eigentlich das der Punkt, da ich Und
Jan: das Passwort bietet sich halt an, weil er's eher übertragen musste sozusagen, ne?
Martina: Ja, ja, ja. Und man überträgt ja eigentlich nur noch die signierte Challenge, von mir ist noch 'n paar Metadaten. Noch nicht mal die Authenticator ID könntest Du verwenden, weil die könnte auch wechseln. Also hast schon recht, ich glaube so, das müsste man sich wieder selbst konstruieren, so per se gibt's das nicht mehr. Tatsächlich, ja.
Jan: Dave, Ja. Du wolltest noch eine Frage zu deiner Glaskugel stellen.
Dave: Genau, und zwar, man hat am Anfang son bisschen deine Aversion gegenüber Passwörtern mitbekommen. Und deswegen hier die Frage an dich, ist es für dich so, dass dieses System Passwort irgendwie kaputt ist und irgendwie in Zukunft komplett irgendwie aussterben wird, dass wir jetzt nur noch dann in Zukunft Paskies verwenden oder was? Wie wie wie sieht die Zukunft für dich aus, was Security angeht?
Martina: Ist natürlich eine sehr spannende Frage und hängt natürlich von so vielen Faktoren ab. Das eine ist son 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 dass die Zukunft passwortlos ist und dafür steht ja auch Fiido, Fast Identity online, Passwort lässt Authentication, die die tun ja versuchen ja seit über 6 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 und fertig. Und ich glaube, es braucht vielleicht doch eher so neuen Wind, also ich sag mal, dass vielleicht auch die die Entwickler und Entwicklerinnen oder Nutzer und Nutzerinnen, die Passwörter noch erlebt haben, vielleicht auch in Rente gehen oder halt irgendwie, dass man halt nur noch halt diese Passki Ära halt letztendlich kennt, weil es ist halt Passwörter haben halt den Vorteil, ich kann sie eben mal schnell jemanden geben. Ich schreib sie auf 'n Zettel. Oh, ich hab mein Passwort vergessen, dann schreibe ich kurz, wie wie's wie's, ich glaub, das war das Samsung CTO einmal, meiner Sekretärin eine E-Mail und sagt, schick mir mal bitte das Passwort über E-Mail, ich hab mein Passwort vergessen. Und dann wurden die E-Mails leider offengelegt, 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 totzukriegen in in naher, mittelnahen Zukunft. Nichtsdestotrotz bin ich aber überzeugt, dass in längerer Zukunft Passkys überwiegen werden und mehr und mehr Leute auch von den Vorteilen letztendlich profitieren werden und es auch merken und deshalb auch Paskys 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 Anwenderinnen und Anwender das Passwort immer wieder neu, weil es nervig ist. Also immer immer wieder für andere Dienste, weil's halt einfach nervig ist. Und dann muss man einfach, glaube ich, nur 'n bisschen Aufklärungsarbeit leisten. Vielleicht noch mal son paar Sachen standardisieren wie Recovery, Recovery, wie kann man das machen? Vielleicht auch ohne, dass man unbedingt das mit 'ner E-Mail verknüpft oder so. Ich glaube, da mussten braucht man auch 'n bisschen Aufraum arbeiten, paar Fragen müssen geklärt werden, aber dann seh ich die Zukunft auf jeden Fall grundlegend Passwortless.
Jan: Wunderbar. Das wär ja fast schon 'n schönes Schlusswort gewesen.
Martina: Aber.
Jan: Aber, Dave, ja, was was was haben wir noch, ne?
Dave: Das Schweinchen des Tages, richtig?
Jan: Das was?
Dave: Das Schweinchen des Tages? Ach so, Pic of
Jan: the day. Hat's gedauert, ja. Oh Gott. So, wie immer haben wir noch ein paar für euch am Ende der Folge. Und ich sag mal, Dave fängt an, weil er bestimmt wow midnight picken will diese Woche.
Dave: Oh, gar nicht, gar nicht. Ich hab wirklich, ich hab Ich hab
Jan: statt ihr meine Schulter einmal vorhersagen, was Du was Du machst.
Dave: Aber guter Gedanke, nee, seit ihr meine Schulter wieder funktioniert, hab ich den Weg wieder ins gefunden und bin komplett raus, was W0W angeht. Erstmals, erst mal. Aber ich hab ich hab tatsächlich was anderes. Es ist auch tatsächlich 'n Game, das ich mitgebracht habe, weil ich's aber von der Idee her sehr cool fand. Und zwar ist es. Das ist 'n Spiel, das irgendjemand mal entwickelt hat. Und ich fand's vom Gedanken halt sehr cool. Es ist halt also eine Schlange einfach und die Schlange verfolgt dich und Du bist der Apfel. Du musst wegrennen. Und das ist halt irgendwie von der Idee so gut gemacht irgendwie. Und das ist auch schon interessant, da gibt's verschiedene Level und es wird natürlich immer schwieriger und sowas. Du willst
Jan: ja auch immer kürzer? Also weißt Du, dann so komplett revers halt?
Dave: Ja, weiß ich grad nicht mehr so aussehen. Ich hab das vor paar Wochen immer gemacht und fand's auf jeden Fall sehr unterhaltsam. Also es wird auf jeden Fall also 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. War fand ich auf jeden Fall eine superlustige Idee. Ich mag, wenn man son kreativen Twist einfach in irgendwie bekanntes Spielprinzipien alleinbringt. Nun von daher ist das mein. Ich fand's sehr, sehr unterhaltsam und lustig.
Jan: Okay, damit hab ich überhaupt nicht gerechnet. WOW Midnight versus. Triple-A-Titel, hundertste Millionen. Nein. Beides. Beides. Beides. Für
Dave: mich für
Martina: Aber etwas k 18, beides. Ja. Superparadies. Genau.
Jan: Also jetzt jetzt hätt 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 trau mich jetzt nicht mehr noch mal 'n Forecast zu machen, deswegen frage ich einfach, was
Martina: hast Du als Pick of the day dabei? Das stimmt, das ist natürlich 'n bisschen zu einfach und ich hab natürlich Pokémon schon durchgesuchtet, aber mein Pick of the day kam zu 1 ähnlichen Zeit raus, denn ich liebe Horrorspiele. Total. Als damals
Jan: doch Pokémon. Nein.
Martina: Ja, als damals Silent Hill F raushaben, hab ich das durchgesuchtet. Und jetzt kam aber gerade Ende Februar das neue Resident Evil raus.
Jan: Requir.
Martina: Ja. Ja. Ja. Was was ich halt jetzt tatsächlich mir teilweise vorher schon Let's Plays und und oh, irgendwie die Spieldynamik und das ist ja ziemlich cool. Also Resident Evil ist hier so Zombies und man knallt die ab und es ist so eine kleine Backgroundstory. Man muss immer Töchter von irgendwelchen Präsidenten retten und so. Und und diesmal ist es halt
Jan: so, dass man 2 Charaktere immer wieder abwechselnd spielt, was
Martina: ich super spannend finde, weil Charaktere immer wieder abwechselnd spielt, was ich super spannend finde, was mir aber so ein bisschen Probleme macht, weil so der eine Charakter, das ist dieser Leon, das ist 'n Hauptcharakter und mit dem kann man rumballern und Zombies töten und mit der mit dem anderen Charakter, das ist quasi sone FBI Agentin, mit der man dann
Dave: Die Grace.
Martina: Grace, genau. Und die hat halt nicht so viel Ressourcen und mit der muss man immer schleichen und vorsichtig sein und also Ressourcen mit Man hat nicht so viele Patrone, hat nicht Waffen und keine Ahnung und ich bin so schlecht im Ressourcenumgang. Wenn ich irgendwas sehe, will ich einfach draufballern und es einfach nur töten. Ich ich bin halt nicht so die Versteckerin und und vorsichtig und Geduld haben und Sorgfalt, das ist nichts für mich, Deshalb ist das ziemlich herausfordernd, aber macht Spaß bisher auf jeden Fall.
Dave: Ich find's ich find's by the way, also ich hab's mir auch sofort geholt. Ich würd sagen, ich bin Resident Evil Ultra, also jeden Teil sofort am besten Tag gespielt und ich muss sagen, die kriegen das erstaunlich gut hin, dieses weil also die Serie hat's, war damals Horror, da hat sich in eine Actionrichtung bewegt und ist dann wieder zu Horror zurückgekommen. Und die haben jetzt beides kombiniert, diese Actionreiche und dieses Horrorartige. Und das ist halt wirklich super gelöst durch diese 2 Charaktere, die in 'nem ähnlichen in 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 Gray spielst, wirst Du von den Zombies gejagt und das irgendwie Genau. Kriegen das wahnsinnig gut hin. Also wirklich, Hut ab.
Martina: Ja, ja und das Coole, aber noch am Einsatz sozusagen, was ich besonders cool finde, ist, man stellt es sich, man stellt sich das vielleicht erst mal voll schlimm und langweilig vor, dass Du denselben Weg zweimal abgehst. Also und ja, am Anfang ist es so, da ist man ist ja in sonem Krankenhaus und dann geht die Grace erst mal vor und danach kommt der Lier 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 Crazy vorsichtig sein und sich verstecken und man man läuft ganz anders oder man erkundet das ganz anders und mit dem Lion geht man einfach durch und ballert das ab. Da kann man dann endlich die dummen Zombies, die einen gejagt haben, dann einfach abknallen. Also das ist nicht so monoton, wie das erst mal klingt. Das finde ich das finde ich halt supercool, was sie da kreiert haben. Also ja, nee, ich bin noch nicht so weit ehrlicherweise, weil ich natürlich die Zeit lieber mit euch in 'nem Podcast verbringe als Yes.
Jan: Let's go.
Martina: Jesko. Wer ist denn die Liebe zu spielen? Aber wahrscheinlich heut Abend werd ich mal wieder ein bisschen reinschauen.
Jan: Ja, wunderbar. Ich hab noch einen ganz kleinen Pick of the day dabei. Und zwar hatten wir uns hier vor 'n paar Wochen alle son sehr intensiver mit beschäftigt und irgendwelchen komischen AI Agents, die Amok laufen können auf deinen Kisten. Und ich dachte, ich mach das sehr vorbildlich und ich installier den hier bei mir auf sonem eigenen kleinen Mac mini, den ich noch rumliegen hatte und irgendwie alles schön isoliert und abgekapselt und so. Und dann hab ich son bisschen Panik bekommen, dacht, okay, aber der muss ja auch in mein 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 son Anti Zero Trust Network bei mir zu Hause. Wenn Du einmal drin bist in meinem Netzwerk, so, dann ist alles dann ist alles offen und so. Dann kannst Du am Smarthome rumschrauben, unter Medienserver und an der Haussteuerung und so, ist alles egal. Solange Du einmal irgendwie physisch Access hast, also Dave, wenn Du mal vorbeikommt, einfach 45 irgendwo die Wand, sagt dann die 3 Gäste. Und da ist so, okay, nee, der der niemals kann der hier irgendwie alleine rumlaufen, weil es steht ja irgendwie Tür und Tor offen. Da hab ich war so die Frage, okay, wie krieg ich den halt hier irgendwie isoliert? Und ich hab jetzt nicht son krassen Unify Switch oder so was, wo ich Hardware Faulanz irgendwie aufmachen kann und das irgendwie auf der Ebene alles trennen kann. Aber dann hab ich 'n bisschen recherchiert und was ganz Cooles gefunden, Das ist jetzt mein, lange, lange Vorgeschichte. Wer zu Hause eine Fritzbox nutzt, so, der kann die Fritzbox so einstellen, dass der LAN Anschluss Nummer 4 isoliert von allen anderen Netzwerkports betrieben werden kann. Das so Purman's V-Netz sozusagen, ja. Du hast genau ein Gerät, was Du anstöpseln kannst, was von allen anderen getrennt betrieben wird, so. Und das hab ich dann genommen und sage so, okay, hier mein OpenClown Mac mini, der per Kabel an dem Port ran und der sieht den ganzen Rest nicht. Ich hab 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 erst mal Fritzbox Port Nummer 4 und überhaupt keinen Zugriff auf gar nix. So, ganz, ganz kleiner Pick of the day, so Minischwein. Ach so, das
Martina: ist aber auch sehr vorbildlich, weil die meisten hauen einfach oben 'n Glo ins Netz und den
Jan: goefrise Die allermeisten installieren das wahrscheinlich einfach schon mal auf ihrer eigenen Kiste so, da fängt's ja schon mal an.
Dave: Ja, ja. Ich hab auch ich hab auch grade schon gesagt, Martina, so als Security Profi hier und Du hörst direkt so Open Klo. Und ich so, oh nein,
Jan: oh nein,
Dave: oh nein, oh nein, was kommt jetzt?
Jan: Ja, da da könnt man eigentlich noch eine ganz eigene Folge drüber machen, wie dieses Experiment gelaufen ist und so was alles.
Martina: Ich glaub, das ist auch super, also ich glaub, das wär superspannend. Ich würd's sie mir definitiv anhören. Also jetzt wie wirklich aufrichtig, ich fänd's superspannend.
Jan: Ja, vielleicht machen wir das tatsächlich noch. Wir haben son paar Leute hier, die damit so rumexperimentiert haben und tatsächlich auch in den verschiedensten Abstufungen. Also ich ich war, glaub ich, der allerparanoideste, sag ich mal so, ja? Wir hatten hier Leute, Garhead, ich will keine Namen nennen Mog, der so das auf seinem Desktop einfach drauf installiert, go for it, ja? Dann haben wir Leute, die das irgendwie in 'nem auf in 'nem TV Server irgendwie ganz woanders hin installiert haben so, ja. Und das sind alles sehr unterschiedliche Erfahrungen, die man damit machen kann, ne. Je nachdem, wie viel Daten da drauf sind, ob das deine Kiste ist, ob das Ding Headness läuft, wie isoliert das halt ist, weil natürlich, jetzt ohne diese Podcast vorher jetzt schon zu machen, ne, aber je ordentlich in Anführungszeichen Du ihn einrichtest, desto desto weniger kann er halt am Ende auch tun, ne. Ne, und das dann wieder diese diese Abwägung, was wir vorhin auch schon dran erinnern, ne. Security ist immer so dieses Dreieck zwischen Security Convenience und Kosten und so. Aber ja, also merkt's 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.
Martina: Ja, sehr cool.
Dave: Sehr cool. So.
Jan: Wunderbar. Dann Martina, danke dir für die Zeit, die Du dir
Martina: Sehr sehr gerne.
Jan: Uns genommen hast, auf deinen Hate Spaß. Resident Evil zu verzichten für uns, anderthalb Stunden, ja. 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 at Programmier Punkt 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. Tschau, tschau und bis zum nächsten Mal.
Dave: Vielen Dank. Bis dann. Tschüssi.
Martina: Danke. Tschau, tschau.

Passkeys mit Martina Kraus

Shownotes

Picks of the Day

LAN-Gastzugang der FRITZ!Box

Resident Evil Requiem

Reverse Snake

Speaker Info

Martina Kraus