Yönetici özeti
| Neden yaptık | Account recovery hızlı, okunabilir ve sakin olmalı; permissive olmamalı |
| Saved factor | Recovery Code: XXXXXX-XXXXXX-CC, 12 karakter secret ve 2 karakter checksum |
| Email factor | Verification Code: XXXXCC, 4 karakter secret ve 2 karakter checksum |
| Alphabet | ABCDEFGHJKLMNPQRTUWXYZ346789, görsel olarak karışabilecek karakterlerden kaçınmak için seçildi |
| Server limits | 10 dakikalık email-code window, one-time use, attempt limits, resend cooldown, transaction TTL ve abuse telemetry |
| Security boundary | Email code inbox access kanıtlar. Recovery Code saved-account-secret possession kanıtlar. İkisi de protected recovery için tek başına yeterli değildir. |
Çözdüğümüz problem
Recovery normal login değildir. İnsanlar buraya zaten bir şey ters gittiğinde gelir: kayıp cihaz, eksik passkey, yeni telefon veya deadline. Bir recovery design cryptographically sound olabilir ama code çok uzun, okunması zor, kopyalanması zor veya yanlış yazması kolay olduğunda users yine başarısız olabilir.
Amaç recovery sürecini gevşek yapmak değildi. Amaç honest path’i daha az acı verici yapmak ve server’ı strict tutmaktı. Bu; transcription mistakes azaltmak, tüm önemli field’ları tek ekranda tutmak, paste’i forgiving yapmak ve user server response beklemeden önce obvious typos validate etmek anlamına geldi.
Yeni codes
İki code da aynı PayCal accessibility alphabet’i kullanır:
ABCDEFGHJKLMNPQRTUWXYZ346789Okunurken, kopyalanırken, yazdırılırken veya yazılırken sık karışan karakterleri bilinçli olarak hariç tutuyoruz. Inputs uppercase yapılır ve spaces/hyphens kaldırılır; böylece users grouped veya ungrouped formda code paste edebilir.
| Code | Display format | Secret characters | Checksum characters |
|---|---|---|---|
| Recovery Code | XXXXXX-XXXXXX-CC |
12 | 2 |
| Verification Code | XXXXCC |
4 | 2 |
Checksum secret değildir ve security entropy eklemez. Honest mistakes yakalamak için vardır. Son iki karakter secret portion ile eşleşmezse browser hemen “Check the last two characters,” diyebilir; user bir server attempt harcamadan önce.
Matematik
Recovery Code, 28 possible symbol içinden 12 secret character içerir. Bu şunu verir:
28^12 = 232,218,265,089,212,416 possibilities
log2(28^12) ~= 57.7 bitsEmail Verification Code 4 secret character içerir:
28^4 = 614,656 possibilities
log2(28^4) ~= 19.2 bitsİki factor birlikte değerlendirildiğinde secret search space şudur:
28^16 = 142,734,349,946,674,946,768,896 possibilities
log2(28^16) ~= 76.9 bitsSaved Recovery Code’a karşı tek random guess yaklaşık 1 / 232 quadrillion’dır. İki factor’e birlikte karşı tek random guess yaklaşık 1 / 142 septillion’dır. Beş combined guess ile bile chance yaklaşık 3.5 x 10^-23, yani yaklaşık 1 / 28.5 sextillion’dır.
Online brute force neden bu kadar uzun sürer
Önemli ifade online recovery. Attackers PayCal üzerinden hardware’lerinin hesaplayabileceği hızda unlimited guesses çalıştıramaz. Server pace’i kontrol eder, failures sayar, codes expire eder, abuse telemetry kaydeder ve transaction state’in hizalı olmasını gerektirir.
Mevcut conservative defaults ile recovery şu controls tarafından sınırlanır:
- email Verification Codes 10 dakika sonra expire olur;
- email Verification Codes single-use’tur;
- verification ve proof endpoints attempt-limited’tır;
- recovery starts per day limited’tır;
- resends per hour limited’tır ve cooldown vardır;
- server-seen checksum failures abuse telemetry ve attempt policy’ye sayılır;
- recovery transactions ve bootstrap windows expire olur;
- browser değil server authoritative kalır.
Saatte beş guess ile Recovery Code space’in yarısını denemek yaklaşık 2.65 trillion yıl sürerdi. Aynı online pace ile combined Recovery Code plus email-code space’in yarısını denemek yaklaşık 1.63 quintillion yıl sürerdi. “Really, really long time” derken bunu kastediyoruz: user’ın huge code taşıması gerektiği için değil, online recovery multiple factors içerdiği ve server guesses’ın serbestçe koşmasına izin vermediği için.
10 dakikalık pencere
Email code kasıtlı olarak kısadır çünkü account’u tek başına korumak için değildir. Time-limited’tır, user inbox’a teslim edilir, attempt-limited’tır ve success durumunda consumed olur.
614,656 possible email-code secret ile, bir 10-minute code window içinde five guesses email code’u chance ile tahmin etme olasılığını en fazla 0.000813% yapar; yaklaşık 1 / 122,931. Bu yine protected recovery’yi tamamlamaz, çünkü saved Recovery Code ve recovery proof da pass etmelidir.
User experience’ta ne değişti
Recovery screen’i tek centered form’a indirdik. User email field, Verification Code field, Recovery Code field ve tek primary action görür: Verify and continue.
- User email beklerken saved Recovery Code paste edebilir.
- Spaces ve hyphens accepted ve normalized edilir.
- Recovery Codes
XXXXXX-XXXXXX-CColarak auto-format edilir. - Verification Codes
XXXXCColarak auto-format edilir. - Invalid alphabet characters clear inline message gösterir.
- Checksum failures server request öncesi locally yakalanır.
- İki format da doğru görünürse form “Checking...” gösterir ve short debounce sonrasında automatically submit eder.
- Verify and continue button fallback olarak available kalır.
Normal user için sonuç daha hızlıdır: fewer steps, fewer surprises, less hidden state ve spaces/hyphens ile code kopyalamaya less punishment.
Security model’de ne değişti
Redesign ayrıca birkaç recovery boundary’yi sıkılaştırdı:
- Raw Recovery Codes email ile gönderilmez. Oluşturulduğunda bir kez gösterilir ve user tarafından kaydedilmelidir.
- PayCal recovery-wrapped material ve verifier state saklar, raw Recovery Code saklamaz.
- Magic links mevcut protected account’u tek başına passkey-ready yapamaz.
- Email-only bootstrap yalnızca existing protected crypto material ve existing passkey yoksa first-passkey setup için allowed’tır.
- Recovery completion, recovery transaction’da registered passkey credential ID’nin completion request ile eşleşmesini gerektirir.
- Successful account recovery sonrasında old passkeys revoked olur; böylece new passkey trusted credential olur.
Bu ne anlama gelmez
Bu, 12-character human-readable code’un 256-bit offline secret olduğu iddiası değildir. PayCal account recovery online, server-mediated, two-factor recovery flow’dur. Recovery Code bir factor’dür; inbox access ve transaction state başka bir factor’dür; passkey registration final device-bound step’tir.
Bu ayrım önemlidir. Code’u readable yaptık çünkü insanların onu kaydetmesi ve doğru yazması gerekir. Server’ı strict tuttuk çünkü readable recovery weak recovery anlamına gelmemelidir.
Artık uyguladığımız rule
Email code inbox access kanıtlar.
Recovery Code saved-account-secret possession kanıtlar.
Protected account recovery için tek başına hiçbiri yeterli değildir.İstediğimiz denge buydu: account owner için kolay, hızlı ve simple hissettiren recovery; ama server üzerinden guessing’i pratik bir yol olmaktan çıkaracak kadar strict kalan recovery.