Warum der Traum von Passkeys zerbrochen ist
Der Traum
- 2019 begann der Autor mit der Entwicklung einer Webauthn-Bibliothek für Rust
- Damals herrschte Optimismus, dass diese Technologie Passwörter ersetzen könnte
- Man erwartete Unterstützung für Zwei-Faktor-Authentifizierung, passwortlose Authentifizierung und benutzernamenlose Authentifizierung
- Die vom Autor entwickelte Bibliothek hatte großen Einfluss auf die Branche
Warnsignale
- Chrome dominiert den Markt, sodass alles, was Chrome nicht unterstützt, faktisch aus dem Standard herausfällt
- Die Authenticator Selection Extension ist ein typisches Beispiel
- Problematisch ist auch, dass wichtige Entscheidungen bei persönlichen Treffen in den USA getroffen werden
- Dadurch werden internationale Teilnehmende ausgeschlossen
Abwärtstrend
- 2022 stellte Apple Passkeys vor
- Anfangs wirkte das Konzept gut gestaltet, doch spätere Aussagen der Verantwortlichen definierten Passkeys als Resident Key
- Das führte dazu, dass Security Keys mit wenig Speicherplatz ausgeschlossen wurden
- Danach wurden Passkeys zunehmend zu einem Mittel, Nutzer an Plattformen zu binden
Die Lage verschlechtert sich
- Chrome und Safari drängen zur Nutzung von caBLE statt von Security Keys
- Ein Ansatz mit sehr schlechter Usability
- Android verhindert auf Websites mit Passkey-Unterstützung die Nutzung von Security Keys
- Entwicklerbeispiele lenken dazu, nur Google Passkeys zu verwenden
- Nutzer haben große Schwierigkeiten bei der Verwendung von Passkeys
- Es treten Bugs, komplexe Abläufe und verlorene Schlüssel auf
- In Apple Keychain werden Passkeys häufig gelöscht
Ausblick
- Der Autor erwartet, dass Passkeys für normale Verbraucher scheitern werden
- Das Gewinnstreben der Unternehmen beschädigt die User Experience
- Sogar der Partner des Autors sagt, dass Passwörter besser seien als Passkeys
- In Unternehmen werden weiterhin Security Keys benötigt, doch die Usability-Probleme bleiben bestehen
- Der Autor wird das Projekt
webauthn-rs weiter pflegen, sucht aber nach anderen Ansätzen statt Passkeys
Meinung von GN⁺
- Es ist besorgniserregend, dass sich Passkeys in eine Richtung entwickeln, in der Security Keys ausgeschlossen und die Plattformabhängigkeit vertieft werden. Die Wahlfreiheit der Nutzer einzuschränken, erscheint nicht wünschenswert.
- Neben der Weiterentwicklung der Technologie scheint auch eine Verbesserung der Usability notwendig zu sein. Das Ganze sollte weder übermäßig komplex noch unnötig restriktiv werden.
- Dass der Einfluss weniger Unternehmen wächst und dadurch Probleme im Standardisierungsprozess entstehen, wirkt ebenfalls dringend lösungsbedürftig. Eine offenere und transparentere Entscheidungsstruktur wäre wünschenswert.
- Die als Alternativen genannten Geräte-Zertifikate oder Smartcard-Ansätze wirken interessant. Sie könnten die Grenzen bestehender Passkeys überwinden und zugleich die Usability verbessern.
- Da wir uns noch in einer Übergangsphase befinden, dürfte es weiterhin auf technische Fortschritte und die Aufnahme von Nutzerfeedback ankommen. Hoffentlich arbeiten unterschiedliche Interessengruppen zusammen, um ein besseres Authentifizierungssystem zu schaffen.
3 Kommentare
Eine passwortlose Zukunft kommt
Passkey in Chrome vorgestellt
Hacker-News-Meinungen
Das größte Problem mit Passkeys ist, dass man den Unternehmen, die sie anbieten, nicht vertrauen kann. Aus Sicherheitsgründen sind sie an die Plattform gebunden, aber oft ist das kaum von Plattformbindung zu unterscheiden. Wenn man auf einem Apple-Gerät einen Passkey erstellt, kann er dieses Gerät offenbar nie wieder verlassen, und es gibt keine Möglichkeit, das zu ändern. Das schützt zwar vor Phishing, aber was passiert, wenn Apple den Schlüssel löscht oder ich mein iPhone entsorgen will?
In langen Diskussionen über Passkeys sieht man eine merkwürdige Ausweichbewegung beim Sicherheitsaspekt des „Wissens“. In den USA können Gerichte und Strafverfolgungsbehörden Nutzernamen, Fingerabdrücke, Netzhautscans, Face ID usw. rechtmäßig erlangen, aber sie haben kein Recht, etwas aus dem Gehirn zu extrahieren. Passkeys bevorzugen es, „etwas, das man weiß“ durch „etwas, das man hat“ zu ersetzen, und das ist sicherheitstechnisch ein Albtraum.
Gegenposition: Ich liebe Passkeys. Ich nutze den Firefox-Browser und den 1Password-Manager, auf dem iPhone nutze ich 1Password + Firefox. Über passkeys.directory habe ich Logins bei GitHub, Google, Microsoft usw. auf Passkeys umgestellt. Formulierungen wie „Mit Passkey anmelden“ statt „Mit Touch ID anmelden“ sorgen für Verwirrung. 1Password synchronisiert Passkeys zwischen Geräten. Wenn ich mich an einem öffentlichen Computer anmelden muss, kann das unpraktisch sein, aber das kommt nicht oft vor.
Ich meide Passkeys bisher, weil es noch kein klares mentales Modell dafür gibt. Ich nutze bereits zufällige Passwörter, die mein bestehender Passwortmanager erzeugt, daher sehe ich keinen zwingenden Grund zum Umstieg. Benutzername/E-Mail + Passwort verstehe ich, aber wenn ich mich an den Schmerz von „app-spezifischen Passwörtern“ erinnere, mache ich mir Sorgen, dass sich manche Open-Source-/CLI-Tools nicht gut mit Passkeys integrieren lassen. Daher ist es vielleicht besser zu warten, bis sich die Lage stabilisiert.
Ich bin vollständig im Apple-Keychain-Ökosystem und habe mehrere Apple-Geräte, daher sind Passkeys großartig. Als Entwickler erlebe ich täglich die Grenzen des schwachen SMS-2FA. Nutzer lassen sich durch Social Engineering leicht dazu bringen, ihre 2FA-Codes weiterzugeben. Passkeys bieten eine sicherere Lösung, sodass Entwickler sich keine Sorgen machen müssen, dass Nutzer Codes am Telefon dem Kundensupport laut vorlesen. Passkeys werden nicht durch SIM-Swapping kompromittiert, und man kann sie nicht mit Betrügern teilen.
Als technisch versierte Person weiß ich immer noch nicht genau, wie Passkeys funktionieren, warum sie besser sind und was sie eigentlich genau sind. Wenn eine Sicherheitsfunktion nicht so einfach ist wie Benutzernamen und Passwörter zu merken und an einem sicheren Ort zu speichern, wird sie nicht funktionieren. Es wird von einem Schlüssel auf dem Gerät gesprochen, aber wenn ich sowohl ein Handy als auch einen PC nutze, frage ich mich, wie ich darauf zugreife, ob ich anfangs Benutzername/Passwort brauche und ob ich einen Schlüssel benötige, den ich ins Gerät einstecken muss.
Usernameless wirkt wie eine übertriebene Optimierung. Es ist vernünftig und gut, wenn Nutzer beim Login einen Benutzernamen verwenden. Das erinnert sie daran, welchen Benutzernamen sie überhaupt nutzen. Es kann passieren, dass jemand mit einem Usernameless-Passkey auf einen Dienst zugreift, dann aus irgendeinem Grund den Passkey verliert und außerdem den Benutzernamen für den Dienst vergisst, sodass der Prozess zur Kontowiederherstellung gar nicht erst gestartet werden kann.
Wer die technische Funktionsweise von Passkeys nicht kennt, sollte sich diesen Implementierungsleitfaden ansehen: https://webauthn.guide/ Ich verstehe den Hass auf Passkeys nicht. Für die Authentifizierung auf Public-Key-Challenges umzusteigen, ist ein großer Fortschritt für die Websicherheit. Jeder Browser bzw. jedes OS schützt und sichert den privaten Schlüssel. Selbst wenn man den Schlüssel verliert, kann man über den Ablauf „Passwort vergessen“ die Anmeldedaten zurücksetzen.
Damit ich den Einsatz von Passkeys in Betracht ziehe, müssen folgende Anforderungen erfüllt sein:
Ich habe nicht geprüft, ob die WebAuthn-Implementierungen in Firefox oder Chrome unter Linux diese Anforderungen erfüllen.
Ich versuche, die Entwicklungen im 2FA-Bereich zu verfolgen, und Passkeys waren am verwirrendsten. Ich habe viel Hype darüber gesehen, dass Passkeys die nächste Generation seien, aber es war schwer, Erklärungen dazu zu finden, was sie tatsächlich sind und wie sie funktionieren. Als ich erfuhr, dass es sich um auf einem Sicherheitsschlüssel gespeicherte Schlüssel handelt, war ich enttäuscht. Die Idee, Schlüssel spontan auf Basis von Domainnamen zu erzeugen, gefällt mir. Der Vorteil von Passkeys ist, dass man sich nicht den Benutzernamen merken muss, den man auf einer Website verwendet, aber das ist nur ein kleiner Vorteil.
Auf eine verwandte Frage nach dem offiziellen Namen für die Technik, bei der Schlüssel auf Basis von Domainnamen spontan berechnet und rekonstruiert werden (FIDO2-basiert? WebAuthn-basiert?), fand ich die Antwort hier: https://fy.blackhats.net.au/blog/… Dort werden spontan rekonstruierte Schlüssel als „non-resident credential“ bezeichnet.