Passkeys

Christoph: Hallo und herzlich willkommen zu einer neuen Ausgabe des INNOQ Security Podcasts. Heute habe ich die Sonja bei mir. Hallo Sonja!

Sonja: Hi Christoph!

Christoph: Ja, und wir beide wollen über das Thema Usable Security und Passkeys sprechen. Das hat zwei Gründe. Wir haben das schon mal ein bisschen in älteren Sendungen betrachtet. Da hatten wir sogar einige. Wir haben mal über Passwörter gesprochen, über Passwort Manager, über Zwei-Faktor Authentifizierung und im Adventskalender mal über die Sicherheit von Fingerabdrücken und den Komfort von Fingerabdrücken. Und dabei gab es eine ganze Reihe von Problemen. Und du hast dich mit deiner Masterarbeit genau mit diesem Thema beschäftigt. Und das können wir jetzt mal zusammenbringen. Vielleicht fangen wir damit an, erst mal eine kleine Problemstellung zu geben. Was ist denn eigentlich so schlecht an den Passwörtern? Man könnte jetzt natürlich die alte Folge noch mal nachhören, aber vielleicht fassen wir das noch mal kurz zusammen.

Sonja: Ja, genau. Passwörter haben von zwei Seiten Probleme. Und das sind auch die Themen, mit denen ich mich hauptsächlich beschäftigt habe. Usability und Security. Und ihr habt das damals schon in eurer Folge recht detailliert besprochen. Passwörter sind einerseits, wenn man erst mal auf die Usability schaut, irgendwie nicht gut gemacht fürs menschliche Gehirn. Man muss sie sich erst mal ausdenken und man kann sie sich schlecht merken und das ist was, was dann eher dazu führt, dass man sich nicht sichere Passwörter ausdenkt, sondern einfache, so einfach wie es geht. Und das öffnet wiederum Angriffen Tür und Tor. Und gleichzeitig ist es von der Security-Seite so, dass Security seither so, dass nicht nur die konkreten Credentials von User-Seite her angegriffen werden können, sondern auch auf der Backend Seite, weil Passwörter auch dort gespeichert werden müssen. Es gibt ein Geheimnis, das gespeichert wird und das dann zur Authentifizierung dient. Und das ist ein Problem. Und da kann man sich behelfen mit, da habt ihr auch schon darüber gesprochen, mit Passwort Managern oder man kann den zweiten Faktor dazufügen, um das ganze sicherer zu gestalten. Aber letztlich bleibt viel Verantwortung bei den Nutzer:innen, dass sie das richtig machen oder auch vielleicht bei den Webseiten, die das implementieren, dass sie auf guten Backend-seitigen Schutz schauen. Aber oft wird auch viel Verantwortung auf die Nutzer:innen abgewälzt. Und das müsste vielleicht auch nicht so sein. Und die Frage ist: Gibt es bessere Lösungen, die da die Verantwortung wegnehmen und das Ganze nutzbarer und gleichzeitig sicherer gestalten? Das wäre großartig.

Christoph: Ja, wo du Passwörter sagtest, dass man die sich schlecht merken kann. Ich sage immer: Passwörter müssen zwei Eigenschaften haben. Sie müssen leicht zu merken sein, aber viel Entropie haben. Aber man kann nur eine auswählen. Beides geht dann halt nicht. Der Passwort-Manager hilft, aber da braucht er natürlich auch schon mal wieder ein Master Passwort. Und vielleicht kostet er auch Geld und da muss ich den auch noch synchronisieren zwischen den verschiedenen Geräten und so. Also alles nicht so einfach. Dann hattest du gesagt: Zwei-Faktor Authentifizierung. Dazu hat man zwar schon mal eine ganze Folge aufgenommen, aber vielleicht erzählst du den Leuten, die die jetzt nicht gehört haben und auch nicht nachhören wollen, obwohl ich das natürlich dringend empfehle. Was denn Zwei-Faktor Authentifizierung ist und vielleicht mal ein paar Beispiele. Da gibt es verschiedene Implementierungen.

Sonja: Bei den Faktoren, von denen wir hier immer sprechen, die teilt man grob ein in drei: Wissen, das wäre dann sowas wie ein Passwort oder eine PIN oder Besitz. Und da würde klassischerweise so ein zweiter Faktor, den vielleicht die meisten kennen, reinfallen, den man zum Beispiel bei Banking Apps oft benutzt, ein One-Time Passwort. Das wird dann entweder gleichzeitig auf dem Handy generiert, das ist der Besitzer oder auf Seiten der Websites und dann via SMS geschickt, hat auch alles wiederum irgendwie Sicherheitsimplikationen. Von daher würde ich echt empfehlen, die Folge noch mal nachzuhören. Da habt ihr das im Detail besprochen. Und dann gibt es noch den dritten Faktor: Biometrie. Sowas wie ein Fingerabdruck oder ein Gesichts-Scan. Und ich glaube, grob gehört auch noch so was wie physikalisches Verhalten dazu. Pattern der Tastatur zum Beispiel würde, glaube ich, auch noch unter Biometrie fallen. Das ist ein bisschen grenzwertig. Vielleicht müsste man da noch mal einen vierten Faktor erfinden. Und das wird gerne oder auch nicht so gerne ergänzt, um dann diese Schwächen von Passwörtern ein bisschen abzufedern. Es ist halt so, es gibt auch noch andere Möglichkeiten 2 Faktoren zu generieren. Das würde ich gleich noch ergänzen. Aber man versucht vor allem das Ganze gegen so was wie Credentials Stuffing oder Brute Force Attacken, die halt wirklich mit einem schwachen Passwort dann gut funktionieren, dagegen noch mal einen Schutz aufzubauen. Das Problem dabei ist allerdings, man braucht dafür zusätzliche Hardware. Es ist von der Usability Seite wieder etwas schwierig. Bzw. ist nicht für alle so einfach zu nutzen, auch wenn wahrscheinlich heutzutage fast jeder ein Smartphone hat, und man muss es auch, der zeitliche Aufwand wird noch mal mehr. Viele finden das nervig und schalten es nach Möglichkeit schnell ab, wenn es irgendwie geht. Was der zweite Faktor mit so einem One-Time Password aber nicht verhindert, ist grundsätzlich die Möglichkeit von Phishing, weil auch ein zweiter Faktor eben über so eine Fake Website abgefangen werden kann. Und dann kann man die Credentials, wenn man jetzt gutgläubig die auf der falschen Website eingibt, können die dann irgendwo abgefangen werden und von bösen Hackerinnen missbraucht werden.

Christoph: Ja, das ist, glaube ich, heutzutage mit das größte Problem, weil es relativ einfach geworden ist, Phishing Kampagnen zu fahren. Seiten zu kopieren, gibt es Tools für. Die sehen dann genauso aus. Domains, die ähnlich sind, findet man auch immer wieder noch, die man dann registrieren kann. Und wenn man da nicht genau drauf achtet, dann passiert es auch durchaus, dass Leute dann einfach ihre Credentials eingeben, wenn man sie da drauf lockt, mit irgendwelchen vorgeschobenen Vorwänden. Ihre Identität noch mal neu bestätigen, sonst wird Konto geschlossen oder solche Sachen, wo man vielleicht auch noch zeitlichen Druck ausgesetzt wird. Und wenn wir das jetzt auch bedenken, dass viele dieser Massen Phishing E-Mails natürlich nicht so glaubwürdig sind, aber das wird a) immer spezialisierter und jetzt mit AI-Tools auch immer geschliffener in der Sprache. Und bei uns intern tauchen auch immer wieder mal in Slack auf: Hier folgende E-Mail: Ist die echt? Ist die nicht echt? Das betrifft nicht nur Leute, die jetzt nicht so technikaffin sind wie wir beide oder bei uns in der Firma. Da gibt es viele Probleme und wir hatten selber mal in der Firma so ein Phishing Test und die Rate war niedrig. Aber auch selbst bei unseren technikaffinen Leuten ist es Leuten passiert, dass sie ihr Passwort, ihre Credentials eingegeben haben.

Sonja: Ja, ich glaube, das ist ein ganz wichtiger Punkt, dass es nicht sowas ist. Da kann man jetzt arrogant sein und sagen: Mich trifft es nicht, aber ich glaube, es gibt für fast alle irgendwie so einen Hebel oder einen Trigger oder einfach mal einen schlechten Tag und man denkt nicht darüber nach und fühlt sich dann irgendwie. Ich glaube, es ist nicht so, dass da irgendjemand komplett davor gefeit ist, wenn das den richtigen Punkt trifft oder es zum richtigen Zeitpunkt kommt. Deswegen ist es wichtig, dass man da auch ein Bewusstsein dafür hat, dass es das gibt und dass es auch extrem verbreitet ist, das Phishing. Das gibt es auch schon seit mehreren Jahrzehnten. Also mehrere Jahrzehnte ist übertrieben, aber seit über zehn Jahren auf jeden Fall und ist immer noch ein sehr beliebter Angriffsvektor.

Christoph: Ja. Wo du sagst, es kann jeden treffen. Der richtige Zeitpunkt. Es kann nur der fehlende Kaffee sein am Morgen, wo man unaufmerksam ist. Oder es gibt eine beliebte Methode, die jetzt nicht so ganz den sozialen Faktor hat. Aber den Nervfaktor, wenn man das per Push Nachrichten oder SMS kriegt, und dann wird man beballert mit Login Versuchen.

Sonja: Push Bombing.

Christoph: Genau, die Angreifer haben schon die normalen Credentials, aber der zweite Faktor fehlt. Und wenn man dann nachts, weil man vielleicht auch irgendwie Bereitschaft oder so hat und das Telefon nicht abstellen kann, bombardiert und irgendwann drückt man da mal auf den falschen Knopf, weil man eigentlich schlafen will oder das Generve aus ist, und schon ist es vorbei. Aber gegen Phishing, da gab es auch schon Lösungen. Wenn wir jetzt so was Hardware-basiertes haben, da wird es oft schwierig mit dem Phishing, aber da gab es auch Probleme. Vielleicht könntest du die noch mal ein bisschen ergänzen.

Sonja: Ich glaube, ihr hattet das auch in der Zwei-Faktor Folge erwähnt, mit dem einem anderen zweiten Faktor, nämlich einem Hardware Security Token und auf der Basis von Web AuthN. Und das ist auch das, worauf Passkeys aufbauen. Da kommen wir dann noch dazu. Und das ist dann Standard oder eine API, die als Standard ausgearbeitet worden ist von der W3C. Und das in Zusammenarbeit mit der FIDO Alliance. Und die haben sich so ein bisschen dem Thema verschrieben, Web Authentifizierungen sicherer zu machen. Und diesen Standard gibt es auch schon eine Weile. Seit 2019 ist es, glaube ich, offiziell ein Standard und so lange kann man sich auch schon theoretisch passwortlos einloggen. Das heißt, diese API muss implementiert sein in den Browsern und in den Authenticators, bisher in der Regel waren das Roaming Authenticators. Das sind tragbare Teile, die dann über Public Key Encryption mir so ein Schlüsselpaar erzeugen. Das heißt, ich habe dann einen Private Key auf dem Authenticator und schicke nur den Public Key dann an die Webseite und der Browser ist da auch noch mit eingebunden. Es ist dann ein Zusammenspiel aus den Web Anbietern und der Relying Party, einem Browser und diesem Authenticator. Das ist so zusammengebunden und deswegen ist es gar nicht möglich, das irgendwie zu fischen. Weil wenn ich jetzt auf einer Fake-Seite wäre, dann könnte ich meine Credentials da gar nicht eingeben. Ich hoffe, das war nicht zu abstrakt.

Christoph: Es war ganz schön viel. Vielleicht sollten wir noch mal so ein bisschen ins Detail gehen. Roaming Authenticator ist natürlich der Fachbegriff, aber wir können auch einfach sagen, das ist ein USB-Stick.

Sonja: Genau, wie so ein YubiKey zum Beispiel.

Christoph: YubiKey, Nitrokey, Titankey von Google, einfach so ein kleines Device, was ich in einen USB-Port stecke. Und der Browser kann dann mit dem kommunizieren. Dafür gibt es auch ein Protokoll, was definiert ist, wie man standardisiert mit der Hardware kommuniziert und du hast schon gesagt, Public Private Crypto findet auf diesem Key statt und gar nicht auf deinem Rechner. Und dann kann man den Key auch nicht so leicht runter kriegen. Die sind auch dagegen geschützt. Und die Webseite macht das dann mit der WebAuthn API versucht dann den Key anzusprechen und dann kriegt das… Du sagtest, es ist nicht möglich, das zu phishen, weil ein Teil der Informationen, die in diesem ganzen Ablauf benutzt werden, ist die Domain und die haben die Leute, die das Phishing betreiben, nicht. Die haben zwar vielleicht eine, die so ähnlich ist, nur ein Buchstabe anders, aber das reicht dann halt schon, dass es nicht geht. Das ist super von der Sicherheit, aber von der Usability wahrscheinlich eher nicht. Vielleicht kannst du noch was sagen, warum die Usability da gar nicht so gut ist. Weil eigentlich, stelle ich mir vor, stecke ich das jetzt in den USB-Port und drücke einmal auf den Knopf, das hört sich jetzt nicht so schlimm an von der Usability. Außer ich habe einen Mac und nur USBS und mein YubiKey hat USBA, aber sonst…

Sonja: Ja, ich sehe da vor allem den Punkt auch in der Unzugänglichkeit durch den Preis. Es ist natürlich dafür, dass es noch sehr in den Kinderschuhen steckt, und wenig angeboten wird von Webseiten einfach ein großes Investment. Und ich muss, wenn ich jetzt möchte, dass ich auch ein Backup habe, dann brauche ich zumindest noch einen zweiten Key, weil wenn ich sonst das Ding verliere, dann habe ich meine Credentials, die quasi da drauf sicher lokal gespeichert sind. Durch diese Sicherheit verliere ich halt auch die Flexibilität, die Credentials immer verfügbar zu haben, wie das zum Beispiel bei einem Passwort theoretisch ist, wenn ich es mir merke oder wenn ich einen Cloud Password Manager benutze. Und noch problematischer wird es dann, das nutzen einige, es ist aber tatsächlich nicht so, dass sich das in der Breite durchgesetzt hätte. Wie gesagt, das gibt es schon seit vier Jahren. Ich denke, dass es in unserer Bubble recht viele Leute machen, mit einem großen Sicherheitsbewusstsein. Aber für Menschen, die das einfach nicht auf dem Schirm haben, dass das Passwort auch sehr problematisch sein könnte, ist es vielleicht einfach ein zu großes Investment und dann auch noch das erst mal registrieren und einrichten. Natürlich gibt es auch die Möglichkeit, dass man diesen Authenticator nicht nur extern hat, sondern auch auf dem Gerät. Das ist allerdings noch nicht so lange im Einsatz, wie das eben bei Passkeys eine Rolle spielt. Und da ist es dann noch mal problematischer. Wenn ich das nur lokal habe, dann kann ich bei meinem Gerät, wenn ich mein Gerät verliere, dann kann ich das nicht backupen und dann habe ich halt meine Credentials verloren und muss mir mühsam wahrscheinlich meine Accounts irgendwie wieder zusammen resetten. Und das macht wahrscheinlich keinen Spaß.

Christoph: Zusammengefasst für die 0815 User und Userinnen ein völliges Problem, weil man braucht mehrere Geräte, man muss Geld investieren und man muss sich um Backups kümmern. Alles Dinge, die diese Leute vielleicht eigentlich gar nicht so machen, weil das nicht so ihr Spielzeug ist, wo sie sich den ganzen Tag mit beschäftigen, sondern irgendwie so ein Gerät, was irgendwie nützlich ist. Aber ich will nicht drei Geräte haben, um die Möglichkeit zu haben. Nicht Computer und Telefon und USB-Stick und so weiter. Das haben wir noch mal kurz zusammengefasst, wo überhaupt das Problem ist. Warum man sich darum kümmern sollte, und du hast dich jetzt in deiner Masterarbeit um das Thema gekümmert. Um was geht die denn genau? Am besten stellst du die vor, bevor ich das sage. Ich weiß das gar nicht so wie du.

Sonja: Der Titel ist ein bisschen reißerisch, da habe ich “Passkeys: Die Zukunft der Authentifizierung im Web?” angekündigt. Eine Frage, die ich, das kann ich da schon mal spoilern, nicht abschließend beantworten konnte, weil das einfach noch so viel in der Entwicklung ist. Aber kommen wir in der Diskussion noch drauf. Und mich hat besonders das Spannungsfeld zwischen Usability und Security interessiert, weil mit dieser Allgegenwart des Passworts und bei “Ich habe bestimmt 100 Accounts im Web”. Durchschnittlich haben Nutzer:innen so 70 bis 80, sagen Untersuchungen. Und fast alle basieren hauptsächlich auf Passwörtern. Manche haben dann noch einen zweiten Faktor. Das ist frustrierend, dass es da keine gute Lösung gibt, die zugleich sicher ist oder auch gut benutzbar. Auch wenn man Tools benutzt. Passkeys sind vor einem Jahr, im März 2022 hat die FIDO Alliance quasi ein White Paper dazu veröffentlicht, wo sie dieses Konzept vorgestellt haben. Und die versprechen genau das, dass eben diese Kluft vielleicht sogar zwischen Usability und Security. Auf der einen Seite die WebAuthn mit Hardware Security Tokens, die einfach relativ schlecht für die breiten Nutzer:innen nutzbar sind. Und auf der anderen Seite die Security Flaws von Passwörtern möchten die irgendwie so zusammenbringen, dass es da einen Sweet Spot gibt, dass man jetzt sagt: Okay, wir haben eine Lösung, die ist sicher, die ist für alle gut nutzbar, die wird jetzt auf jeden Fall Passwörter verdrängen vom Markt. Das wird sich dann im nächsten Jahr noch zeigen. Die Frage ist wahrscheinlich jetzt erst mal. Worauf ich gestoßen bin bei meinen Untersuchungen, als ich dazu recherchiert habe, ist, dass es einen ganzen Forschungszweig gibt. Das ist Usable Security, der sich genau um dieses Thema kümmert, um dieses Problem, dass anscheinend nicht zusammenzudenken ist. Es gibt da sehr viele Stimmen, die sagen, das liegt vielleicht nicht daran, dass es keine Lösungen gibt, sondern dass Nutzer:innen nicht von Anfang an mitgedacht werden bei Security Themen und dass es mit diesem Trade off zwischen Usability und Security eigentlich ein Mythos ist.

Christoph: Ich kenne das auch, wenn man sich mit den Leuten aus der Security Community, die aus der Technikecke kommen, unterhält. Dann heißt es immer: Ja, das ist immer ein Verlust an Usability, wenn es sicher sein soll und das ist in der praktischen Umsetzung auch oft so, dass viele Dinge dann umständlicher werden, wenn sie sicher sein sollen. Aber das muss nicht so sein. Mein Lieblingsbeispiel dafür ist, das mache ich immer, wenn ich so Trainings gebe, als Apple den Fingerabdrucksensor eingeführt hat. Touch ID auf dem iPhone. Heutzutage ist es dann Face ID zum größten Teil, aber es ist wahrscheinlich übertragbar. Da gab es mal eine Untersuchung. Vorher, bevor es das gab, das war in den USA. Irgendwie hatten ungefähr um die 20% oder sogar etwas weniger einen Pin-Code, dass das gesperrt ist. Und das heißt, die, die das nicht hatten, da konnte man das Telefon, wenn es geklaut wurde, auch sofort benutzen, weil es überhaupt keine Zugangssperre gab. Und dann kam man mit der Touch ID raus, also Fingerabdruck Scan, und seitdem hatten das dann weit über 80% eingeschaltet, weil es nämlich sogar nicht nur die Usability schlechter gemacht hat, sondern einfacher. Ich brauchte nur meine Finger drauflegen, ich musste nicht noch meine PIN eingeben, was eigentlich länger dauert als eben den Finger auf den Button zu legen und dann ist es entsperrt. Und es ist aber trotzdem noch so sicher, dass wenn es geklaut wird, dass es dann erst mal nicht zugänglich ist. Jetzt können natürlich die, wo der Aluhut etwas größer ist als bei mir, sagen: Fingerabdrücke kann man auch fälschen. Und man hat auch nur zehn davon. Das stimmt. Aber für so ein Consumer Massengerät ist natürlich der Schutz vor Dieben, dass die da nicht so einfach rankommen an die Daten, wahrscheinlich der allergrößte Use Case, den ich abdecke und wenn ich dann ein investigativer Journalist bin, dann muss ich mir vielleicht auch was anderes überlegen, das ist schon klar. Die Verbesserung der Security hat gleichzeitig zu einer besseren Usability geführt. Seitdem finde ich, das sollte immer mit das Ziel sein davon, dass es beides macht. Und wir hatten vorher im Vorabgespräch auch noch mal so ein schönes Zitat gefunden. Das finde ich auch super. Das werde ich jetzt glaube ich auch in Zukunft immer in die Trainings mit reinnehmen. Wenn es nicht bedienbar ist, ist es auch nicht sicher. Von Angela Sasse, die in Bochum an der Universität lehrt, im Bereich IT Security, die aber von Haus aus aber Psychologin ist und die sich Usability Themen auf die Fahne geschrieben hat. Das finde ich super. Hattest du in deiner Arbeit auch noch mal ein paar andere Beispiele für Usable Security dabei?

Sonja: Ja, genau. Ich könnte dazu noch ergänzen. Sie ist da eine große Stimme, die ist mir da immer wieder begegnet. Eins ist auch noch: Users are not the enemy. und dass teilweise eben Hacker:innen mehr sich in die Nutzer:innen hineindenken als die Menschen, die für die Security zuständig sind. In Kurz könnte man sagen, dass es einfach der Ansatz dabei ist, dass die Sicherheit einfach bei den Systemen liegen soll und nicht die Verantwortung auf die Nutzer:innen abgewälzt werden wird. Und ein Beispiel, das ich da auch noch gefunden habe, ist so ein bisschen, wenn Systeme oder kommerzielle Anwendungen auf Nutzer:innenteraktionen angewiesen sind, dann achten sie viel mehr auf backendseitigen Schutz und machen nicht so komplizierte Password Policies zum Beispiel, die es Nutzer:innen wieder total schwer machen sich ein Passwort aus den Fingern zu saugen oder vielleicht auch gar nicht mit dem Passwort Manager abdecken können, weil dann das eine Sonderzeichen nicht erlaubt ist. Aber sonst muss man ganz viele noch einfügen und es darf nicht länger sein als so, aber auch nicht kürzer sein als so. Und das ist auch so ein Faktor. Da hat man untersucht und festgestellt, dass die krassesten Password Policies die wirklich am unnötig schwierigsten waren. Diese Anwendungen kamen von Unis, die eigentlich nicht so extreme High Security Systeme waren. Wenn man abhängig ist davon, dass die Menschen das wirklich benutzen, dann denkt man vielleicht auch ein bisschen mehr mit, als wenn so ein Gewinn zum Beispiel dranhängt. Bei den Forschungen zu Passwörtern geht es viel in die Richtung, wie die Nutzerinnen mit Passwörtern umgehen. Und da hat man festgestellt, bei einem Experiment zum Beispiel, dass es einfach auch eine extreme kognitive Last ist für Menschen, sich Passwörter auszudenken, die komplex sind. Dass es einfach wirklich nicht dem klassischen Denken entspricht, sich sowas auszudenken und zu merken. Das hat man an der Pupillenänderungen festgestellt. Weitere Forschungen dazu sagen, dass es tatsächlich so ist, dass Menschen sich dann versuchen, herauszuwinden. Wenn man eine komplizierte Passwort Policy hat, dann denkt man sich eins aus, aber man kann es sich nicht mehr merken und deswegen nimmt man das Passwort für alle Dienste, die man kennt. Und das ist natürlich nicht so ideal. Und dann gibt es auch noch, das gibt es nicht mehr so oft, aber dass man die Passwörter immer wieder neu vergeben muss, nach drei Monaten oder so, hat sich auch herausgestellt, das führt eher zu weniger Sicherheit, weil die Leute dann auch einfach nur einen Buchstaben ändern, in dem Glauben, dass es dann sicherer ist. Das ist es dann natürlich nicht mehr, wenn man sich jetzt schon eine Dictionary Attack, wo dann vielleicht auch einfach die Buchstaben dann noch irgendwie drangefügt werden, die oft geändert werden. Wenn das vorher xyz1 war, dann ist es danach wahrscheinlich xyz2 und dann kann man es auch einfach gleich lassen.

Christoph: Zum Merken nehmen die Leute irgendein Pattern, wo sie dann irgendwie einen Teil verändern können, hochziehen oder ein Datum dran werfen oder sonst irgendwie was und nehmen sich nicht immer ein komplett Neues. Und da können solche Tools, die Passwörter erstellen, ganz gut abbilden. Da kann man zum Beispiel Pattern vorgehen oder bestimmte Teile festmachen, das stimmt. Gut, das, was du so erzählst, ist das, was ich auch öfter mal erzähle. Aber in deiner Arbeit stehen auch Quellen dafür drin. Also noch besser, jetzt kann ich das auch noch belegen.

Sonja: Quellenliste kommt in die Shownotes.

Christoph: Sehr gut, aber das Thema ist sozusagen eine der Motivationen für das eigentliche Thema, und zwar die Passkeys. Vielleicht könntest du mal erklären, was sind denn überhaupt Passkeys und wie sollen die bei den Problemen, die wir jetzt identifiziert haben, denn helfen? Du hast gesagt, das hast du so provokant geschrieben: Sind das die Lösungen? Und schon angedeutet, dass da auch nicht alles grün ist. Aber was verbessern die denn gegenüber dem Status quo?

Sonja: Wir haben schon gesagt, dass die auf dem WebAuthn Standard basieren und dass der WebAuthn Standard auch wirklich einen Standard setzt in puncto Sicherheit. Da muss man eigentlich nichts noch mal verbessern. Aber dass da die Usability so problematisch ist, dass es einfach nicht von vielen angenommen worden ist bis jetzt. Und das hat die FIDO Alliance auch erkannt. Die FIDO Alliance, das muss man dazu sagen, viele Mitglieder sind namhafte große Firmen, die auch ein Interesse daran haben, dass da ordentlich Schutz geboten wird. Zum Beispiel Google, Microsoft, Apple, Amazon und auch viele Passwort Manager sind da dabei, wie OnePassword. Und die haben gemerkt, es hat jetzt nicht funktioniert. Und jetzt mit einem Konzept nachgelegt, wo sie gerade diese Usability Themen adressieren wollen. Dass man das nicht gut backupen kann und dass es vielleicht auch mit Kosten verbunden ist, wenn man sich so Hardware Tokens kaufen muss.

Christoph: Die Hardware Tokens haben hauptsächlich nicht funktioniert. Das war sozusagen das, was die FIDO vorher propagiert hat. Zweiter Faktor kann man nicht mehr phishen. Und das ist alles super sicher und das stimmt auch. Aber er hat sich dann genau deswegen nicht durchgesetzt, weil das Handling nicht funktioniert. Vom Backup angefangen bis zu dem “ich habe vielleicht nicht den richtigen USB-Port oder wo stecke ich den jetzt in mein iPhone rein, das überhaupt kein Port hat?” Und solche Sachen. Ganz viele Detail Probleme, die die Usability eigentlich geschrottet haben.

Sonja: Genau.

Christoph: Und da setzen sie jetzt an.

Sonja: Da setzen sie jetzt an und angesprochen sind konkret die großen Ökosysteme, dass die das quasi auch in ihren Systemen verbauen. Apple, Google und Microsoft sind da am Zug quasi, die Authenticators in die Hardware bzw. das Betriebssystem einzubauen und die so mit ihren Cloud Lösungen zu verzahnen. Das dann in diesem Ökosystem sowohl ein Backup als auch die Synchronisierung möglich ist. Ich bin Apple-Nutzerin, also ich kenne schon diese iCloud Keychain und Google hat mit dem Passwort Manager etwas ähnliches, womit auch schon Synchronisierung von Passwörtern möglich ist. Und das wird quasi jetzt angesprochen, dass das integriert werden sollte und inzwischen auch ist, zumindest bei Google und Apple. Dass, wenn ich einmal auf mein Apple Rechner ein Passkey registriere über Safari, dann wird das automatisch gesynct auf meine ganzen anderen Apple-Geräte, die ich habe. Falls ich mehrere habe.

Christoph: Vielleicht noch einen Schritt zurück. Du sagst, ich habe einen Passkey registriert und der soll den Authenticator ersetzen. Vielleicht noch mal kurz zur Erklärung. Authenticator ist ungefähr das, was der USB-Stick vorher gemacht hat. Die Hardware, die dann das Public Key kryptographisch gemacht hat für eine Anmeldung.

Sonja: Im Prinzip läuft das so, dass ich dann, wenn ich so eine Registrierung anstoßen werde, zeigt er einen UI Flow in dem Browser an und dazwischen bin ich als User:in aber aufgefordert, mich als ich zu identifizieren. Und das mache ich dann über meine biometrische Geste oder auch einen Pin. In meinem Rechner wäre es jetzt hier ein Fingerabdruck. Und dann wird dieses Schlüsselpaar erzeugt und verbleibt dann auf meinem Gerät als der Private Key. Der wird aber gleichzeitig jetzt nicht mehr wie vorher, wo der wirklich auf diesem YubiKey geblieben ist. Jetzt wird er in diesen Cloud Kreislauf geschickt. Da wird dann auch noch mal ein Schlüsselpaar erzeugt und da natürlich auch mit Ende-zu-Ende Verschlüsselung. Aber verlässt quasi jetzt dieses hochsicherheits-mäßige Lokale und wird in die Cloud geschickt. Das ist dann der Usability Vorteil und gleichzeitig ein bisschen die Aufweichung der Security, weil dann natürlich das Cloud System wieder eine Angriffsfläche bietet.

Christoph: Welchen Usability Vorteil habe ich denn jetzt, wenn der Key jetzt das Gerät verlässt und zum Beispiel in der Cloud landet?

Sonja: Dann habe ich den Vorteil, dass ich da meine Credentials tatsächlich gebackuped habe, quasi. Wenn ich dann mein iPhone verliere zum Beispiel, dann sind wir immer noch da und ich kann sie, wenn ich noch ein Apple-Gerät habe und die mit meiner Apple ID verbunden sind, weiter auf einem anderen Gerät nutzen. Wenn ich keins mehr habe, aber ich sollte vielleicht dann noch den Zugang wissen zu meiner Apple ID, die ist auch passwortgeschützt. Irgendwo bleibt man doch an Passwörtern hängen. Dann kann ich mein nächstes Gerät dann einfach wieder damit verknüpfen und habe dann wieder Zugang zu meinen Credentials.

Christoph: Das heißt dann auch weiterführend, ich muss es ja noch nicht mal verlieren, aber wir Techies besitzen meistens mehr als ein Gerät. Mindestens schon mal Telefon und Computer, manchmal auch mehrere Computer oder vielleicht auch andere Geräte, bzw. zwei aus dem Apple Ökosystem, iPad oder so, dass ich die dann auch synchronisieren kann. Ich muss nicht wie vorher mehrere kaufen, nicht nur wegen Backup, sondern auch vielleicht weil ich die an verschiedenen Stellen benutzen will.

Sonja: Genau, das ist natürlich der Vorteil.

Christoph: Dann habe ich eine Synchronisation über alle Geräte hinweg und habe da nicht die Schwierigkeiten, dass ich vielleicht verschiedene Formen dafür brauche, USBA, USBC, NFC und sonstige Möglichkeiten wie ich das überhaupt an meine Geräte kriege, sondern das ist dann einfach da.

Sonja: Genau, und das geht auch superschnell. Vielleicht kann man da noch als weiteren Vorteil ergänzen, dass man sich auch über Geräte hinweg authentifizieren kann. Es muss natürlich dann in dem entsprechenden Browser auch implementiert sein. WebAuthn immer noch. Da hat sich am Standard gar nicht viel geändert. Das sind die anderen Systeme, die das dann ergänzen oder Passkeys zu machen. Und wenn ich jetzt zum Beispiel aber mich gerne lieber meinem Desktop Rechner mit Google Chrome, dem Browser, arbeite, dann kann ich, sofern ich schon einen iCloud Key registriert habe und ein iPhone habe, ein Kamera-fähiges Gerät, kann ich mich dann auch über den Umweg eines QR-Codes (den ich scanne und es muss auch noch dabei Bluetooth aktiviert sein), kann ich mich also quasi auch Cross-Device authentifizieren. Das heißt, ich stoße das bei Google Chrome an, ich bekomme dann den QR-Code, ich scanne den, würde mich dann mit meinem iCloud Key und dieser entsprechenden Geste, wenn ich mein Smartphone benutze, hätte ich dann so einen Gesichtsscan, damit wieder authentifizieren und dann wäre ich damit angemeldet und könnte dann wiederum bei Chrome einen lokalen Key ergänzen, damit ich mich nicht in Zukunft immer über diese zwei Geräte authentifizieren muss. Das ist dann im ersten Einrichtungsschritt etwas umständlich und danach ist es aber wieder ganz easy, weil dann kann ich mich wieder ganz normal mit meinem Fingerabdruck anmelden.

Christoph: Das heißt, ich kann auch aus dem Walled Garden von Apple, Google rauskommen, weil das Problem ist, wenn ich das richtig verstanden habe, was gelöst wird, dieses iCloud Zeug kann ich bei Apple Geräten und Apple Software kann ich das synchronisieren, aber nicht mit Google oder nicht mit Microsoft.

Sonja: Genau.

Christoph: Aber vielleicht besitze ich doch verschiedene Geräte mit verschiedenen Betriebssystemen oder verschiedene Browser.

Sonja: Genau.

Christoph: Dann bekomme ich damit auch keine größeren Probleme. Kameras, die QR-Codes scannen können, sind doch schon bei vielen Geräten dabei. Die meisten Laptops, die Mobiltelefone sowieso und auch die meisten Tablets haben wahrscheinlich auch eine Kamera. Das geht. Und wozu brauche ich dazu noch Bluetooth?

Sonja: Das ist wieder so ein Schutzmechanismus, um die physische Nähe zu garantieren, dass das nicht irgendwie über weite Wege hinweg dann doch irgendwo abgefangen werden kann.

Christoph: Dass ich nicht darauf reinfalle, wenn mir irgendwer irgendwelche QR-Codes präsentiert, die ich aus Versehen scanne und auf OK klicke. Oder nur mein Gesicht davorhalte, um zu schauen, was ist, und ich habe jemand anderen authentifiziert. Das ist so ähnlich wie bei der Corona Warn App, um zu zeigen, man ist nah genug dran, nicht in kompletter Ferne. Da wird es auch über Bluetooth gemacht, die Kontaktherstellung. Das ist nicht schlecht, aber es werden dann schon neue Keys erstellt. Eine richtige Synchronisierung ist das eigentlich nicht über die Geräte?

Sonja: Genau. Wenn ich das dann wieder lokal nutzen will bzw. diesen Umweg gehen will, dann muss ich mir dann wieder ein lokalen Key erstellen. Das ist bei den Browsern relativ ähnlich, das heißt, es wird mir auch bekannt vorkommen, aber ich bin dann angemeldet. Ich würde dann sagen einen neuen Key erstellen und werde dann durchgeleitet und habe am Ende dann wieder einen neuen Passkey registriert, also quasi bei dieser Relying Party dann erst mal schon zwei Keys.

Christoph: Im Backend bin ich unter mehreren Keys bekannt.

Sonja: Genau, aber die kriegen natürlich nicht meinen Private Key, sondern nur meinen Public Key.

Christoph: Ja, aber die haben dann zwei Public Keys?

Sonja: Genau.

Christoph: Gut. Ein weiteres Feature, was wir so auch im Vorgespräch nochmal angesprochen haben, ist, dass man aber auch die Sicherheit wieder erhöhen kann, indem man sogenannte Device-bound Keys nimmt. Was verbirgt sich denn dahinter?

Sonja: Genau, das ist dann quasi wieder noch mal ein kleiner Schritt zurück. Das ist die Möglichkeit, wenn man sagt: Okay, das wird mir jetzt ein bisschen zu unsicher und ich kann dann nicht mehr feststellen, ob es wirklich von einem korrekten Device kommt oder vielleicht ist es doch irgendwo gehackt und dann ist jemand Fremdes unterwegs. Dass es doch wieder ein an Hardware gebundenes Key Pair erzeugt und nur in dem Zusammenspiel darf ich mich dann tatsächlich anmelden. Das ist noch im aktuellen Draft von dem Standard aufgenommen. Bisher wird auch eine Beta in der ganz neuen Android Version schon unterstützt und in allen anderen Systemen noch nicht. Das ist auf jeden Fall noch ein ganz neues Ding. Das soll aber definitiv in der Breite in allen Systemen auch kommen, weil das eben auch die Forderung ist, dass es vielleicht auch für manche Anbieter einfach dann ein ausschlaggebendes Kriterium ist, überhaupt Passkeys als Authentifizierung zu erlauben.

Christoph: Ich kann mir das schon vorstellen, im Firmenkontext, dass zum Beispiel dann nicht die Schlüssel, die man dann im privaten Bereich benutzt. Es gibt so: Bring Your Own Device-Modell, dass man da private Accounts gemischt hat mit anderen, dass die da nicht auf einmal in die Synchronisation kommen und dann in den Familien Account kommen und die Kinder Zugriff auf irgendwelche Systeme hätten. Das ist dann im professionellen Geschäftsumfeld dann vielleicht auch eine gute Idee, dass man die dalässt. So, Passkeys sind jetzt mal zusammengefasst als Ersatz für YubiKeys oder NitroKeys, die das Ganze in Software implementieren und die Nachteile so aufheben sollen. Dass man das nicht synchronisieren kann, zwischen Geräten keine Backups haben kann, dass man keine Extrakosten hat und kurz gesagt alle Usability Probleme, die bis jetzt an die Verbreitung verhindert haben, erst mal aufhebt. Und neben der Erklärung, was das ist, hast du in deiner Arbeit auch eine kleine Implementierung mitgeliefert. Wozu war das denn gut?

Sonja: Du hast gesagt, das löst alle Usability Probleme und ich würde das nicht uneingeschränkt unterschreiben, weil tatsächlich ist es auch so, dass das momentan auch wieder Besitz erfordert und das ist was, was nicht inklusiv ist. Ich kann nicht von allen Leuten erwarten, dass sie erstens überhaupt ein Smartphone oder einen Rechner haben. Es gibt immer noch Menschen, die besitzen keine Computer, in welcher Form auch immer. Auch, dass sie diese spezielle Hardware haben. Es hat einfach nicht jeder die teuersten und neuesten Systeme von Apple und Google, Microsoft. Und das schließt einfach viele Leute dann doch aus. Und deswegen war meine Idee, das ist jetzt auch so ein Zwischenstand, weil das ganze Thema immer noch sehr stark in Entwicklung ist, dass man das nicht als ausschließliches Authentifizierungs-Verfahren anbieten kann. Man muss auf jeden Fall die Möglichkeit haben, noch ein alternatives Verfahren zu haben. Und da habe ich mich jetzt auch erst mal für ein Passwort entschieden. Und das würde ich gerne auch noch verproben. Dass beide Verfahren angeboten werden und da aber auch auf die Psychologie spekuliert wird, dass man Leute auch überzeugen kann von dem neuen Verfahren, wenn sie die Möglichkeit haben. Es ist so, wenn meine Hardware oder mein Webbrowser das gar nicht kann, dann komme ich gleich auf einen Passwort-Login. Ich habe kein Frustrationserlebnis, weil ich das eigentlich machen möchte, aber ich kann es nicht machen, weil mein Rechner da nicht mitmacht. Und wenn das aber grundsätzlich möglich ist, bekomme ich beide Verfahren zur Auswahl. Und ich hatte da irgendwie zwei Gedanken. Das ist einerseits, dass es die Inklusion ermöglicht. Deswegen gibt es überhaupt ein Passwort Login und dass es auf der anderen Seite auch gezeigt wird, dass Menschen das eher nutzen. Ein neues Verfahren, man ist vielleicht auch skeptisch, wenn man das einfach jahrelang gewohnt ist, dass sie sich trotzdem für das neue Verfahren entscheiden, wenn man sie dazu vorsichtig ermuntert durch gute, verständliche Texte, nicht zu technisch. Weil auch das war so ein bisschen das Ergebnis dieser Usable Security Forschung, dass Menschen einfach dann fremdeln mit zu viel Technik Overload und gerne Dinge auch verstehen, aber das ist was, es ist sehr technisch und kompliziert und deswegen habe ich mich dann da entschieden, das sehr knapp und in Abschnitten über Usability und Security zu beschreiben. Und bei dem Angebot von Passwörtern dann auch ein bisschen zu warnen vor Security Nachteilen von Passwörtern. Und dass man die idealerweise nur dann nutzen soll, wenn man auch einen guten Passwort Manager hat, zum Beispiel. Und deswegen ist es dann darauf hinausgelaufen, beides anzubieten. Und so ist es auch was, was ich bisher auf der Web-Landschaft gesehen habe bei den wenigen Unternehmen, die das schon anbieten, dass auf jeden Fall das Passwort auch immer noch da ist. Aber meine Idee war dann aber schon auch, dass man, wenn man sich einmal für das Passkey-Verfahren entschieden hat, man nicht nachträglich noch ein Passwort anmelden kann. Um dann die Sicherheit, die man schon mal hatte, nicht dann noch nachträglich aufzuweichen. Und da habe ich lange darüber nachgedacht, auch diskutiert mit Menschen, weil das natürlich Use Cases gibt, wo es dir dann tatsächlich auf die Füße fallen kann, wenn du dein einziges Apple Gerät, wie in deinem Beispiel, verlierst. Und dann aber auch nicht mehr das Geld hast, dir ein neues anzuschaffen oder vielleicht auch nicht so schnell ein neues bekommst. Und dann sind erst mal alle Credentials futsch. Das Backup ist weg und das ist vielleicht auch was, was bald obsolet wird, weil es auch eine Third Party Integration geben soll oder da auch schon Betaversionen unterwegs sind von Password Managern, die das dann quasi auch wieder entkoppeln würden von den Ökosystemen. Aber, das war so mein Gedankengang dabei zu dieser aktuellen Situation, wo das alles noch sehr am Anfang steht. Dass es noch nicht funktioniert, Passkeys alleine als einzige Wahl anzubieten, weil es einfach sehr exklusiv ist.

Christoph: Ich glaube, da hast du einen ganz wichtigen Aspekt mit dieser Beispielimplementierung angefasst, was auch vielleicht zum Thema Usability gehört. Was wir bis jetzt gesagt haben, war alles so eine Getrennt-Betrachtung. Wir haben betrachtet Passwörter. Die haben ihre Probleme und wir haben dann Zwei-Faktor-Verfahren, die haben die Probleme und dann haben wir gesagt, Passkeys lösen folgende Probleme, aber das Nebeneinanderstehen dieser, sagen wir mal zwei bis x Welten ist natürlich für den User auch eine Überforderung. Dann wäre es: Hier, brauche ich hier mein Passwort oder brauche ich jetzt hier mein Passkey oder brauche ich hier meine SMS als zweiten Faktor, mein Telefon oder meinen OTP Code? All sowas kann leicht eine kognitive Überforderung für die Nutzer:innen sein. Das ist der Usability Teil und gleichzeitig auch natürlich ein Security Teil. Uns nützt es ja nichts, wenn wir sagen: Jetzt benutze Passkeys und trotzdem gibt es als Hintertür das Passwort, was zwar gehasht mit einem passenden Verfahren aber auch auf dem Server liegt und vielleicht doch da entwendet werden kann und dann vielleicht per Brut-Force geknackt wird. Oder auch trotzdem durch eine klassische Phishing Seite, weil es immer noch diese Backdoor gibt. Wir haben doch noch irgendwo ein Passwort und ich melde mich zwar immer schön brav an, aber die Angriffsfläche ist einfach noch da, dass man das dann einfach auch gar nicht mehr zulässt. Weil ich bin mir auch gar nicht sicher, ob die Leute dann zum Beispiel, soweit es möglich ist, auch ihr Passwort dann sozusagen entfernen, als Zugang und dann nicht einfach alles eingerichtet haben. Haben sie ihr Passwort, dann haben sie mal SMS gemacht, dann haben sie danach hier OTP, haben aber die SMS noch nicht entfernt. Und jetzt haben sie noch Passkeys. Da gibt es auf einmal vier Möglichkeiten, die vielleicht zwar unterschiedliche Angriffsflächen haben und manche auch weniger. Passkeys sind schon durch das Public Private Key Verfahren sehr sicher, aber trotzdem ist alles noch da. Das sind zwei wichtige Aspekte, die man auch in der Praxis sehen muss. Man kann nicht alle Systeme einfach isoliert diskutieren, glaube ich.

Sonja: Das stimmt total.

Christoph: Von daher finde ich das schon ganz cool, dass du das da mal gemacht hast und gerade auch so diese Migration, dass man sagt, man schubst den User so ein bisschen dazu, das ist glaube ich, ein ganz wichtiger Aspekt. So, und was ist denn jetzt als Ergebnis insgesamt herausgekommen? Was ist das Fazit des Ganzen?

Sonja: Ja, das ist vielleicht auch ein bisschen enttäuschend, weil ich kann jetzt nicht… Die Frage, die ich mir am Anfang gestellt habe oder der Titel meiner Masterarbeit, kann ich noch nicht beantworten, weil das alles noch in der Entwicklung ist. Was mich überrascht hat, als ich angefangen habe oder auch im Verlauf, war, dass sich gefühlt so wenig tut. Auf Entwickler:innen-Seite, dass es wirklich nur sehr wenige Implementierungen gibt, die das anbieten. Weil da könnte man auf jeden Fall auch Erfahrungen sammeln und sich Sachen anschauen, wie das dann umgesetzt wird. Zum Beispiel, gibt es einen Fallback als Passwort. Also Google hat es im Mai irgendwann gestartet dieses Jahr. Zum Beispiel, Randnotiz, das fand ich interessant, dass sie nicht darauf geachtet haben, tatsächlich abzufragen, ob da ein eingebauter Plattform Authenticator verfügbar ist. Firefox kann das tatsächlich noch nicht. Das ist der Einzige der gängigen Browser, die Plattform Authenticators nicht implementiert haben oder womit es nicht nutzbar ist. Und es gibt aber eine Methode, die das abfragen kann, ob auf der Plattform ein Authenticator verfügbar ist und entsprechend kann man die User Journey dann schon so lenken, dass das dann nicht als Möglichkeit angeboten wird. Und so werde ich erst mal gefragt, ob ich einen Passkey anlegen möchte. Und im nächsten Schritt kriege ich dann einen Fehler und sowas sollte man zum Beispiel vermeiden. Es ist interessant, dass es auch gerade den Leuten, die das voran pushen wollen, auch passiert. Das finde, ist der enttäuschende Stand jetzt, dass es einfach noch wenig Vergleich gibt und das liegt vielleicht auch daran, das hatten wir jetzt noch gar nicht so richtig angesprochen, dass es developerseitig auch noch relativ wenig gibt, obwohl das alles, wie gesagt, auf diesem WebAuthn Standard aufbaut. Die ganze technische Sachen, die die Webseiten betreffen, überwiegend zumindest, dass es bis jetzt auf diese Device Public Key Geschichte zielt. Das ist alles schon seit Jahren da und es ist interessant, dass es noch zu wenig Libraries und Komponenten gibt, die man noch einbinden könnte. Aber ich habe beobachtet, dass sich da schon jetzt mehr tut. Meine Anwendung war in Ruby und eigentlich wollte ich gerne eine Library einbinden, die praktisch beides abdeckt, WebAuthn und Passwort Authentifizierung. Das kann Rails noch nicht allein auf jeden Fall. Zu dem Zeitpunkt, wo ich gestartet habe, gab es das noch nicht. Und jetzt gerade gibt es auch eine Version von dieser Library, die ich gerne genutzt hätte. Vielleicht bin ich einfach ein bisschen zu früh dran gewesen. Deswegen kann ich mir schon vorstellen, dass sich da jetzt auch ganz schön viel tut, weil das ist natürlich irgendwie das Entscheidende, ob es die Webseiten auch wirklich alle implementieren. Weil, ich kann das noch so gerne als Nutzer:in nutzen wollen, aber wenn es nicht angeboten, wird, kann ich es nicht nutzen. Und im nächsten Schritt entscheidet sich dann, ob es dann auch wirklich so angenommen wird, wie ich mir das vorstellen könnte. Und ein großer Schritt wahrscheinlich zur Zeit der Entwicklung sind diese Third Party Integrationen, das eben dann auch Passwort Manager Passkeys soweit integrieren, dass die dann dieses ganze Synchronisieren übernehmen können. Dass man dann nicht mehr auf ein Ökosystem angewiesen ist. Oder dieses Cross-Device, das ein bisschen umständlich ist, würde dann auch wegfallen. Ich würde sagen, es ist aber wirklich wahnsinnig viel in der Entwicklung. Es geht auch wieder so ein bisschen in die Richtung, dass noch mehr. Ich weiß nicht, wer das pusht, aber von Apple aus gibt es auf jeden Fall auch Moves es noch mehr in Richtung Usability zu schubsen. Zum Beispiel, es wurde auf der letzten Keynote angesprochen, dass es mit dem nächsten OS auch die Möglichkeit geben soll, einen Passkey dann auch mit Freunden und Familie zu teilen und es geht auch jetzt schon über AirDrop. Das ist dann sicher auch wieder ein Vorteil für viele Use Cases aber auch dann wieder genau das was, was wirklich das absolute K.O. Kriterium gegen andere Verfahren und für diesen Standard ist, dass es so Phishing resistent ist. Und das wird dann ein bisschen aufgeweicht. Man kann dann vielleicht nicht so eine Phishing Seite hinbauen, aber Social Engineering Attacken würden wieder ein bisschen mehr Spielraum bekommen.

Christoph: Gerade bei diesem AirDrop-Feature. Das finde ich ein bisschen kritisch, weil dasselbe funktioniert bei WLAN-Passwörtern und das macht man andauernd. Man kommt in der Gruppe irgendwo hin. Da gibt es ein freies WLAN, hat aber ein relativ kompliziertes Passwort. Einer hat es eingetippt und die anderen sharen das einfach. Und das poppt zum Teil auch automatisch auf, weil man in den Kontakten ist. Wenn ich dann genau sowas habe und dann erstelle ich aus Versehen mal so ein Passkey. Ich stelle mir da Angriffsszenarien wie dieses SMS-Bombing vor oder so, dass ich dann schnell genötigt werde, mal den Knopf zu drücken. Dann kann das wahrscheinlich schon ein bisschen schwierig werden. Muss man auch ein bisschen auf die genaue Ausgestaltung gucken, wie weit man das anfordern kann, aber du hast Recht. Wahrscheinlich hat man die richtige Balance noch nicht gefunden, was nötig ist. Ein Use Case für mich ist immer, dass ich so was auch teilen will. Und zwar unkompliziert so Accounts, die in der Familie geteilt werden, der Netflix oder Disney+ Account, wo die Kinder dann vielleicht auch Zugriff brauchen und die gleichzeitig natürlich auch einen hohen Bedarf haben, dass sie nicht an ein Passwort gebunden sind, weil sie dann vielleicht mal auf Geräten eingegeben werden, wie dem Fernseher oder dem Smart TV, die dann irgendwie eine Fernbedienung haben. Leute, die in der richtigen Zeit aufgewachsen sind und ganz schnell SMS tippen konnten auf Nokia, die können das vielleicht, aber ich kann zum Beispiel auf so einem Gerät kein Passwort vernünftig eintippen. Das heißt, da werden die Passwörter natürlich von der Sicherheit deutlich schlechter. Und wenn ich da das habe und das aber auch noch gut teilen kann, dann wäre das natürlich ein großes Plus. Und wahrscheinlich ist es natürlich ein großes Problem, dass man alle Use Cases mit Passkeys abdecken will.

Sonja: Ja, mit Sicherheit.

Christoph: Im professionellen Umfeld zum Beispiel oder ein hoher Sicherheitsbereich, die andere Anforderung haben als ich jetzt zum Beispiel innerhalb des Familienumfelds, wo ich zwar trotzdem sicher sein will, aber vielleicht an vielen Stellen auch eine Aufweichung habe. Das war so wie bei dem, was ich gerade erwähnt hatte, Touch ID und Face ID schützt erst mal da, wenn das Ding gestohlen wird und nicht vor: Ich werde am Flughafen vom Militär einkassiert und man hält mir das einfach vors Gesicht oder drückt meinen Finger darauf. Das sind komplett andere Use Cases. Und alles mit Passkeys zu erschlagen wird glaube ich dann auch noch schwierig.

Sonja: Ja, das stimmt. Und es wird der Versuch gemacht, indem man ihm sagt: Wir haben dann auch noch diese Möglichkeit, noch mal diese Device-bound Keys für die Leute, die ein höheres Sicherheitsbedürfnis haben, zu ergänzen. Solche Anpassungsmöglichkeiten sind sicher eine gute Idee. Und wie du schon sagst, ich denke auch, dass das jetzt noch so ein bisschen sich herausstellen muss oder vielleicht ein bisschen ausbalanciert werden muss, was jetzt ein ganz guter Kompromiss für die meisten ist. Es wendet sich schon explizit eher an Endnutzer:innen würde ich sagen, auch wenn Unternehmen auch mitbedacht werden, um einfach tatsächlich dieses große Ziel, dass man Passwörter loswird, ein bisschen näher zu kommen. Aber ich denke, dass man sich da noch ein paar Jahre gedulden muss, bis die Möglichkeit besteht, dass es so weit kommt. Ich denke, es dauert tatsächlich länger, als ich ursprünglich dachte. Aber ich gebe dem Ganzen schon eine gute Chance, weil einfach auch so eine Markt Power dahintersteckt und jetzt auch einiges in Gang kommt. Vielleicht muss man dann in einem Jahr oder so noch mal ein Follow-Up machen und schauen, ob diese ganzen Gedanken um: Braucht man jetzt irgendwie beides? Das hat sich vielleicht bis dahin erledigt. Da bin ich auf jeden Fall gespannt.

Christoph: Ein Follow-Up bietet sich da bestimmt an, dass wir mal nach Zeitraum X, sei es ein Jahr, sei es vielleicht zwei Jahre, oder anderthalb Jahren. - Sonja: In 30 Jahren, Christoph.

Christoph: Oder in 30 Jahren. Was hat sich alles so getan? Das ist ja schon jetzt so ein bisschen Follow-Up auf unse Passwort- und Passwort Manager-Folgen. Und das ist jetzt die aktuellstee Entwicklung. Und von daher sollten wir auf jeden Fall da noch mal darauf schauen. Das verlinken wir dann auch noch in den Shownotes. Wir hatten uns eine Liste angeguckt, wer das schon alles unterstützt. Und die ist überschaubar. Aber okay, da ist wahrscheinlich nicht jeder drauf, weil die communitygepflegt ist. Aber, das ist noch nicht wirklich groß. Und das heißt, da wird sich hoffentlich noch einiges tun. Oder wenn wir dann in einem Jahr sagen: Die Liste ist um 1% gewachsen, dann ist das vielleicht auch gescheitert. Da interessiert mich noch als letzte Frage, bevor wir das jetzt vielleicht beenden. Du sagtest, die Libraries existieren noch nicht und das ist vielleicht ein Problem, warum sich das auch noch nicht durchsetzt, weil die Entwickler und Entwicklerinnen nicht drankommen. Aber du hast das jetzt schon dafür implementiert und hast gesagt, du wünschst dir das. Aber war das denn so schwer?

Sonja: Es gab eine Library für WebAuthn für Ruby, aber die kann kein Passwort. Das war keine globale Lösung und das wünsche ich mir, wenn ich eine Anwendung bauen möchte und eine Authentifizierung und eine Library einbinde, dann möchte ich, dass die mein komplettes Authentifizierungs-Ding abdeckt. Ich musste das dann noch so verzahnen und da gab es auch Probleme und es hat am Ende dann auch funktioniert, aber es war so ein bisschen hakelig. Ich habe das jetzt machen wollen und müssen, aber es ist sicher niedrigschwellig, wenn man weiß, vielleicht wartet man auch noch ab. Man will da auch nicht eine Alpha-Version in Produktion dann bringen, die sich noch nicht bewährt hat. Vielleicht ist man auch noch skeptisch, denn das ist ein kritischer Bereich.

Christoph: Der Hintergrund meiner Frage ist eigentlich… Meine These wäre: An der Technik scheitert das wahrscheinlich nicht so sehr. Ich meine, die Spec ist schon umfangreich, aber das kriegen wir wahrscheinlich alles hin. Aber was du so gemacht hast, mit passenden Texten und verständlichen Texten die Erklärung zu liefern und die User:innen dahin zu stupsen, den in den 50 Sprachen, die man vielleicht braucht, in der Integration hinzukriegen, finde ich wahrscheinlich den viel schwierigeren Teil, den passend in allen Sprachen zu formulieren und vielleicht auch noch an kulturelle Gegebenheiten anzupassen. Wie man Leute überzeugt, anstatt die Technik irgendwann. Ich glaube, das ist bei dieser ganzen Einführung – ich mag das jetzt ein bisschen flapsig formulieren – ist wahrscheinlich der schwierigere Teil. Weil die Libraries werden auch kommen.

Sonja: Genau. Es ist wahrscheinlich einfach das. Vielleicht ist es auch ein gutes Schlusswort, man sollte bei jedem Security Thema auf jeden Fall und jedem Thema, was bei der Implementierung Nutzer:innen von Anfang an mitdenken und denen entsprechende Angebote machen. Wie wir vorher schon festgestellt haben, Security funktioniert einfach nicht ohne Usability und deswegen hoffe ich einfach, dass sich da jetzt noch mehr tut, weil ich halte das schon für ein ganz guten Schritt.

Christoph: Sehr gut. Ich würde sagen, das nehmen wir auch als Schlusswort. Dann sage ich: Vielen Dank an dich. Vielen Dank an die Hörer und Hörerinnen, die jetzt so lange zugehört haben. Wenn ihr Kritik, Anregungen, Feedback habt oder vielleicht auch Themenvorschläge, dann schreibt uns doch einfach eine Mail an [email protected]. Dann können wir das aufgreifen und es wäre natürlich gut, wenn euch die Folge gefallen hat, dass ihr uns auf den Plattform, wo ihr uns hört, entsprechend gute Bewertungen gebt. Dann können wir auch mehr Reichweite erlangen und dann kommen noch mehr Leute in den Genuss dieses supertollen Podcast. So, und damit sagen wir beide: Tschüss und bis zum nächsten Mal.

Sonja: Bis zum nächsten Mal. Ciao.