Passkeys vs. Passwörter: Wie WebAuthn das Passwort tatsächlich ersetzt

Für etwa dreißig Jahre lautete die Antwort auf die Frage “Wie beweise ich online, wer ich bin” stets gleich: Geben Sie eine geheime Zeichenfolge ein, die Sie auch im Kopf gespeichert haben. Passkeys brechen dieses Muster - und zwar nicht auf eine Marketing-Art. Sie verändern die eigentliche Kryptografie dessen, was beim Einloggen passiert. Dieser Beitrag erklärt, wie das funktioniert, wo es Passwörter wirklich übertrifft und welche Tücken 2026 noch immer auftreten.

Was ein Passkey tatsächlich ist

Ein Passkey ist ein öffentliches/privates Schlüsselpaar. Das ist alles. Wenn Sie einen für eine Website erstellen, generiert Ihr Gerät zwei mathematisch verknüpfte Schlüssel. Der private Schlüssel verbleibt auf dem Gerät, gesichert durch das Sicherheitselement der Hardware. Der öffentliche Schlüssel wird an den Server gesendet und neben Ihrem Konto gespeichert.

Die Asymmetrie ist der Kern der Sache. Der Server kann eine vom privaten Schlüssel erstellte Signatur verifizieren, kann diese Signatur aber niemals selbst reproduzieren, weil er den privaten Schlüssel nicht hat. Vergleichen Sie das mit einem Passwort, bei dem der Server irgendetwas speichern muss, das von Ihrem Geheimnis abgeleitet ist, um es später prüfen zu können. Selbst ein ordnungsgemäß gesalzener bcrypt- oder Argon2-Hash ist ein Derivat eines gemeinsamen Geheimnisses. Mit einem Passkey gibt es überhaupt kein gemeinsames Geheimnis. Die Kopie des Servers ist für einen Angreifer, der die Datenbank stiehlt, wertlos.

Jeder Passkey ist auf eine Website beschränkt. Der Browser bindet ihn an den Ursprung der Website (seine Relying Party ID, normalerweise die Domain). Ein für github.com erstellter Passkey erzeugt keine gültige Signatur für g1thub.com, und der Browser bietet ihn nicht einmal an. Behalten Sie das im Hinterkopf, denn es ist der Mechanismus hinter dem Anti-Phishing-Anspruch, der später erläutert wird.

Wenn Sie bereits einen Hardware-Sicherheitsschlüssel für SSH oder einen YubiKey für 2FA verwendet haben, wissen Sie ungefähr, wie sich das anfühlt. Passkeys sind das gleiche FIDO2-Grundelement, nur als primärer Anmeldenachweis statt als zweiter Faktor eingesetzt.

Die WebAuthn-Zeremonie, Schritt für Schritt

WebAuthn ist die Browser-API, die all das zugänglich macht. Die Spezifikation nennt jeden Anmeldeablauf eine “Zeremonie”. Es gibt zwei: Registrierung und Authentifizierung. Beide sind Challenge-Response, und der Server sieht niemals einen privaten Schlüssel.

Registrierung

Wenn Sie sich anmelden oder einem bestehenden Konto einen Passkey hinzufügen:

1. Der Server generiert eine zufällige Challenge und sendet sie mit den Relying-Party-Informationen und Ihrem Benutzer-Handle an den Browser.
2. Der Browser übergibt das dem Authenticator (dem sicheren Enklave Ihres Telefons, Windows Hello, einem YubiKey usw.).
3. Der Authenticator verifiziert Sie mit einer lokalen Geste (Face ID, Fingerabdruck, PIN) und generiert ein neues Schlüsselpaar, das auf diesen Ursprung beschränkt ist.
4. Er signiert die Challenge mit dem neuen privaten Schlüssel und gibt den öffentlichen Schlüssel sowie die signierte Attestierung zurück.
5. Der Server speichert den öffentlichen Schlüssel und eine Credential-ID für Ihr Konto.

Hier ist die Form davon in der Browser-API:

// Registrierung - der Server hat bereits `challenge` und `user` gesendet
const credential = await navigator.credentials.create({
  publicKey: {
    challenge,                       // zufällige Bytes vom Server
    rp: { name: "Example", id: "example.com" },
    user: { id: userIdBytes, name: "[email protected]", displayName: "Ada" },
    pubKeyCredParams: [
      { type: "public-key", alg: -7 },   // ES256
      { type: "public-key", alg: -257 }, // RS256
    ],
    authenticatorSelection: {
      residentKey: "required",       // macht es zu einem entdeckbaren Passkey
      userVerification: "required",
    },
  },
});
// credential.response (Attestierung + öffentlicher Schlüssel) zurück an den Server senden

Diese zufällige Challenge ist wichtig. Sie muss nicht erratbar und einmalig verwendbar sein - genau die Eigenschaft, die ein guter Zufallstoken-Generator bietet. Wenn Sie die Serverseite aufbauen und Challenges prägen müssen, ist unser Sicherer Token-Generator die gleiche Art von CSPRNG-gestütztem Wert, den Sie crypto.randomBytes in der Produktion zugeordnet hätte.

Authentifizierung

Das spätere Anmelden ist das Spiegelbild:

1. Der Server sendet eine neue zufällige Challenge.
2. Der Browser fordert den Authenticator auf, sie mit dem privaten Schlüssel für diesen Ursprung zu signieren.
3. Sie bestätigen mit einem biometrischen Merkmal oder einer PIN.
4. Der Authenticator gibt die Signatur zurück; der Server verifiziert sie gegen den gespeicherten öffentlichen Schlüssel.

// Authentifizierung
const assertion = await navigator.credentials.get({
  publicKey: {
    challenge,                  // neue zufällige Bytes
    rpId: "example.com",
    userVerification: "required",
    allowCredentials: [],       // leer = Benutzer lässt entdeckbaren Passkey wählen
  },
});
// Server prüft assertion.response.signature gegen den gespeicherten öffentlichen Schlüssel

Kein Passwort wird übertragen. Kein Code wird eingegeben. Die Signatur ist nur für diese eine Challenge, auf diesem einen Ursprung gültig, und erlischt in dem Moment, in dem sie verwendet wird.

Warum das Phishing und Credential Stuffing eliminiert

Zwei der gängigsten Wege, wie Konten kompromittiert werden, funktionieren gegen Passkeys nicht mehr, und es lohnt sich, genau zu verstehen, warum.

Phishing. Ein Phishing-Angriff beruht darauf, Sie dazu zu bringen, Ihr Geheimnis an eine Lookalike-Website weiterzugeben. Mit einem Passkey gibt es nichts weiterzugeben. Der Browser bindet die Signatur an den Ursprung, mit dem er tatsächlich kommuniziert. Wenn Sie auf paypa1.com landen, wird der Authenticator nicht mit Ihrem paypal.com-Schlüssel signieren, weil die Ursprünge nicht übereinstimmen. Der Browser zeigt den Passkey nicht einmal an. Der Angreifer erhält nichts Verwendbares, selbst wenn seine Seite ein pixelgenaues Klon ist. Das ist strukturell anders als TOTP. Ein Echtzeit-Phishing-Proxy kann zwischen Ihnen und der echten Website sitzen, den sechsstelligen Code von Ihrer Authentifikator-App abfangen und ihn innerhalb des 30-Sekunden-Fensters wiederverwenden. Passkeys haben keinen Code, der abgefangen werden könnte.

Credential Stuffing. Dieser Angriff verwendet aus einem Datenleck gestohlene Passwörter von einer Website gegen andere Websites und setzt auf Wiederverwendung. Er funktioniert, weil Passwörter übertragbare Geheimnisse sind. Ein gestohlener öffentlicher Schlüssel ist wertlos: Sie können damit nicht signieren, und er galt sowieso nur für eine Website. Es gibt keine Liste wiederverwendbarer Geheimnisse zum Ausprobieren.

Das bedeutet nicht, dass Passkeys Sie gegen alles immunisieren. Bereits auf Ihrem entsperrten Gerät laufende Malware kann eine authentifizierte Sitzung missbrauchen. Kontowiederherstellungsabläufe sind oft der schwache Punkt (mehr dazu unten). Und Social Engineering gegen einen Helpdesk kümmert sich nicht um Ihre Anmelde-Kryptografie. Passkeys beseitigen eine ganze Kategorie von Angriffen; sie beenden nicht den Krieg.

Hier ist der Vergleich klar dargestellt:

Angriff	Passwort (+ TOTP)	Passkey
Datenbankverstoß gibt Anmeldedaten preis	Hashes können offline geknackt werden	Öffentlicher Schlüssel allein ist wertlos
Phishing-Seite fängt Eingaben ab	TOTP in Echtzeit weiterleitbar	Ursprungskonflikt blockiert Signierung
Credential Stuffing / Wiederverwendung	Funktioniert bei Passwort-Wiederverwendung	Kein übertragbares Geheimnis vorhanden
Keylogger auf dem Gerät	Fängt Passwort und Code ab	Nichts zu tippen, was abgefangen werden könnte
Malware in aktiver Sitzung	Vulnerabel	Weiterhin vulnerabel
Missbrauch der Kontowiederherstellung	Vulnerabel	Oft weiterhin vulnerabel

Der Authenticator: Plattform vs. Roaming

Das Ding, das Ihren privaten Schlüssel hält, ist der Authenticator, und es gibt zwei Varianten.

Plattform-Authenticatoren sind in das Gerät integriert. Face ID und Touch ID auf Apple-Hardware, Windows Hello auf einem PC, der Fingerabdrucksensor auf einem Android-Telefon. Sie kommunizieren direkt über das Betriebssystem mit WebAuthn. Bequem, immer dabei und die gängigste Art, wie Menschen auf Passkeys treffen.

Roaming-Authenticatoren sind separate Hardware, die Sie einstecken oder antippen: ein YubiKey 5, ein Google Titan-Schlüssel, ein SoloKey. Sie kommunizieren mit dem Browser über USB, NFC oder Bluetooth unter Verwendung eines Protokolls namens CTAP2 (Client to Authenticator Protocol). Derselbe CTAP2-Link ermöglicht das gerätübergreifende Anmelden, bei dem Ihr Telefon als Roaming-Authenticator für einen nahegelegenen Laptop über Bluetooth fungiert, nachdem Sie einen QR-Code gescannt haben.

Roaming-Schlüssel sind die Wahl für Menschen, die möchten, dass der private Schlüssel ein dediziertes Stück Hardware physisch nie verlässt. Der Nachteil liegt auf der Hand: Es ist ein weiteres Objekt, das man tragen und nicht verlieren darf. Für die meisten Benutzer ist ein Plattform-Authenticator, der durch einen synchronisierten Credential-Store gesichert ist, der realistische Standard.

Synchronisierte Passkeys vs. Gerät-gebundene

Das ist die Aufteilung, die die meiste Verwirrung verursacht, und sie ist die wichtigste Entscheidung dafür, wie Passkeys für Sie tatsächlich funktionieren.

Gerät-gebundene Passkeys verlassen niemals den Authenticator, der sie erstellt hat. Ein auf einem YubiKey generierter Passkey lebt und stirbt auf diesem YubiKey. Hohe Sicherheit, weil der private Schlüssel genau ein Zuhause hat. Auch hohes Risiko, wenn dieses Zuhause verloren geht, denn es gibt nirgendwo eine Kopie.

Synchronisierte Passkeys werden durch einen Credential-Manager gesichert und über Ihre Geräte kopiert:

• iCloud Keychain synchronisiert Passkeys auf Ihren Apple-Geräten, Ende-zu-Ende-verschlüsselt, wiederherstellbar wenn Sie sich auf einem neuen iPhone oder Mac anmelden.
• Google Password Manager tut dasselbe auf Android und Chrome.
• Windows Hello neigte historisch zu Gerät-gebundenen Credentials, obwohl Microsoft sich zunehmend zu synchronisierten Passkeys bewegt, die an Ihr Microsoft-Konto gebunden sind.
• Bitwarden und 1Password sind plattformübergreifende Manager, die Passkeys speichern und synchronisieren, unabhängig vom Betriebssystem, was das Walled-Garden-Problem umgeht.

Synchronisierte Passkeys tauschen ein winziges theoretisches Sicherheitsstück gegen enorme praktische Belastbarkeit ein. Das Argument gegen die Synchronisierung ist, dass Ihr privater Schlüssel nun an mehr als einem Ort existiert und auf die Sicherheit Ihres Cloud-Kontos setzt. Das Argument dafür ist, dass die Alternative - jeden Zugangsdaten zu verlieren, wenn Sie Ihr Telefon in einen See fallen lassen - für normale Menschen eine viel wahrscheinlichere Versagensform ist. FIDOs eigene Leitlinien akzeptieren synchronisierte Passkeys genau deshalb, weil die ausschließlich Gerät-gebundene Einführung an der Wiederherstellungsangst scheitert.

Wenn Sie einen Dienst betreiben und wissen möchten, welche Art ein Benutzer registriert hat, markiert die Authenticator-Daten dies. Sie können Gerät-gebundene für Hochwertigkeitsaktionen verlangen und synchronisierte für den täglichen Login akzeptieren. Diese Abstufung ist sinnvoll.

Die realen Lücken

Jetzt der Teil, den die Launch-Blogs überspringen.

Kontowiederherstellung ist das schwache Glied

Ein Passkey ist nur so stark wie der schlechteste Weg, ihn zu umgehen. Viele Websites, die stolz Passkey-Unterstützung hinzugefügt haben, erlauben immer noch den Zugangsreset per E-Mail-Magic-Link oder SMS-Code. Wenn Ihr Wiederherstellungsweg eine SMS ist, kann ein Angreifer, der Sie SIM-swappt, einfach an all der eleganten Kryptografie vorbei. Passkeys erhöhen den Boden Ihrer Anmeldung, aber die Wiederherstellung hält oft eine Falltür drin. Wenn Sie ein Passkey-geschütztes Konto einrichten, schauen Sie sich an, wie die Wiederherstellung funktioniert, bevor Sie ihm etwas Wichtiges anvertrauen.

Geräteübergreifende Synchronisierung ist immer noch chaotisch

Innerhalb der Apple-Welt oder innerhalb der Google-Welt ist die Synchronisierung reibungslos. Zwischen ihnen nicht. Es gibt keine native “Kopiere meine Passkeys von iCloud Keychain zu Google Password Manager”-Schaltfläche, und es wird wahrscheinlich bald keine geben, weil keines der Unternehmen es eilig hat, das Verlassen zu erleichtern. Das Credential Exchange Protocol, das dies standardisieren soll, wird langsam eingeführt. Bis es überall verfügbar ist, ist ein Drittanbieter-Manager wie Bitwarden oder 1Password der sauberste Weg, um einen Passkey-Satz zu haben, der auf jedem Gerät funktioniert, das Sie besitzen.

”Was ist, wenn ich mein Telefon verliere”

Das ist die Frage, die jeder stellt, und die ehrliche Antwort lautet: Es hängt vollständig davon ab, was Sie vorher eingerichtet haben.

• Synchronisierter Passkey, einziges Ökosystem: Melden Sie sich bei Ihrem Ersatzgerät an, Ihre Passkeys kommen zurück. Größtenteils schmerzlos.
• Gerät-gebundener Passkey auf einem verlorenen Schlüssel ohne registrierten Backup: Diese Credential ist weg, und Sie sind auf den Wiederherstellungsablauf der Website angewiesen.
• Kein zweiter Authenticator irgendwo: Sie können hart ausgesperrt werden.

Die Lösung ist langweilig und effektiv: Registrieren Sie mindestens zwei Authenticatoren auf Konten, die Ihnen wichtig sind. Ein Plattform-Passkey auf Ihrem Telefon plus ein Roaming-Schlüssel in einer Schublade deckt die gängigen Katastrophen ab. Behandeln Sie es wie einen Reserveschlüssel.

Abdeckung ist immer noch ungleich

Große Plattformen unterstützen jetzt Passkeys - Google, Apple, Microsoft, GitHub, Amazon, PayPal. Der Long Tail kleinerer Websites nicht. Viele bieten immer noch nur Passwörter an oder bieten Passkeys als aufgesetzten zweiten Faktor statt als echten Ersatz an. Sie werden jahrelang in einer gemischten Welt leben.

Wo Passworter weiterhin bestehen bleiben

Passwörter sind nicht tot, und das so zu tun, als wären sie es, lässt Sie unvorbereitet.

• Wiederherstellung und Fallback. Wie oben erwähnt, halten die meisten Passkey-Implementierungen ein Passwort oder einen Backup-Code als Break-Glass-Option bereit. Sie werden weiterhin starke generieren.
• Legacy-Systeme. Unternehmens-Apps, alte VPNs, eingebettete Geräteverwaltungsoberflächen, alles, was vor WebAuthn kommt. Diese erhalten keine Passkeys.
• Gemeinsame und headless Konten. Service-Konten, Maschinen, Kioske und Konten, die ein Team weitergibt, lassen sich nicht sauber auf ein biometrisches Modell pro Person abbilden.
• Websites, die es einfach noch nicht gebaut haben. Der Großteil des Webs, immer noch.

Die praktische Haltung für 2026 ist also hybrid. Verwenden Sie Passkeys, wo immer eine Website sie als echte Anmeldemethode anbietet. Halten Sie einen Passwort-Manager für alles andere bereit und machen Sie diese Passwörter lang und zufällig statt einprägsam. Wenn Sie ein Fallback-Passwort brauchen, generieren Sie es statt es zu erfinden: unser Passwort-Generator erzeugt hochentropische Zeichenketten, und wenn Sie etwas prüfen möchten, das Sie bereits verwenden, sagt Ihnen der Passwortstärke-Prüfer , wie es wirklich abschneidet. Und wo Passkeys nicht verfügbar sind, eine Website aber App-basierte 2FA unterstützt, ist ein TOTP-Generator immer noch ein bedeutender Schritt gegenüber nur einem Passwort, auch wenn er der schwächere Cousin eines Passkeys ist.

Zusammenfassung

Ein Passkey ist ein Website-spezifisches öffentliches/privates Schlüsselpaar, bei dem die private Hälfte niemals den Authenticator verlässt und der Server immer nur die öffentliche Hälfte hält. Die WebAuthn-Zeremonie ist ein Challenge-Response, lokal nach einem biometrischen Merkmal oder einer PIN signiert, ohne dass ein gemeinsames Geheimnis übertragen wird. Dieses Design besiegt strukturell Phishing, weil Signaturen an den echten Ursprung gebunden sind, und Credential Stuffing, weil es kein übertragbares Geheimnis zum Wiederverwenden oder Durchsickern gibt. Authenticatoren kommen als Plattform (Face ID, Windows Hello) oder Roaming (YubiKey), und Credentials sind entweder synchronisiert für Belastbarkeit oder Gerät-gebunden für maximale Sicherheit. Die echten Kompromisse sind, dass die Kontowiederherstellung immer noch ein weiches Ziel ist, die gerätübergreifende Synchronisierung halb fertig ist, und das Problem des verlorenen Geräts davon abhängt, ob Sie vorher Backups registriert haben. Passwörter bleiben als Fallback, in Legacy-Systemen und auf dem Long Tail von Websites bestehen, die noch nicht aufgeholt haben. Übernehmen Sie Passkeys, wo sie real sind, halten Sie einen Manager für den Rest bereit und registrieren Sie einen zweiten Authenticator, bevor Sie ihn brauchen.