Account recovery को कमजोर किए बिना readable Recovery Codes

हम कौन-सी समस्या हल कर रहे थे

Recovery normal login नहीं है. लोग वहां तब पहुंचते हैं जब कुछ पहले ही गलत हो चुका होता है: lost device, missing passkey, नया phone, या deadline. Recovery design cryptographically sound हो सकता है और फिर भी users fail हो सकते हैं अगर code बहुत लंबा, पढ़ने में कठिन, copy करने में कठिन, या mistype करने में आसान हो.

Goal recovery को casual बनाना नहीं था. Goal honest path को कम painful बनाना था, server strict रखते हुए. इसका मतलब था transcription mistakes कम करना, सभी important fields एक screen पर रखना, paste forgiving बनाना, और user के server response का इंतजार करने से पहले obvious typos validate करना.

नए codes

दोनों codes वही PayCal accessibility alphabet use करते हैं:

ABCDEFGHJKLMNPQRTUWXYZ346789

हम जानबूझकर उन characters को exclude करते हैं जो पढ़ते, copy करते, print करते या type करते समय अक्सर confuse होते हैं. Inputs uppercase करके और spaces/hyphens हटाकर normalize होते हैं, ताकि users grouped या ungrouped form में codes paste कर सकें.

Checksum secret नहीं है और security entropy नहीं जोड़ता. यह honest mistakes पकड़ने के लिए है. अगर last two characters secret portion से match नहीं करते, तो browser तुरंत कह सकता है, “Check the last two characters,” इससे पहले कि user server attempt खर्च करे.

Online brute force इतना लंबा क्यों लेता है

Important phrase है online recovery. Attackers PayCal के through unlimited guesses उतनी तेजी से नहीं चला सकते जितनी उनकी hardware compute कर सकती है. Server pace control करता है, failures count करता है, codes expire करता है, abuse telemetry record करता है, और transaction state को line up होना require करता है.

Current conservative defaults के साथ recovery इन controls से bounded है:

• email Verification Codes 10 minutes के बाद expire होते हैं;
• email Verification Codes single-use होते हैं;
• verification और proof endpoints attempt-limited हैं;
• recovery starts per day limited हैं;
• resends per hour limited हैं और cooldown है;
• server-seen checksum failures abuse telemetry और attempt policy में count होते हैं;
• recovery transactions और bootstrap windows expire होते हैं;
• server, browser नहीं, authoritative रहता है.

Five guesses per hour पर, Recovery Code space का आधा try करने में लगभग 2.65 trillion years लगेंगे. उसी online pace पर combined Recovery Code plus email-code space का आधा try करने में लगभग 1.63 quintillion years लगेंगे. यही वह “really, really long time” है: इसलिए नहीं कि user को huge code रखना है, बल्कि इसलिए कि online recovery में multiple factors हैं और server guesses को freely run नहीं होने देता.

10-minute window

Email code intentionally short है क्योंकि यह account को अकेले protect करने के लिए नहीं है. यह time-limited है, user inbox में delivered है, attempt-limited है, और success पर consumed होता है.

614,656 possible email-code secrets के साथ, one 10-minute code window में five guesses से email code को chance से guess करने की maximum probability 0.000813% है, यानी लगभग 1 in 122,931. फिर भी protected recovery complete नहीं होगी, क्योंकि saved Recovery Code और recovery proof भी pass करने होंगे.

User experience में क्या बदला

हमने recovery screen को एक centered form तक reduce किया. User email field, Verification Code field, Recovery Code field, और एक primary action देखता है: Verify and continue.

• User email का इंतजार करते हुए saved Recovery Code paste कर सकता है.
• Spaces और hyphens accepted और normalized होते हैं.
• Recovery Codes auto-formatted as XXXXXX-XXXXXX-CC होते हैं.
• Verification Codes auto-formatted as XXXXCC होते हैं.
• Invalid alphabet characters clear inline message दिखाते हैं.
• Checksum failures server request से पहले locally पकड़े जाते हैं.
• जब दोनों formats सही लगते हैं, form “Checking...” दिखाता है और short debounce के बाद automatically submit करता है.
• Verify and continue button fallback के रूप में available रहता है.

Normal user के लिए result faster है: fewer steps, fewer surprises, less hidden state, और spaces/hyphens के साथ code copy करने पर less punishment.

Security model में क्या बदला

Redesign ने कई recovery boundaries भी tighten कीं:

• Raw Recovery Codes email नहीं होते. वे create होने पर once displayed होते हैं और user को save करने होते हैं.
• PayCal recovery-wrapped material और verifier state store करता है, raw Recovery Code कभी नहीं.
• Magic links existing protected account को अपने आप passkey-ready नहीं बना सकते.
• Email-only bootstrap केवल first-passkey setup के लिए allowed है जब existing protected crypto material और existing passkey न हो.
• Recovery complete करने के लिए recovery transaction में registered passkey credential ID का completion request से match करना जरूरी है.
• Successful account recovery के बाद old passkeys revoke होते हैं ताकि new passkey trusted credential बने.

इसका मतलब क्या नहीं है

यह claim नहीं है कि 12-character human-readable code 256-bit offline secret है. PayCal account recovery online, server-mediated, two-factor recovery flow है. Recovery Code एक factor है; inbox access और transaction state दूसरा; passkey registration final device-bound step है.

यह distinction important है. हमने code readable बनाया क्योंकि लोगों को इसे save और correctly type करना होता है. हमने server strict रखा क्योंकि readable recovery का मतलब weak recovery नहीं होना चाहिए.