Passkeys neben Passwörtern, ohne jemanden zu verwirren
Wie EAuth Passkey und Passwort auf einer Login-Seite anbietet, warum das Passwort bleibt und wovor ein Passkey schützt, was ein Passwort nicht kann.
Jede Anwendung, die sich über EAuth anmeldet, bietet Passkeys an, neben dem Passwort, auf derselben Seite. Niemand muss umsteigen, niemandem muss man erklären, was ein Passkey ist, bevor er einen nutzen kann, und das Passwort verschwindet nicht. Dieser Beitrag handelt davon, wie die beiden nebeneinander leben, denn genau dort gehen die meisten Passkey-Einführungen schief.
Was ein Passkey ist, in einem Absatz
Ein Passkey ist ein Schlüsselpaar. Die private Hälfte bleibt auf dem Telefon, dem Laptop oder dem Security Key der Person, geschützt durch die Sperre des Geräts: Fingerabdruck, Gesicht oder PIN. Die öffentliche Hälfte wird bei der Site registriert. Beim Login schickt die Site eine Challenge, und das Gerät signiert sie, nachdem die Person es entsperrt hat. Die Site sieht nie ein Geheimnis, also kann aus unserer Datenbank nichts durchsickern, und der Browser bindet den Passkey an eauth.me, sodass eine kopierte Login-Seite auf einer anderen Domain nichts bekommt, was die echte annimmt. Diese letzte Eigenschaft kann ein Passwort nicht haben: Wer sein Passwort in eine überzeugende Kopie der Seite tippt, hat es verraten; ein Passkey funktioniert dort schlicht nicht.
Eine Seite, zwei Wege hinein
Die Login-Seite von EAuth zeigt die Felder für E-Mail und Passwort und darunter „Sign in with a passkey“. Das ist die ganze Oberfläche. Der Button erscheint erst, wenn das Skript der Seite geprüft hat, dass der Browser einen Passkey nutzen kann. Ein Browser, der das nicht kann, zeigt also nie einen Button, der nichts tut.
Dahinter verlangt die Seite vom Browser Conditional Mediation. Das E-Mail-Feld ist mit username webauthn markiert, und ein Browser, der einen Passkey für eauth.me hat, bietet ihn unter den Vorschlägen dieses Felds an, so wie er ein gespeichertes Passwort anbietet. Ein Browser ohne Passkey zeigt nichts zusätzlich. Niemand tippt zuerst eine Adresse ein: Der Passkey, den die Person wählt, bestimmt das Konto. Wer einen Passkey hat, nutzt ihn mit einem Tippen; wer keinen hat, sieht eine normale Login-Seite.
Es gibt keinen separaten „passwortlosen“ Modus, den man aktivieren muss, und keine Abfrage bei jedem Besuch, ob Sie nicht einen einrichten möchten. Eine solche Abfrage gewöhnt Leute daran, Dialoge wegzuklicken, und das ist das Gegenteil dessen, was Sicherheit braucht.
Wo ein Passkey entsteht
Auf der Kontoseite, unter Security, neben dem zweiten Faktor. Wer einen hinzufügt, wird zuerst nach dem Passwort gefragt. Ein Passkey ist ein Zugang, der eine Passwortänderung überdauert. Ein Browser, in dem jemand angemeldet geblieben ist, darf also nicht genügen, um einen zu hinterlassen, und falsche Passwörter werden dort gezählt: fünf pro Konto in fünfzehn Minuten. Dann erzeugt das Gerät den Schlüssel. Die Person kann ihm einen Namen geben, „MacBook“ oder „iPhone“, damit die Liste auch ein Jahr später etwas bedeutet; ohne Namen wird er nach Browser und Plattform benannt. Jede Ergänzung wird an die Adresse des Kontos gemailt, zusammen mit dem, was zu tun ist, falls man es nicht selbst war.
Entfernen ist ein Button und eine Bestätigung. Eine Untergrenze gibt es nicht: Eine Person darf ihren letzten Passkey entfernen, denn sie hat noch ihr Passwort.
Passkeys, die auf einem Telefon oder Laptop entstehen, werden meist von der Plattform, von Apple oder Google, auf die anderen Geräte der Person synchronisiert. EAuth hält fest, ob ein Passkey synchronisiert ist, und markiert das auf der Kontoseite, denn es ändert, was der Verlust eines Geräts bedeutet: Ein synchronisierter Passkey überlebt ihn, ein Passkey auf einem Hardware-Key nicht. Der Export der Daten einer Person, den eine Anwendung für eine DSGVO-Anfrage erstellt, trägt dieselbe Markierung.
Ein Hardware-Key führt ausserdem einen Zähler, der mit jeder Nutzung steigt. Steigt er nicht, wurde der Key möglicherweise kopiert, und EAuth verweigert dann nicht bloss dieses Login: Es entfernt den Passkey, denn eine Kopie würde weiter funktionieren, und sagt der Person, sie solle sich mit ihrem Passwort anmelden und einen neuen hinzufügen. Synchronisierte Passkeys führen keinen Zähler und werden nicht als Kopien behandelt.
Warum das Passwort bleibt
Zwei Gründe, und keiner davon ist Nostalgie.
Die Geräte einer Person ändern sich. Ein neues Telefon, auf dem das Plattformkonto noch nicht angemeldet ist, ein geliehener Laptop, ein Firmenrechner mit abgeriegeltem Browser: Jedes davon ist ein Moment, in dem der Passkey nicht zur Hand ist. Das Passwort ist dann der Weg hinein, und der zweite Faktor gilt dafür weiterhin.
Wiederherstellung muss es geben. Bleibt das Passwort, verliert man mit einem Passkey nichts: Das Konto hat noch sein Passwort, und ein vergessenes Passwort wird wie bisher über einen Link an die bestätigte Adresse zurückgesetzt. Fiele das Passwort weg, müsste die Wiederherstellung allein auf diesem Link beruhen, und der ist schwächer als beides. Mit dem Passwort ist der Passkey ein Schritt nach oben, nicht einer zur Seite.
Was er nicht tut
Ein Passkey ist kein zweiter Faktor für das Passwort. Ein Passkey, dessen Gerät die Person geprüft hat, mit PIN, Fingerabdruck oder Gesicht, ist für sich allein vollständig: etwas, das sie hat, und etwas, das sie weiss oder ist. Ein Passkey, der nur eine Berührung registriert hat, wie es manche Security Keys tun, zählt als ein Faktor, und ein Konto mit eingeschaltetem zweitem Faktor wird nach seinem Code gefragt, wie nach einem Passwort. Wer sich mit dem Passwort anmeldet, wird weiterhin nach dem Code gefragt, falls er einen eingerichtet hat. Die beiden sind getrennte Wege.
Ein Passkey ersetzt auch die Limits auf dem Passwortformular nicht. Wer den Passkey ignoriert und Passwörter rät, stösst auf dieselben Limits wie bisher: zwanzig falsche Passwörter pro Konto in fünfzehn Minuten von überall, fünf von einer Adresse, gezählt, bevor das Passwort geprüft wird. Die Passkey-Anfragen teilen sich das Limit pro Adresse von dreissig Login-Anfragen pro Minute, ein Passkey neben dem Formular öffnet also nichts zusätzlich.
Für Entwickler
An Ihrer Integration ändert sich nichts: keine Einstellung, kein SDK-Aufruf. Wer sich mit einem Passkey anmeldet, bekommt denselben Authorization Code und dasselbe ID-Token wie jemand mit Passwort. Das Token sagt nicht, welches von beiden genutzt wurde, also können Sie Passkey-Logins heute nicht anders behandeln. Das ist eine Einschränkung, und ich nenne sie lieber, als dass Sie nach einem Claim suchen, den es nicht gibt.
Ein Konto bei EAuth gehört zu einer Anwendung. Wer zwei Anwendungen nutzt, hat zwei Konten und fügt jedem einen Passkey hinzu. Weil jeder Passkey zu eauth.me gehört, bietet der Browser womöglich beide auf beiden Login-Seiten an; der für die andere Anwendung wird mit einer entsprechenden Meldung abgewiesen, und niemand wird angemeldet. Unsere eigene Entwicklerkonsole und unser Dashboard melden sich über dieselbe Seite an, also bekommen Entwickler dort ebenfalls Passkeys.
Quellen
- Web Authentication: An API for accessing Public Key Credentials, Level 3, W3C, gelesen am
- Bootstrapping, passkeys.dev, gelesen am
- Multifactor Authentication Cheat Sheet, OWASP, gelesen am
Geschrieben von Samuel Krauss, Founder. Abgelegt unter eauth, passkeys, security, webauthn.
Übersetzt aus dem Englischen. Zum englischen Original