پاس ورڈز ان چیزوں میں سے ایک ہیں جنہیں ہم نے صرف اس لیے معمول بنایا ہے کہ ہم ان کے ساتھ برسوں سے رہتے ہیں۔ صارفین انہیں بھول جاتے ہیں، انہیں دوبارہ استعمال کرتے ہیں، انہیں وہ جگہ لکھتے ہیں جہاں انہیں نہیں کرنا چاہیے۔ ٹیموں کو ری سیٹ، پالیسیاں، ہیش، لیک، فشنگ اور سپورٹ کا انتظام کرنا چاہیے۔
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 کو بہتر بناتے ہیں، جو کہ بہت کم ہے۔ وہ جادو کی چھڑی نہیں ہیں: بحالی، مطابقت، تعاون اور رول آؤٹ کو اچھی طرح سے ڈیزائن کیا جانا باقی ہے۔
لیکن بنیادی تبدیلی مضبوط ہے۔ صارفین سے رازوں کی ایجاد اور حفاظت کے لیے کہنا بند کریں۔ آپ آلہ کو اپنے ڈومین سے منسلک ایک خفیہ ثبوت پر دستخط کرنے دیتے ہیں۔ کم انسانی میموری، کم فشنگ، کم پاس ورڈ ری سیٹ۔ میں کہوں گا کہ وہ سنجیدگی سے لینے کے قابل ہیں۔