Argon2id und scrypt werden für die Passwortspeicherung empfohlen, und Passkeys werden anstelle von Passwörtern empfohlen. Die beiden Empfehlungen haben eine unterschiedliche Quantenexposition. Ein mit Argon2id gehashtes Passwort ist symmetrische Kryptographie; Grovers Algorithmus bietet höchstens eine quadratische Beschleunigung beim Raten, und die speicherharte Konstruktion kostet den Quantenangreifer denselben Speicher pro Versuch wie den klassischen. Ein Passkey ist ein P-256-Schlüsselpaar und eine ECDSA-Signatur, die aktuelle Ressourcenschätzungen vor RSA-2048 in die Reihenfolge des Brechens setzen. Welche Quantenfrist für einen Passkey gilt, hängt davon ab, wo sein privater Schlüssel gespeichert ist.
Stand der Standardisierung für ML-DSA in WebAuthn
RFC 9964 definiert ML-DSA-Serialisierungen für COSE, und das IANA-COSE-Register führt die Kennungen −48, −49 und −50 für ML-DSA-44, ML-DSA-65 und ML-DSA-87. WebAuthn Level 3, seit August 2026 eine W3C Recommendation, reicht eine COSE-Algorithmuskennung durch, ohne sie zu interpretieren, sodass die W3C-Spezifikation keine Änderung braucht. Der Review-Entwurf der Server Requirements für WebAuthn Level 3 und CTAP 2.3 der FIDO Alliance vom Februar 2026 führt alle drei ML-DSA-Parametersätze als Recommended für Server; seine ML-DSA-Referenz ist noch der Internet-Draft, der dem RFC vorausging. Ein individueller IETF-Entwurf, draft-vitap-ml-dsa-webauthn, beschreibt Registrierung und Assertion mit ML-DSA-Schlüsseln und rät zu ML-DSA-44 oder ML-DSA-65, wo Signaturgröße oder Verarbeitungszeit zählen. Eine ML-DSA-87-Signatur ist 4.627 Bytes groß; eine ES256-Signatur 64.
Authenticatoren existieren als Demonstratoren. Google veröffentlichte im August 2023 eine hybride ECDSA/Dilithium-Firmware für OpenSK. Yubico hat Prototyp-YubiKeys gezeigt, die mit ML-DSA signieren, was Mike Jones festhielt, als RFC 9964 erschien. Swissbits iShield Key 2 PQC unterstützt ML-DSA-Credentials gegenüber einer angepassten SimpleWebAuthn Relying Party. Keines davon ist ein zertifiziertes Produkt, und kein Plattform-Authenticator von Apple, Google oder Microsoft hat einen Termin genannt. Johann-Philipp Thiers von Swissbit, Co-Vorsitzender der PQC Study Group der FIDO Alliance, schrieb im September, dass die CTAP-PIN/UV-Protokolle auf ECDH beruhen und voraussichtlich zu ML-KEM wechseln würden, dass Attestierungsketten auf X.509-Zertifikaten mit ECC- oder RSA-Schlüsseln aufsetzen und dass die Signaturen des Metadatendienstes und die Zertifizierungsprogramme mit ihnen geändert werden müssen.
Gerätegebundene Passkeys und die Signaturfrist
Eine Passkey-Assertion ist eine Challenge-Response-Signatur. Sie beweist den Besitz des Schlüssels zum Zeitpunkt des Signierens; es gibt keinen Chiffretext zu sammeln und keinen Sitzungsschlüssel zu rekonstruieren. Die Exposition ist die, die die NSA trust now, exploit later nennt: Ein Angreifer, der den öffentlichen Schlüssel aufgezeichnet hat, gewinnt den privaten Schlüssel, sobald ein kryptographisch relevanter Quantencomputer existiert, und signiert von da an Challenges. Unter EO 14412 ist das die Signaturfrist 2031, ein Jahr hinter der Schlüsseleinigung. In der Debatte um hybride Signaturen ist Valsordas Position, dass reines ML-DSA-44 für Signaturen genügt, während Hybride beim Schlüsselaustausch bleiben. Apples PQ3-Design für iMessage folgt derselben Überlegung: Die Schlüsseleinigung wechselte 2024 auf ein Kyber-Hybrid, und die Absenderauthentifizierung bleibt bei P-256-ECDSA, weil eine Signatur nicht rückwirkend angegriffen werden kann.
Ein Passkey, dessen privater Schlüssel in einem Hardware-Authenticator oder im Secure Element eines Geräts bleibt, unterliegt deshalb der Signaturfrist und steht in der Migrationsreihenfolge hinter dem TLS-Schlüsselaustausch und hinter dem Code-Signing.
Synchronisierte Passkeys und die Frist für die Schlüsseleinigung
Apples Handbuch zur Plattformsicherheit beschreibt unter sichere Schlüsselbund-Synchronisierung, dass jedes Gerät eine Syncing-Identität aus P-384-Elliptische-Kurven-Schlüsseln hält, dass jeder Schlüsselbundeintrag so verschlüsselt ist, dass nur ein Gerät im Kreis des Nutzers ihn entschlüsseln kann, und dass er in dieser Form Apples Server passiert. Die Wiederherstellung ist ein eigener Pfad: Apples Seite zur Escrow-Sicherheit beschreibt einen Escrow-Datensatz, den ein Cluster aus Hardware-Sicherheitsmodulen schützt, jedes mit einem Schlüssel, der die ihm anvertrauten Datensätze verschlüsselt, mit dem per SRP geprüften iCloud-Sicherheitscode des Nutzers, und nennt keinen Public-Key-Algorithmus für die Escrow-Verpackung. Googles Beschreibung der Passkeys im Google Passwortmanager hält fest, dass ein gesicherter privater Schlüssel nur in verschlüsselter Form hochgeladen wird, unter einem Schlüssel, der auf den eigenen Geräten des Nutzers zugänglich ist und auf einem neuen Gerät über die Bildschirmsperre eines vorhandenen Geräts wiederhergestellt wird, und nennt die Schlüsseleinigung nicht.
Auf dem Sync-Pfad ist das gespeicherte Objekt ein privater Signaturschlüssel, verpackt an eine Elliptische-Kurven-Geräteidentität und für die Lebensdauer des Kontos auf der Infrastruktur des Anbieters gehalten. Ein Angreifer, der diesen Chiffretext hält, durch Einbruch oder auf dem Rechtsweg, und später einen einzelnen Geräteidentitätsschlüssel bricht, gewinnt die daran verpackten Einträge als nutzbare Signaturschlüssel. Harvest now, decrypt later gilt für diesen Pfad, und damit die Frist für die Schlüsseleinigung statt der Signaturfrist. Ob die Sync- und Wiederherstellungskanäle der drei Plattformanbieter auf Post-Quanten-Schlüsseleinigung umgestellt sind, beantwortet ihre öffentliche Dokumentation nicht.
Bestehende Credentials können den Algorithmus nicht wechseln
Die FIDO Alliance schätzt für Mai 2026 fünf Milliarden aktiv genutzte Passkeys, und ihre Umfrage State of Passkeys 2026 ergibt, dass drei Viertel der Verbraucher mindestens einen aktiviert haben. Jeder ist ein P-256-Schlüssel oder ein RSA-Schlüssel, wo die Relying Party das zuließ. WebAuthn kennt keine Operation, die den Algorithmus eines bestehenden Credentials ändert; Migration ist eine neue Registrierungszeremonie pro Konto und Nutzer, und die Relying Party hält beide Credentials, bis das alte stillgelegt ist.
RSA in Exportqualität ist der Präzedenzfall für einen Credential-Bestand, der seinen Grund überdauert. Die 512-Bit-RSA_EXPORT-Cipher-Suites entstanden Mitte der 1990er durch US-Exportregeln, und die Regeln wurden 2000 gelockert. FREAK fand im März 2015 36,7% der Server mit browservertrauten Zertifikaten, die die Suites noch anboten, und Clients, die sie noch akzeptierten, und Logjam fand zwei Monate später dasselbe für 512-Bit-Diffie-Hellman. Kein Mechanismus hatte in fünfzehn Jahren einen neuen Schlüssel erzwungen. Ein Passkey erhält nur dann einen neuen Schlüssel, wenn ein Mensch ihn neu registriert.
Konfiguration der Relying Party
Werden −48 und −49 in pubKeyCredParams neben −7 akzeptiert, wie es die CTAP-2.3-Server-Requirements empfehlen, wird der erste Authenticator, der ML-DSA anbietet, nicht abgewiesen. WebAuthn-Bibliotheken nehmen die Algorithmen auf; Keycloaks Tracking-Issue ist durch webauthn4j blockiert, und SimpleWebAuthn wurde in Swissbits Demonstrator gepatcht. Wird der COSE-Algorithmus jedes registrierten Credentials erfasst, werden die Zahl der P-256-Credentials und ihre Veränderungsrate berichtbar, was eine Credential-Tabelle, die nur den Public-Key-Blob hält, nicht leisten kann.
Die Aufteilung der Berichterstattung ist dieselbe wie bei TLS, wo [PQ]probe den Post-Quanten-Schlüsselaustausch gegen 2030 bewertet und den Signaturalgorithmus jedes gesehenen Zertifikats erfasst. Bei Passkeys berichtet der Sync- und Wiederherstellungskanal gegen die Frist für die Schlüsseleinigung und die Assertion gegen die Signaturfrist, und die Algorithmusspalte der Credential-Tabelle ist die Quelle der zweiten Zahl.