PayCal Technologies Inc.

Readable Recovery Codes nang hindi pinapahina ang account recovery

Noong June 2026, ni-redesign namin ang PayCal account recovery para maging mas madali ito para sa totoong users na under stress: mas maiikling saved Recovery Codes, malinaw na email Verification Code, typo-resistant checksums, forgiving paste behavior, at isang calm form. Hindi nagbago ang security rule: kailangang patunayan ng recovery ang parehong inbox access at possession ng saved account secret.

Na-publish: · Huling na-update:

Executive summary

Bakit namin ginawa Dapat mabilis, readable, at calm ang account recovery nang hindi nagiging permissive
Saved factor Recovery Code: XXXXXX-XXXXXX-CC, kung saan 12 characters ang secret at 2 ang checksum
Email factor Verification Code: XXXXCC, kung saan 4 characters ang secret at 2 ang checksum
Alphabet ABCDEFGHJKLMNPQRTUWXYZ346789, pinili para maiwasan ang visually confusing characters
Server limits 10-minute email-code window, one-time use, attempt limits, resend cooldown, transaction TTL, at abuse telemetry
Security boundary Pinapatunayan ng email code ang inbox access. Pinapatunayan ng Recovery Code ang possession ng saved-account-secret. Hindi sapat ang alinman nang mag-isa para sa protected recovery.

Ang problemang nilulutas namin

Hindi normal login ang recovery. Ginagamit ito ng tao kapag may mali nang nangyari: nawawalang device, missing passkey, bagong phone, o deadline. Puwedeng cryptographically sound ang recovery design pero mabigo pa rin ang users kapag masyadong mahaba, mahirap basahin, mahirap kopyahin, o madaling ma-mistype ang code.

Hindi goal na gawing casual ang recovery. Goal na gawing less painful ang honest path habang strict pa rin ang server. Ibig sabihin nito ay bawasan ang transcription mistakes, ilagay ang lahat ng important fields sa isang screen, gawing forgiving ang paste, at i-validate ang obvious typos bago maghintay ang user ng server response.

Ang bagong codes

Parehong codes ang gumagamit ng parehong PayCal accessibility alphabet:

ABCDEFGHJKLMNPQRTUWXYZ346789

Sinasadya naming i-exclude ang characters na madalas malito kapag binabasa, kinokopya, ini-print, o tina-type. Nine-normalize ang inputs sa uppercase at inaalis ang spaces at hyphens, kaya puwedeng mag-paste ang users ng grouped o ungrouped codes.

Code Display format Secret characters Checksum characters
Recovery Code XXXXXX-XXXXXX-CC 12 2
Verification Code XXXXCC 4 2

Hindi secret ang checksum at hindi ito nagdadagdag ng security entropy. Nariyan ito para hulihin ang honest mistakes. Kapag hindi tugma ang last two characters sa secret portion, puwedeng sabihin agad ng browser na “Check the last two characters,” bago maubos ng user ang isang server attempt.

Ang math

May 12 secret characters ang Recovery Code mula sa 28 possible symbols. Ibig sabihin:

28^12 = 232,218,265,089,212,416 possibilities
log2(28^12) ~= 57.7 bits

May 4 secret characters ang email Verification Code:

28^4 = 614,656 possibilities
log2(28^4) ~= 19.2 bits

Kapag pinagsama ang dalawang factors, ang secret search space ay:

28^16 = 142,734,349,946,674,946,768,896 possibilities
log2(28^16) ~= 76.9 bits

Ang isang random guess laban sa saved Recovery Code ay humigit-kumulang 1 in 232 quadrillion. Ang isang random guess laban sa dalawang factors nang magkasama ay humigit-kumulang 1 in 142 septillion. Sa five combined guesses, ang chance ay humigit-kumulang pa rin na 3.5 x 10^-23, o roughly 1 in 28.5 sextillion.

Bakit matagal ang online brute force

Ang important phrase ay online recovery. Hindi makakapagpatakbo ang attackers ng unlimited guesses sa PayCal sa bilis ng hardware nila. Kinokontrol ng server ang pace, binibilang ang failures, pinapa-expire ang codes, nagre-record ng abuse telemetry, at kailangan tumugma ang transaction state.

Gamit ang current conservative defaults, naka-bound ang recovery sa controls tulad ng:

  • email Verification Codes expire after 10 minutes;
  • email Verification Codes are single-use;
  • verification and proof endpoints are attempt-limited;
  • recovery starts are limited per day;
  • resends are limited per hour and have a cooldown;
  • server-seen checksum failures count toward abuse telemetry and attempt policy;
  • recovery transactions and bootstrap windows expire;
  • the server, not the browser, remains authoritative.

Sa five guesses per hour, ang pagsubok sa kalahati ng Recovery Code space ay aabot ng humigit-kumulang 2.65 trillion years. Ang pagsubok sa kalahati ng combined Recovery Code plus email-code space sa parehong online pace ay aabot ng humigit-kumulang 1.63 quintillion years. Iyan ang ibig naming sabihin sa “really, really long time”: hindi dahil kailangang magdala ang user ng huge code, kundi dahil may multiple factors ang online recovery at hindi hinahayaan ng server na malayang tumakbo ang guesses.

Ang 10-minute window

Sadyang maikli ang email code dahil hindi ito ginawa para protektahan ang account nang mag-isa. Time-limited ito, dinadala sa inbox ng user, attempt-limited, at consumed on success.

Sa 614,656 possible email-code secrets, five guesses sa loob ng isang 10-minute code window ay nagbibigay ng at most 0.000813% chance na mahulaan ang email code by chance, o about 1 in 122,931. Hindi pa rin nito makukumpleto ang protected recovery, dahil kailangang pumasa rin ang saved Recovery Code at recovery proof.

Ano ang nagbago sa user experience

Binawasan namin ang recovery screen sa isang centered form. Nakikita ng user ang email field, Verification Code field, Recovery Code field, at isang primary action: Verify and continue.

  • Puwedeng i-paste ng user ang saved Recovery Code habang naghihintay ng email.
  • Accepted at normalized ang spaces at hyphens.
  • Auto-formatted ang Recovery Codes as XXXXXX-XXXXXX-CC.
  • Auto-formatted ang Verification Codes as XXXXCC.
  • Nagpapakita ng clear inline message ang invalid alphabet characters.
  • Locally nahuhuli ang checksum failures bago ang server request.
  • Kapag mukhang tama ang parehong formats, ipinapakita ng form ang “Checking...” at automatic na nag-submit pagkatapos ng short debounce.
  • Available pa rin ang Verify and continue button bilang fallback.

Mas mabilis ang result para sa normal user: fewer steps, fewer surprises, less hidden state, at less punishment kapag kinopya ang code na may spaces o hyphens.

Ano ang nagbago sa security model

Pinahigpit din ng redesign ang ilang recovery boundaries:

  • Hindi ini-email ang raw Recovery Codes. Ipinapakita ang mga ito once kapag created at kailangang i-save ng user.
  • Recovery-wrapped material at verifier state ang ini-store ng PayCal, hindi ang raw Recovery Code.
  • Hindi kayang gawing passkey-ready ng magic links ang existing protected account nang mag-isa.
  • Allowed lang ang email-only bootstrap para sa first-passkey setup kapag walang existing protected crypto material at walang existing passkey.
  • Para makumpleto ang recovery, kailangang tumugma ang passkey credential ID na registered sa recovery transaction sa completion request.
  • Nire-revoke ang old passkeys pagkatapos ng successful account recovery para ang new passkey ang maging trusted credential.

Ano ang hindi ibig sabihin nito

Hindi ito claim na ang 12-character human-readable code ay 256-bit offline secret. Ang PayCal account recovery ay online, server-mediated, two-factor recovery flow. Isang factor ang Recovery Code; isa pa ang inbox access at transaction state; ang passkey registration ang final device-bound step.

Mahalaga ang distinction na iyon. Ginawa naming readable ang code dahil kailangan itong i-save at i-type nang tama ng tao. Pinanatili naming strict ang server dahil hindi dapat ibig sabihin ng readable recovery ay weak recovery.

Ang rule na ine-enforce namin ngayon

Pinapatunayan ng email code ang inbox access.
Pinapatunayan ng Recovery Code ang possession ng saved-account-secret.
Hindi sapat ang alinman nang mag-isa para sa protected account recovery.

Iyan ang balance na gusto namin: recovery na madaling gamitin, mabilis, at simple para sa account owner, habang sapat na strict para hindi maging practical path ang guessing sa server.