گذرواژهها یکی از آن چیزهایی هستند که فقط به این دلیل که سالها با آنها زندگی کردهایم، آن را عادی کردهایم. کاربران آنها را فراموش می کنند، دوباره از آنها استفاده می کنند، آنها را در جایی که نباید بنویسند. تیم ها باید بازنشانی ها، خط مشی ها، هش ها، نشت ها، فیشینگ و پشتیبانی را مدیریت کنند.
passkey احراز هویت را کامل نمیکند، اما یک مشکل بزرگ را برطرف میکند: سرور دیگر مجبور نیست رازی را با کاربر به اشتراک بگذارد.
واقعا چه اتفاقی می افتد
A passkey اعتباری بر اساس WebAuthn است. هنگامی که کاربر آن را ایجاد می کند، دستگاه یک جفت کلید تولید می کند:
- یک کلید خصوصی که در دستگاه یا در مدیر رمز عبور باقی می ماند.
- یک کلید عمومی که سرور می تواند آن را ذخیره کند.
هنگام ورود به سرور، "رمز عبور را به من بگویید" نمی پرسد. ارسال یک چالش تصادفی دستگاه آن را با کلید خصوصی امضا می کند. سرور امضا را با کلید عمومی تأیید می کند.
این بخش خوب است: اگر پایگاه داده به سرقت رفته باشد، هیچ رمز عبوری برای شکستن وجود ندارد. و اگر کاربر به یک دامنه جعلی ختم شود، passkey برای آن دامنه معتبر نیست. این فقط راحتی نیست، بلکه محافظتی ملموس در برابر فیشینگ است.
مرورگر به عنوان یک پل عمل می کند
در مرورگر دو API اصلی عبارتند از:
navigator.credentials.create()برای ایجاد passkey؛navigator.credentials.get()برای استفاده از آن در هنگام ورود.
اما منطق مهم روی سرور است. سرور باید چالش را ایجاد کند، آن را به طور موقت ذخیره کند، پاسخ را تأیید کند، منبع و Relying Party ID را بررسی کند، سپس جلسه را ایجاد کند.
بخش مشتری باید تقریبا خسته کننده باشد:
const options = await fetch('/api/passkeys/login/options').then((r) => r.json()); const credential = await navigator.credentials.get({ publicKey: PublicKeyCredential.parseRequestOptionsFromJSON(options), }); await fetch('/api/passkeys/login/verify', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(credential?.toJSON()), });
اگر متوجه شدید که رمزگذاری WebAuthn را با دست اجرا میکنید، متوقف شوید. از یک کتابخانه قوی سمت سرور استفاده کنید. خطاهای اینجا "اشکالات زیبا" نیستند، بلکه حفره های احراز هویت هستند.
چه چیزی در پایگاه داده ذخیره شود
نیازی به نجات نیمی از جهان نیست. معمولا به اندازه کافی:
- شناسه اعتبار؛
- کلید عمومی؛
- کاربر متصل؛
- هر شمارنده یا ابرداده تأیید؛
- حمل و نقل، اگر برای UX مفید باشد.
- نام انتخاب شده توسط کاربر؛
- تاریخ ایجاد و آخرین استفاده.
یک جدول مینیمال ممکن است به شکل زیر باشد:
create table passkey_credentials ( id uuid primary key default gen_random_uuid(), user_id uuid not null references users(id), credential_id text not null unique, public_key text not null, name text, created_at timestamptz not null default now(), last_used_at timestamptz );
سپس گزارشهای حسابرسی و اعلانها را اضافه میکنم: اگر شخصی یک passkey جدید در حساب من ایجاد کند، میخواهم در مورد آن بدانم.
UX مهمتر از نسخه ی نمایشی است
نسخه نمایشی یک passkey همیشه زیبا است: شما کلیک میکنید، Face ID، وارد میشوید. محصول واقعی پیچیدهتر است.
یکی گوشیشو عوض میکنه شخصی از رایانه شرکت قفل شده استفاده می کند. برخی از مردم نمی دانند که چرا مرورگر یک passkey را پیشنهاد می کند. شخصی دسترسی به دستگاه خود را از دست می دهد.
به همین دلیل است که من با "از امروز دیگر پسورد برای همه وجود ندارد" شروع نمی کنم. من اینطور شروع می کنم:
- passkey اختیاری برای کاربران داخلی؛
- پیشنهاد برای ایجاد یکی پس از ورود موفق.
- صفحه حساب برای تغییر نام و حذف passkey؛
- بازگشت روشن;
- عرضه تدریجی در ورود به سیستم اصلی.
متن در رابط باید ساده باشد. «از صفحه قفل دستگاه خود استفاده کنید» بهتر از «تأیید هویت با اعتبارنامه FIDO2 مقیم» است.
اشتباهاتی که از آنها اجتناب می کردم
برای مشتری چالش ایجاد نکنید. چالش بر روی سرور ایجاد می شود و باید فقط یک بار تأیید شود.
فقط به شناسه اعتبار اعتماد نکنید. باید امضا، چالش، مبدا و Relying Party ID را تأیید کنید.
قبل از اینکه جریان بازیابی خوبی داشته باشید، بک گراندها را حذف نکنید. بدون رمز نیازی نیست که تبدیل به "اگر تلفن خود را گم کنید برای همیشه خارج هستید".
passkey را بهعنوان یک دکمه کاملاً ظاهری در نظر نگیرید. پنهان کردن یک دکمه امنیت نیست: تأیید واقعی در سمت سرور است.
Passkey-اول یا passkey دوستانه؟
برای یک محصول جدید می توانید ابتدا passkey فکر کنید. برای یک برنامه موجود، من passkey دوستانه را ترجیح می دهم: passkey را به عنوان یک روش توصیه شده اضافه کنید، موفقیت و مشکلات را اندازه گیری کنید، سپس وزن رمز عبور را با آرامش کاهش دهید.
مهاجرت ایده آل احساس نمی شود. کاربر متوجه می شود که ورود آسان تر است، نه اینکه شرکت پروتکل احراز هویت خود را تغییر داده است.
نتیجه گیری
passkey جالب هستند زیرا امنیت و UX را همزمان بهبود میبخشند، که نادر است. آنها یک عصای جادویی نیستند: بازیابی، سازگاری، پشتیبانی و عرضه باید به خوبی طراحی شوند.
اما تغییر اساسی قوی است. از درخواست از کاربران برای اختراع و محافظت از اسرار خودداری کنید. شما به دستگاه اجازه می دهید یک مدرک رمزنگاری مرتبط با دامنه شما را امضا کند. حافظه انسانی کمتر، فیشینگ کمتر، بازنشانی رمز عبور کمتر. میتوانم بگویم ارزش جدی گرفتن را دارند.