Passkey এবং WebAuthn: পাসওয়ার্ড ছাড়াই, যাদু ছাড়াই লগইন করুন
· 4 min read · Filippo Spinella · Security, WebAuthn, Authentication, Web Development
পাসওয়ার্ডগুলি সেই জিনিসগুলির মধ্যে একটি যা আমরা স্বাভাবিক করেছি কারণ আমরা তাদের সাথে বছরের পর বছর বেঁচে আছি৷ ব্যবহারকারীরা সেগুলি ভুলে যান, পুনঃব্যবহার করেন, যেখানে তাদের উচিত নয় সেখানে লিখুন৷ দলগুলিকে অবশ্যই রিসেট, নীতি, হ্যাশ, ফাঁস, ফিশিং এবং সমর্থন পরিচালনা করতে হবে।
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 উন্নত করে, যা বিরল। এগুলি কোনও জাদুর কাঠি নয়: পুনরুদ্ধার, সামঞ্জস্যতা, সমর্থন এবং রোলআউটগুলি ভালভাবে ডিজাইন করা উচিত।
কিন্তু মৌলিক পরিবর্তন শক্তিশালী। ব্যবহারকারীদের উদ্ভাবন এবং গোপনীয়তা রক্ষা করতে বলা বন্ধ করুন। আপনি ডিভাইসটিকে আপনার ডোমেনের সাথে সংযুক্ত একটি ক্রিপ্টোগ্রাফিক প্রমাণ স্বাক্ষর করতে দেন। কম মানুষের মেমরি, কম ফিশিং, কম পাসওয়ার্ড রিসেট। আমি বলব যে তারা গুরুত্ব সহকারে নেওয়ার যোগ্য।