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- परिवहन, यदि यूएक्स के लिए उपयोगी हो;
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~
74passkey का डेमो हमेशा सुंदर होता है: आप 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 दिलचस्प हैं क्योंकि वे एक ही समय में सुरक्षा और यूएक्स में सुधार करते हैं, जो दुर्लभ है। वे कोई जादू की छड़ी नहीं हैं: पुनर्प्राप्ति, अनुकूलता, समर्थन और रोलआउट को अच्छी तरह से डिज़ाइन किया जाना बाकी है।
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~