Passkeys/WebAuthn: مفهوم، Registration و Recovery

Passkey فقط «passwordی که جای بهتری ذخیره شده» نیست. در WebAuthn، یک Relying Party از مرورگر و authenticator برای ساخت یا استفاده از public-key credential کمک می‌گیرد و server باید ceremony را با challenge، RP ID، origin و policy مورد انتظار خودش verify کند. recovery هم یک مسیر فرعی بی‌اهمیت نیست؛ اگر recovery از sign-in اصلی ضعیف‌تر باشد، مرز حساب عملاً از همان مسیر ضعیف تعریف می‌شود. این درس فقط یک fixture محلی، deterministic و synthetic دارد و هیچ credential واقعی، account واقعی، authenticator فیزیکی یا target بیرونی را لمس نمی‌کند.

1. مسئله قبل از دکمه «ورود با Passkey»

سناریو یک relying party مصنوعی در https://login.example.test است. learner باید registration و authentication را به‌صورت ceremonyهای جدا ببیند و برای هرکدام state سمت server را ثبت کند. سؤال اصلی این نیست که UI کار کرد یا نه؛ سؤال این است که server چه چیزی را صادر کرد، چه چیزی برگشت، چه چیزی verify شد و کدام فرض امنیتی هنوز اثبات نشده است.

2. خروجی محدود درس

خروجی شما WebAuthn Registration & Recovery Record v1 است. هر ردیف باید Ceremony، RP ID، Origin، Challenge State، Credential ID، User Verification Policy، Server Verification Result، Recovery Path، Negative Probe، Evidence و Residual Decision را ثبت کند.

3. این درس چه چیزی را ثابت نمی‌کند

این fixture production security را ثابت نمی‌کند. همه passkeyها sync/backup/attestation یکسان ندارند. challenge فقط وقتی مفید است که server آن را تولید، نگهداری و روی پاسخ verify کند. recovery نمی‌تواند صرفاً چون «استثنا» است با factor ضعیف‌تر بدون تصمیم risk-based مجاز شود. همچنین این درس TOTP و recovery code درس بعد را جذب نمی‌کند.

4. Public-key credential

مدل مفهومی درس این است: private credential material داخل authenticator باقی می‌ماند و relying party برای credential ثبت‌شده public material و metadata لازم برای verification را نگه می‌دارد. fixture هیچ private key واقعی تولید یا export نمی‌کند؛ فقط boundary را مدل می‌کند.

5. Relying Party و RP ID

RP ID بخشی از scope credential است. baseline از login.example.test استفاده می‌کند. learner باید RP ID مورد انتظار server را از origin کامل جدا نگه دارد: origin شامل scheme و host است، اما RP ID مدل دامنه‌ای جداگانه دارد. fixture mismatch عمدی RP ID را رد می‌کند.

6. Origin

Baseline origin برابر https://login.example.test است. server در fixture فقط origin مورد انتظار خودش را قبول می‌کند. mutation origin_mismatch نشان می‌دهد صرف داشتن credential id درست کافی نیست؛ response با origin غیرمنتظره باید در verification boundary رد شود.

7. Challenge به‌عنوان state سمت server

Registration و authentication هرکدام challenge synthetic جدا دارند. challenge در fixture server-generated model است، deadline دارد و پس از مصرف دوباره معتبر نیست. learner باید بین «challenge موجود در پاسخ» و «challenge مورد انتظار و هنوز معتبر سمت server» فرق بگذارد.

8. Freshness و replay

Probe expired_registration_challenge deadline را عمداً می‌شکند. classification درست EXPIRED_CHALLENGE_REJECTED است. Probe دیگری challenge اشتباه را در authentication می‌فرستد و باید CHALLENGE_MISMATCH_REJECTED شود. این‌ها exploit نیستند؛ mutationهای deterministic روی داده مصنوعی‌اند.

9. Registration ceremony

در registration، server گزینه‌های synthetic شامل RP ID، origin expectation، challenge و userVerification=required را صادر می‌کند. virtual authenticator یک credential id و public material مصنوعی برمی‌گرداند. server فقط در صورت تطبیق ceremony inputs آن credential را به synthetic account record متصل می‌کند.

10. Authentication ceremony

Authentication از challenge تازه و credential ثبت‌شده استفاده می‌کند. fixture بررسی می‌کند credential به RP مورد انتظار مربوط است، origin و challenge درست‌اند و user verification مطابق policy انجام شده است. success فقط نتیجه همین boundary محدود است.

11. User Verification

userVerification=required در این fixture یک policy صریح relying party است. منظور این نیست که server biometric secret دریافت می‌کند. fixture فقط یک boolean observation مصنوعی دارد که نشان می‌دهد authenticator policy مورد انتظار را برآورده کرده یا نه.

12. Credential ID و material

credential_id یک شناسه مصنوعی است. learner نباید آن را private secret فرض کند و نباید از وجود آن alone نتیجه بگیرد که ceremony معتبر بوده است. verification به context کامل ceremony وابسته است.

13. Fact، Observation و Inference

expected_rp_id=login.example.test یک fact پیکربندی است. origin mismatch rejected یک observation در fixture است. «پس deployment واقعی در برابر همه حملات phishing امن است» inference خارج از evidence این درس است. Record باید این سه سطح را جدا نگه دارد.

14. Positive Evidence برای Registration

Positive registration باید نشان دهد challenge معتبر و unused بوده، RP ID و origin match شده‌اند، policy user verification رعایت شده و server credential synthetic را ثبت کرده است. فقط وجود credential id evidence کافی نیست.

15. Positive Evidence برای Authentication

Positive authentication باید نشان دهد credential قبلاً ثبت شده، challenge تازه است، expected RP/origin برقرار است و user verification مورد انتظار مشاهده شده است. Record باید نتیجه را VERIFIED_AUTHENTICATION نگه دارد، نه claim کلی «account secure».

16. Negative Evidence: challenge منقضی

Learner registration را با challenge منقضی replay می‌کند. انتظار EXPIRED_CHALLENGE_REJECTED است. evidence باید deadline/state و نتیجه server verification را ثبت کند.

17. Negative Evidence: challenge اشتباه

در authentication، response یک challenge synthetic دیگر حمل می‌کند. انتظار CHALLENGE_MISMATCH_REJECTED است. این probe نشان می‌دهد client-supplied value بدون مقایسه با state server قابل اعتماد نیست.

18. Negative Evidence: origin اشتباه

origin_mismatch origin را به https://evil.example.test تغییر می‌دهد. fixture باید ORIGIN_MISMATCH_REJECTED بدهد. هدف فقط اثبات enforcement همان allowlist مصنوعی است؛ درباره browserهای واقعی یا حمله بیرونی claim اضافه نمی‌شود.

19. Negative Evidence: RP ID اشتباه

rp_id_mismatch RP ID را از baseline جدا می‌کند و باید RP_ID_MISMATCH_REJECTED شود. Record باید RP ID و origin را دو ستون جدا حفظ کند تا learner این دو boundary را یکی نگیرد.

20. Negative Evidence: User Verification missing

اگر policy required باشد ولی virtual authenticator observation آن را false نشان دهد، server-side model باید USER_VERIFICATION_REQUIRED بدهد. این classification فقط policy fixture را ثابت می‌کند.

21. Recovery یک authentication bypass رایگان نیست

Lost-device scenario یک recovery decision می‌سازد. baseline recovery path از backup authenticator یا supervised identity proofing برای controlled re-enrollment استفاده می‌کند. مسیر synthetic email_only_link عمداً ضعیف‌تر علامت‌گذاری شده و بدون justification پذیرفته نمی‌شود.

22. Recovery و re-enrollment

Recovery هدفش بازگرداندن account authority است، پس به credential assurance مرتبط است. Record باید مشخص کند کدام path مجاز است، چه evidenceای برای identity proofing یا backup authenticator وجود دارد و credentialهای قبلی چه lifecycleی خواهند داشت. این درس یک معماری universal تجویز نمی‌کند.

23. Synced در برابر device-bound

Transfer Case عمداً یک staff portal با device-bound credential را مطرح می‌کند. learner نباید assumptionهای sync/backup baseline را به آن منتقل کند. Record باید user-verification و recovery evidence را از نو با context جدید ارزیابی کند.

24. Mutation: weaker recovery shortcut

در probe weak_recovery_shortcut recovery path به email_only_link تغییر می‌کند. fixture باید WEAK_RECOVERY_REJECTED برگرداند. learner باید دلیل bounded rejection را ثبت کند، نه اینکه هر email-based flow واقعی را بدون context ناامن اعلام کند.

25. Evidence completeness

اگر یکی از 11 field اصلی artifact حذف یا blank شود، validator باید EVIDENCE_INCOMPLETE بدهد. نتیجه امنیتی بدون row-level traceability قابل قبول نیست، حتی اگر happy path سبز باشد.

26. اجرای Lab

از lab://SEC-004/SEC004-LAB1 استفاده کنید. ابتدا static_preflight.py، سپس run_local_lab.py و در پایان run_checks.py را اجرا کنید. همه داده‌ها synthetic هستند؛ network، real credential و external target لازم نیست.

27. Baseline را قبل از mutation ثبت کنید

ابتدا registration و authentication baseline را اجرا و output خام را نگه دارید. بعد mutationها را یکی‌یکی اجرا کنید. اگر baseline و mutation همزمان تغییر کنند، evidence attribution ضعیف می‌شود.

28. WebAuthn Registration & Recovery Record v1

برای هر ceremony یا recovery decision یک row مستقل بسازید. Server Verification Result باید observation باشد. Residual Decision باید چیزی را که هنوز ثابت نشده صریح نگه دارد و تصمیم accountable را از automation جدا کند.

29. Diagram ذهنی

مسیر اصلی: RP server challenge → browser/WebAuthn ceremony → virtual authenticator operation → server verification → bounded session authority. شاخه recovery جداست و فقط از یک controlled recovery gate به re-enrollment برمی‌گردد. هیچ edgeای نباید بدون evidence به «secure» ختم شود.

30. Transfer Case

Transfer Case: یک staff portal مصنوعی برای role پرریسک از device-bound credential استفاده می‌کند. learner باید user-verification و recovery evidence را دوباره ارزیابی کند و نباید sync/backup properties baseline را فرض بگیرد. تصمیم نهایی باید مستقل نوشته شود.

31. ارزیابی نهایی

پایان موفق یعنی learner بتواند registration و authentication را trace کند، challenge/origin/RP-ID/user-verification evidence را جدا ثبت کند، حداقل یک negative probe را توضیح دهد، weak recovery shortcut را با bounded reasoning رد یا defer کند و changed-context decision را مستقل بنویسد.

32. منابع و freshness

Source boundary این درس دقیقاً سه مرجع frozen دارد: W3C-WEBAUTHN-L3، FIDO-PASSKEYS و FIDO-PASSKEY-RECOVERY. snapshot در 2026-09-02 ثبت شده و earliest review_due برابر 2026-10-02 است. Query 1 در 2026-09-16 هنوز داخل window است. یک current-primary-source check نیز بدون افزودن source یا گسترش claim boundary انجام شده است.

33. مرز مسئولیت انسانی

AI می‌تواند بعد از بیان objective، probe دفاعی پیشنهاد کند یا observationهای synthetic را مرتب کند. حق ندارد evidence ندیده بسازد، یک ceremony سبز را proof امنیت کلی بنامد یا تصمیم نهایی recovery/risk/owner را به‌جای learner بگیرد.