Passkey और WebAuthn: बिना पासवर्ड, बिना जादू के लॉगिन करें
· 5 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 एन्क्रिप्शन लागू करते हुए पाते हैं, तो रुकें। एक मजबूत सर्वर-साइड लाइब्रेरी का उपयोग करें। यहां त्रुटियां "सुंदर बग" नहीं हैं, वे प्रमाणीकरण छेद हैं।
डेटाबेस में क्या सेव करना है
आधी दुनिया को बचाने की कोई जरूरत नहीं है. आमतौर पर पर्याप्त:
- क्रेडेंशियल की आईडी;
- सार्वजनिक कुंजी;
- कनेक्टेड उपयोगकर्ता;
- कोई सत्यापन काउंटर या मेटाडेटा;
- परिवहन, यदि यूएक्स के लिए उपयोगी हो;
- उपयोगकर्ता द्वारा चुना गया नाम;
- निर्माण तिथि और अंतिम उपयोग।
एक न्यूनतम तालिका इस तरह दिख सकती है:
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 दिलचस्प हैं क्योंकि वे एक ही समय में सुरक्षा और यूएक्स में सुधार करते हैं, जो दुर्लभ है। वे कोई जादू की छड़ी नहीं हैं: पुनर्प्राप्ति, अनुकूलता, समर्थन और रोलआउट को अच्छी तरह से डिज़ाइन किया जाना बाकी है।
लेकिन बुनियादी बदलाव मजबूत है. उपयोगकर्ताओं से रहस्यों का आविष्कार करने और उन्हें सुरक्षित रखने के लिए कहना बंद करें। आप डिवाइस को अपने डोमेन से जुड़े क्रिप्टोग्राफ़िक प्रमाण पर हस्ताक्षर करने देते हैं। कम मानवीय स्मृति, कम फ़िशिंग, कम पासवर्ड रीसेट। मैं कहूंगा कि वे गंभीरता से लेने लायक हैं।