1 
2گذرواژه‌ها یکی از آن چیزهایی هستند که فقط به این دلیل که سال‌ها با آن‌ها زندگی کرده‌ایم، آن را عادی کرده‌ایم. کاربران آنها را فراموش می کنند، دوباره از آنها استفاده می کنند، آنها را در جایی که نباید بنویسند. تیم ها باید بازنشانی ها، خط مشی ها، هش ها، نشت ها، فیشینگ و پشتیبانی را مدیریت کنند.
3 
4passkey احراز هویت را کامل نمی‌کند، اما یک مشکل بزرگ را برطرف می‌کند: سرور دیگر مجبور نیست رازی را با کاربر به اشتراک بگذارد.
5 
6## واقعا چه اتفاقی می افتد
7 
8A passkey اعتباری بر اساس WebAuthn است. هنگامی که کاربر آن را ایجاد می کند، دستگاه یک جفت کلید تولید می کند:
9 
10- یک کلید خصوصی که در دستگاه یا در مدیر رمز عبور باقی می ماند.
11- یک کلید عمومی که سرور می تواند آن را ذخیره کند.
12 
13هنگام ورود به سرور، "رمز عبور را به من بگویید" نمی پرسد. ارسال یک چالش تصادفی دستگاه آن را با کلید خصوصی امضا می کند. سرور امضا را با کلید عمومی تأیید می کند.
14 
15این بخش خوب است: اگر پایگاه داده به سرقت رفته باشد، هیچ رمز عبوری برای شکستن وجود ندارد. و اگر کاربر به یک دامنه جعلی ختم شود، passkey برای آن دامنه معتبر نیست. این فقط راحتی نیست، بلکه محافظتی ملموس در برابر فیشینگ است.
16 
17## مرورگر به عنوان یک پل عمل می کند
18 
19در مرورگر دو API اصلی عبارتند از:
20 
21- `navigator.credentials.create()` برای ایجاد passkey؛
22- `navigator.credentials.get()` برای استفاده از آن در هنگام ورود.
23 
24اما منطق مهم روی سرور است. سرور باید چالش را ایجاد کند، آن را به طور موقت ذخیره کند، پاسخ را تأیید کند، منبع و Relying Party ID را بررسی کند، سپس جلسه را ایجاد کند.
25 
26بخش مشتری باید تقریبا خسته کننده باشد:
27 
28```typescript
29const options = await fetch('/api/passkeys/login/options').then((r) => r.json());
30 
31const credential = await navigator.credentials.get({
32  publicKey: PublicKeyCredential.parseRequestOptionsFromJSON(options),
33});
34 
35await fetch('/api/passkeys/login/verify', {
36  method: 'POST',
37  headers: { 'Content-Type': 'application/json' },
38  body: JSON.stringify(credential?.toJSON()),
39});
40```
41 
42اگر متوجه شدید که رمزگذاری WebAuthn را با دست اجرا می‌کنید، متوقف شوید. از یک کتابخانه قوی سمت سرور استفاده کنید. خطاهای اینجا "اشکالات زیبا" نیستند، بلکه حفره های احراز هویت هستند.
43 
44## چه چیزی در پایگاه داده ذخیره شود
45 
46نیازی به نجات نیمی از جهان نیست. معمولا به اندازه کافی:
47 
48- شناسه اعتبار؛
49- کلید عمومی؛
50- کاربر متصل؛
51- هر شمارنده یا ابرداده تأیید؛
52- حمل و نقل، اگر برای UX مفید باشد.
53- نام انتخاب شده توسط کاربر؛
54- تاریخ ایجاد و آخرین استفاده.
55 
56یک جدول مینیمال ممکن است به شکل زیر باشد:
57 
58```sql
59create table passkey_credentials (
60  id uuid primary key default gen_random_uuid(),
61  user_id uuid not null references users(id),
62  credential_id text not null unique,
63  public_key text not null,
64  name text,
65  created_at timestamptz not null default now(),
66  last_used_at timestamptz
67);
68```
69 
70سپس گزارش‌های حسابرسی و اعلان‌ها را اضافه می‌کنم: اگر شخصی یک passkey جدید در حساب من ایجاد کند، می‌خواهم در مورد آن بدانم.
71 
72## UX مهمتر از نسخه ی نمایشی است
73 
74نسخه نمایشی یک passkey همیشه زیبا است: شما کلیک می‌کنید، Face ID، وارد می‌شوید. محصول واقعی پیچیده‌تر است.
75 
76یکی گوشیشو عوض میکنه شخصی از رایانه شرکت قفل شده استفاده می کند. برخی از مردم نمی دانند که چرا مرورگر یک passkey را پیشنهاد می کند. شخصی دسترسی به دستگاه خود را از دست می دهد.
77 
78به همین دلیل است که من با "از امروز دیگر پسورد برای همه وجود ندارد" شروع نمی کنم. من اینطور شروع می کنم:
79 
801. passkey اختیاری برای کاربران داخلی؛
812. پیشنهاد برای ایجاد یکی پس از ورود موفق.
823. صفحه حساب برای تغییر نام و حذف passkey؛
834. بازگشت روشن;
845. عرضه تدریجی در ورود به سیستم اصلی.
85 
86متن در رابط باید ساده باشد. «از صفحه قفل دستگاه خود استفاده کنید» بهتر از «تأیید هویت با اعتبارنامه FIDO2 مقیم» است.
87 
88## اشتباهاتی که از آنها اجتناب می کردم
89 
90برای مشتری چالش ایجاد نکنید. چالش بر روی سرور ایجاد می شود و باید فقط یک بار تأیید شود.
91 
92فقط به شناسه اعتبار اعتماد نکنید. باید امضا، چالش، مبدا و Relying Party ID را تأیید کنید.
93 
94قبل از اینکه جریان بازیابی خوبی داشته باشید، بک گراندها را حذف نکنید. بدون رمز نیازی نیست که تبدیل به "اگر تلفن خود را گم کنید برای همیشه خارج هستید".
95 
96passkey را به‌عنوان یک دکمه کاملاً ظاهری در نظر نگیرید. پنهان کردن یک دکمه امنیت نیست: تأیید واقعی در سمت سرور است.
97 
98## Passkey-اول یا passkey دوستانه؟
99 
100برای یک محصول جدید می توانید ابتدا passkey فکر کنید. برای یک برنامه موجود، من passkey دوستانه را ترجیح می دهم: passkey را به عنوان یک روش توصیه شده اضافه کنید، موفقیت و مشکلات را اندازه گیری کنید، سپس وزن رمز عبور را با آرامش کاهش دهید.
101 
102مهاجرت ایده آل احساس نمی شود. کاربر متوجه می شود که ورود آسان تر است، نه اینکه شرکت پروتکل احراز هویت خود را تغییر داده است.
103 
104## نتیجه گیری
105 
106passkey جالب هستند زیرا امنیت و UX را همزمان بهبود می‌بخشند، که نادر است. آنها یک عصای جادویی نیستند: بازیابی، سازگاری، پشتیبانی و عرضه باید به خوبی طراحی شوند.
107 
108اما تغییر اساسی قوی است. از درخواست از کاربران برای اختراع و محافظت از اسرار خودداری کنید. شما به دستگاه اجازه می دهید یک مدرک رمزنگاری مرتبط با دامنه شما را امضا کند. حافظه انسانی کمتر، فیشینگ کمتر، بازنشانی رمز عبور کمتر. می‌توانم بگویم ارزش جدی گرفتن را دارند.
109 
110## منابع
111 
112- [MDN: Passkeys](https://developer.mozilla.org/en-US/docs/Web/Security/Authentication/Passkeys)
113- [MDN: Web Authentication API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API)
114- [W3C: Web Authentication](https://www.w3.org/TR/webauthn-3/)
115- [passkeys.dev](https://passkeys.dev/)
116