Kurzfassung
| Warum wir es getan haben | Kontowiederherstellung sollte schnell, lesbar und ruhig sein, ohne permissiv zu werden |
| Gespeicherter Faktor | Recovery Code: XXXXXX-XXXXXX-CC, wobei 12 Zeichen geheim sind und 2 Zeichen Prüfsumme sind |
| E-Mail-Faktor | Verification Code: XXXXCC, wobei 4 Zeichen geheim sind und 2 Zeichen Prüfsumme sind |
| Alphabet | ABCDEFGHJKLMNPQRTUWXYZ346789, gewählt, um visuell verwechselbare Zeichen zu vermeiden |
| Servergrenzen | 10-Minuten-Fenster für E-Mail-Codes, Einmalnutzung, Versuchslimits, erneute-Sendung-Cooldown, Transaktions-TTL und Missbrauchstelemetrie |
| Sicherheitsgrenze | Der E-Mail-Code beweist Postfachzugriff. Der Recovery Code beweist Besitz des gespeicherten Kontogeheimnisses. Keiner reicht allein für geschützte Wiederherstellung. |
Das Problem, das wir lösen wollten
Wiederherstellung ist kein normaler Login. Menschen nutzen sie, wenn bereits etwas schiefgelaufen ist: ein verlorenes Gerät, ein fehlender Passkey, ein neues Telefon oder eine Frist. Ein Wiederherstellungsdesign kann kryptografisch solide sein und Nutzer trotzdem scheitern lassen, wenn der Code zu lang, schwer lesbar, schwer zu kopieren oder leicht falsch zu tippen ist.
Das Ziel war nicht, Wiederherstellung locker zu machen. Das Ziel war, den ehrlichen Pfad weniger schmerzhaft zu machen und den Server streng zu halten. Das bedeutete weniger Abschreibfehler, alle wichtigen Felder auf einem Bildschirm, tolerantes Einfügen und Validierung offensichtlicher Tippfehler, bevor der Nutzer auf eine Serverantwort wartet.
Die neuen Codes
Beide Codes verwenden dasselbe PayCal-Barrierefreiheitsalphabet:
ABCDEFGHJKLMNPQRTUWXYZ346789Wir schließen bewusst Zeichen aus, die beim Lesen, Kopieren, Drucken oder Tippen häufig verwechselt werden. Eingaben werden normalisiert, indem sie in Großbuchstaben umgewandelt und Leerzeichen sowie Bindestriche entfernt werden. So können Nutzer Codes gruppiert oder ungruppiert einfügen.
| Code | Anzeigeformat | Geheime Zeichen | Prüfsummenzeichen |
|---|---|---|---|
| Recovery Code | XXXXXX-XXXXXX-CC |
12 | 2 |
| Verification Code | XXXXCC |
4 | 2 |
Die Prüfsumme ist kein Geheimnis und erhöht nicht die Sicherheitsentropie. Sie dient dazu, ehrliche Fehler zu erkennen. Wenn die letzten zwei Zeichen nicht zum geheimen Teil passen, kann der Browser sofort sagen: „Prüfe die letzten zwei Zeichen“, bevor der Nutzer einen Serverversuch verbraucht.
Die Mathematik
Der Recovery Code hat 12 geheime Zeichen aus 28 möglichen Symbolen. Das ergibt:
28^12 = 232,218,265,089,212,416 possibilities
log2(28^12) ~= 57.7 bitsDer E-Mail Verification Code hat 4 geheime Zeichen:
28^4 = 614,656 possibilities
log2(28^4) ~= 19.2 bitsWenn beide Faktoren zusammen betrachtet werden, ist der geheime Suchraum:
28^16 = 142,734,349,946,674,946,768,896 possibilities
log2(28^16) ~= 76.9 bitsEin einzelner Zufallsversuch gegen den gespeicherten Recovery Code liegt bei etwa 1 zu 232 Billiarden. Ein einzelner Zufallsversuch gegen beide Faktoren zusammen liegt bei etwa 1 zu 142 Trilliarden. Mit fünf kombinierten Versuchen liegt die Chance immer noch bei etwa 3,5 x 10^-23, also ungefähr 1 zu 28,5 Trilliarden.
Warum Online-Brute-Force so lange dauert
Die wichtige Formulierung ist Online-Wiederherstellung. Angreifer können nicht unbegrenzt schnell Versuche durch PayCal schicken, so schnell ihre Hardware rechnen kann. Der Server steuert das Tempo, zählt Fehlschläge, lässt Codes ablaufen, zeichnet Missbrauchstelemetrie auf und verlangt passende Transaktionszustände.
Mit den aktuellen konservativen Standardwerten wird Wiederherstellung durch Kontrollen begrenzt wie:
- E-Mail Verification Codes laufen nach 10 Minuten ab;
- E-Mail Verification Codes sind nur einmal verwendbar;
- Verifizierungs- und Proof-Endpunkte haben Versuchslimits;
- Wiederherstellungsstarts sind pro Tag begrenzt;
- erneute Sendungen sind pro Stunde begrenzt und haben einen Cooldown;
- vom Server gesehene Prüfsummenfehler zählen zu Missbrauchstelemetrie und Versuchspolitik;
- Wiederherstellungstransaktionen und Bootstrap-Fenster laufen ab;
- der Server, nicht der Browser, bleibt maßgeblich.
Bei fünf Versuchen pro Stunde würde es etwa 2,65 Billionen Jahre dauern, die Hälfte des Recovery-Code-Suchraums zu probieren. Die Hälfte des kombinierten Suchraums aus Recovery Code plus E-Mail-Code im selben Online-Tempo würde etwa 1,63 Trillionen Jahre dauern. Das ist die „wirklich, wirklich lange Zeit“, die wir meinen: nicht weil der Nutzer einen riesigen Code tragen muss, sondern weil Online-Wiederherstellung mehrere Faktoren hat und der Server Versuche nicht frei laufen lässt.
Das 10-Minuten-Fenster
Der E-Mail-Code ist absichtlich kurz, weil er das Konto nicht allein schützen soll. Er ist zeitlich begrenzt, wird an das Postfach des Nutzers geliefert, ist versuchsbeschränkt und wird bei Erfolg verbraucht.
Bei 614.656 möglichen E-Mail-Code-Geheimnissen ergeben fünf Versuche in einem 10-Minuten-Codefenster höchstens eine Chance von 0,000813 %, den E-Mail-Code zufällig zu erraten, also etwa 1 zu 122.931. Das würde geschützte Wiederherstellung trotzdem nicht abschließen, weil auch der gespeicherte Recovery Code und der Recovery Proof bestehen müssen.
Was sich für Nutzer geändert hat
Wir haben den Wiederherstellungsbildschirm auf ein zentriertes Formular reduziert. Der Nutzer sieht das E-Mail-Feld, das Verification-Code-Feld, das Recovery-Code-Feld und eine primäre Aktion: Verify and continue.
- Der Nutzer kann den gespeicherten Recovery Code einfügen, während er auf die E-Mail wartet.
- Leerzeichen und Bindestriche werden akzeptiert und normalisiert.
- Recovery Codes werden automatisch als
XXXXXX-XXXXXX-CCformatiert. - Verification Codes werden automatisch als
XXXXCCformatiert. - Ungültige Alphabetzeichen zeigen eine klare Inline-Meldung.
- Prüfsummenfehler werden lokal erkannt, bevor der Server angefragt wird.
- Wenn beide Formate korrekt aussehen, zeigt das Formular „Checking...“ und sendet nach kurzem Debounce automatisch.
- Die Schaltfläche Verify and continue bleibt als Rückfall verfügbar.
Das Ergebnis ist schneller für normale Nutzer: weniger Schritte, weniger Überraschungen, weniger versteckter Zustand und weniger Strafe für das Kopieren eines Codes mit Leerzeichen oder Bindestrichen.
Was sich im Sicherheitsmodell geändert hat
Die Neugestaltung hat außerdem mehrere Wiederherstellungsgrenzen verschärft:
- Rohe Recovery Codes werden nicht per E-Mail gesendet. Sie werden bei Erstellung einmal angezeigt und müssen vom Nutzer gespeichert werden.
- PayCal speichert recovery-wrapped Material und Verifier-Zustand, nie den rohen Recovery Code.
- Magic Links können ein bestehendes geschütztes Konto nicht allein passkey-ready machen.
- E-Mail-only Bootstrap ist nur für das erste Passkey-Setup erlaubt, wenn kein bestehendes geschütztes Kryptomaterial und kein bestehender Passkey vorhanden ist.
- Der Abschluss der Wiederherstellung verlangt, dass die in der Wiederherstellungstransaktion registrierte Passkey-Credential-ID zur Abschlussanfrage passt.
- Alte Passkeys werden nach erfolgreicher Kontowiederherstellung widerrufen, damit der neue Passkey zum vertrauenswürdigen Credential wird.
Was das nicht bedeutet
Das ist keine Behauptung, dass ein 12-stelliger menschenlesbarer Code ein 256-Bit-Offline-Geheimnis ist. PayCal-Kontowiederherstellung ist ein online, serververmittelter Zwei-Faktor-Wiederherstellungsfluss. Der Recovery Code ist ein Faktor; Postfachzugriff und Transaktionszustand sind ein anderer; Passkey-Registrierung ist der finale gerätegebundene Schritt.
Diese Unterscheidung ist wichtig. Wir haben den Code lesbar gemacht, weil Menschen ihn speichern und korrekt tippen müssen. Wir halten den Server streng, weil lesbare Wiederherstellung nicht schwache Wiederherstellung bedeuten darf.
Die Regel, die wir jetzt erzwingen
Der E-Mail-Code beweist Postfachzugriff.
Der Recovery Code beweist Besitz des gespeicherten Kontogeheimnisses.
Keiner von beiden reicht allein für geschützte Kontowiederherstellung.Das ist die Balance, die wir wollten: Wiederherstellung, die sich für den Kontoinhaber einfach, schnell und klar anfühlt, aber streng genug bleibt, dass Raten über den Server kein praktischer Weg ist.