पासकी: क्या बिल्ली है और क्यों?

पासकी: क्या बिल्ली है और क्यों?

समय टिकट: 12 अप्रैल, 2023 1:41 PM

ये बातें कहलाती हैं पासकी यकीन है कि इन दिनों चक्कर लगा रहे हैं। में मुख्य आकर्षण रहे डब्ल्यू3सी टीपीएसी 2022, में समर्थन मिला सफारी 16में अपना रास्ता खोज रहे हैं मैकओएस और आईओएस, और होने वाले हैं 1Password जैसे पासवर्ड प्रबंधकों का भविष्य। वो हैं पहले से ही समर्थित है एंड्रॉइड में, और जल्द ही भविष्य के रिलीज में क्रोम ओएस और विंडोज़ में अपना रास्ता खोज लेंगे।

गीकी ओएस सुरक्षा संवर्द्धन वास्तव में फ्रंट-एंड समुदाय में बड़ी सुर्खियां नहीं बनाते हैं, लेकिन इसका कारण यह है कि पासकी एक "बात" बनने जा रही है। और इस बात पर विचार करते हुए कि कैसे पासवर्ड और पासवर्ड ऐप्स प्रमाणीकरण और फॉर्म प्रोसेसिंग जैसी चीजों के उपयोगकर्ता अनुभव को प्रभावित करते हैं, हम कम से कम अपने दिमाग को उनके चारों ओर लपेटना चाहते हैं, इसलिए हम जानते हैं कि क्या आ रहा है।

इस लेख का सार यही है। मैं पिछले कुछ समय से पासकीज़ के साथ अध्ययन और प्रयोग कर रहा हूँ — और WebAuthn API जिसके ऊपर वे बनाए गए हैं। मैंने जो सीखा है उसे साझा करने देता हूं।

विषय - सूची

शब्दावली

यहां उस शब्दावली का अनिवार्य खंड है जिसे आप जानना चाहते हैं, जैसा कि हम खोदते हैं। अधिकांश तकनीक की तरह, पासकी गूढ़ शब्दाडंबर और संक्षिप्तीकरण के साथ गढ़ी जाती हैं जो अक्सर समझने में बाधा होती हैं। मैं यहां आपके लिए कई रहस्योद्घाटन करने की कोशिश करूंगा।

  • भरोसेमंद पार्टी: जिस सर्वर के खिलाफ आप प्रमाणीकरण करेंगे। हम इस लेख में "सर्वर" का उपयोग आश्रित पक्ष को दर्शाने के लिए करेंगे।
  • ग्राहक: हमारे मामले में, वेब ब्राउज़र या ऑपरेटिंग सिस्टम।
  • प्रमाणक: सॉफ़्टवेयर और/या हार्डवेयर डिवाइस जो सार्वजनिक कुंजी जोड़े के लिए जनरेशन और स्टोरेज की अनुमति देते हैं।
  • FIDO: एक खुला मानक निकाय जो FIDO क्रेडेंशियल्स के आसपास विनिर्देश भी बनाता है।
  • WebAuthn: पासकी के लिए अंतर्निहित प्रोटोकॉल, जिसे a के रूप में भी जाना जाता है FIDO2 क्रेडेंशियल या सिंगल-डिवाइस FIDO क्रेडेंशियल्स।
  • पासकी: WebAuthn, लेकिन क्लाउड सिंकिंग के साथ (जिसे मल्टी-डिवाइस FIDO क्रेडेंशियल्स, खोजने योग्य क्रेडेंशियल्स या रेजिडेंट क्रेडेंशियल्स भी कहा जाता है)।
  • सार्वजनिक कुंजी क्रिप्टोग्राफी: एक जनरेट की गई कुंजी जोड़ी जिसमें एक निजी और सार्वजनिक कुंजी शामिल है। एल्गोरिदम के आधार पर, इसका उपयोग या तो हस्ताक्षर करने और सत्यापन करने या एन्क्रिप्ट करने और डिक्रिप्ट करने के लिए किया जाना चाहिए। इसे इस रूप में भी जाना जाता है असममित क्रिप्टोग्राफी.
  • आरएसए: रचनाकारों के नाम, रिवेस्ट शमीर और एडेल का संक्षिप्त नाम। आरएसए फैक्टरिंग प्राइम्स के आधार पर सार्वजनिक कुंजी क्रिप्टोग्राफी का एक पुराना, लेकिन अभी भी उपयोगी परिवार है।
  • अण्डाकार वक्र क्रिप्टोग्राफी (ईसीसी): क्रिप्टोग्राफी का एक नया परिवार अण्डाकार वक्रों के आधार पर.
  • ES256: एक दीर्घवृत्त वक्र सार्वजनिक कुंजी जो ECDSA हस्ताक्षर एल्गोरिथम का उपयोग करती है (पीडीएफ) संग SHA256 हैशिंग के लिए।
  • 256 रुपये: ES256 की तरह, लेकिन यह RSA का उपयोग करता है RSASSA-PKCS1-v1.5 और SHA256।

पासकी क्या हैं?

इससे पहले कि हम विशेष रूप से पासकी के बारे में बात कर सकें, हमें एक अन्य प्रोटोकॉल के बारे में बात करने की आवश्यकता है जिसे कहा जाता है WebAuthn (FIDO2 के रूप में भी जाना जाता है)। पासकी एक विनिर्देश है जो WebAuthn के ऊपर बनाया गया है। WebAuthn पासवर्ड बदलने के लिए सार्वजनिक कुंजी क्रिप्टोग्राफी की अनुमति देता है। हम किसी प्रकार के सुरक्षा उपकरण का उपयोग करते हैं, जैसे हार्डवेयर कुंजी या विश्वसनीय प्लेटफ़ॉर्म मॉड्यूल (TPM), निजी और सार्वजनिक कुंजियाँ बनाने के लिए।

सार्वजनिक कुंजी सभी के उपयोग के लिए है। हालाँकि, निजी कुंजी को उस उपकरण से हटाया नहीं जा सकता है जिसने इसे उत्पन्न किया है। यह WebAuthn के मुद्दों में से एक था; यदि आप डिवाइस खो देते हैं, तो आप पहुंच खो देते हैं।

पासकी आपके क्रेडेंशियल्स का क्लाउड सिंक प्रदान करके इसे हल करता है। दूसरे शब्दों में, जो आप अपने कंप्यूटर पर उत्पन्न करते हैं, उसका उपयोग अब आपके फोन पर भी किया जा सकता है (हालांकि भ्रामक रूप से, सिंगल-डिवाइस क्रेडेंशियल्स भी हैं)।

वर्तमान में, लेखन के समय, केवल iOS, macOS और Android क्लाउड-सिंक किए गए पासकी के लिए पूर्ण समर्थन प्रदान करते हैं, और तब भी, वे उपयोग किए जा रहे ब्राउज़र द्वारा सीमित होते हैं। Google और Apple उनके माध्यम से सिंक करने के लिए एक इंटरफ़ेस प्रदान करते हैं गूगल पासवर्ड मैनेजर और ऐप्पल आईक्लाउड किचेन सेवाएं, क्रमशः।

पासकी पासवर्ड कैसे बदलते हैं?

सार्वजनिक कुंजी क्रिप्टोग्राफ़ी में, आप वह कर सकते हैं जिसे जाना जाता है पर हस्ताक्षर. साइनिंग डेटा का एक टुकड़ा लेता है और फिर इसे निजी कुंजी के साथ एक हस्ताक्षर एल्गोरिदम के माध्यम से चलाता है, जहां इसे सार्वजनिक कुंजी से सत्यापित किया जा सकता है।

कोई भी सार्वजनिक कुंजी जोड़ी उत्पन्न कर सकता है, और यह किसी व्यक्ति के लिए जिम्मेदार नहीं है क्योंकि कोई भी व्यक्ति इसे पहले स्थान पर उत्पन्न कर सकता था। यह क्या उपयोगी बनाता है कि केवल निजी कुंजी के साथ हस्ताक्षरित डेटा को सार्वजनिक कुंजी से सत्यापित किया जा सकता है। यह वह भाग है जो एक पासवर्ड को प्रतिस्थापित करता है - एक सर्वर सार्वजनिक कुंजी को संग्रहीत करता है, और हम यह सत्यापित करके साइन इन करते हैं कि हमारे पास अन्य आधा (जैसे निजी कुंजी) है, एक यादृच्छिक चुनौती पर हस्ताक्षर करके।

एक अतिरिक्त लाभ के रूप में, चूंकि हम एक डेटाबेस के भीतर उपयोगकर्ता की सार्वजनिक कुंजियों को संग्रहीत कर रहे हैं, लाखों उपयोगकर्ताओं को प्रभावित करने वाले पासवर्ड उल्लंघनों से अब कोई चिंता नहीं है। यह फ़िशिंग, उल्लंघनों और कई अन्य सुरक्षा मुद्दों को कम करता है जो वर्तमान में हमारे पासवर्ड-निर्भर दुनिया का सामना करते हैं। यदि किसी डेटाबेस का उल्लंघन किया जाता है, तो वह सब कुछ जो उपयोगकर्ता की सार्वजनिक कुंजी में संग्रहीत होता है, जिससे हमलावर के लिए यह लगभग बेकार हो जाता है।

कोई और भूले हुए ईमेल और उनसे जुड़े पासवर्ड भी नहीं! ब्राउज़र याद रखेगा कि आपने किस वेबसाइट के लिए कौन से क्रेडेंशियल्स का उपयोग किया है - आपको केवल कुछ क्लिक करने की आवश्यकता है, और आप लॉग इन हैं। आप पासकी का उपयोग करने के लिए सत्यापन का एक माध्यमिक साधन प्रदान कर सकते हैं, जैसे बायोमेट्रिक्स या पिन , लेकिन वे अभी भी पुराने पासवर्ड की तुलना में बहुत तेज़ हैं।

क्रिप्टोग्राफी के बारे में अधिक

सार्वजनिक कुंजी क्रिप्टोग्राफी में एक निजी और एक सार्वजनिक कुंजी (कुंजी जोड़ी के रूप में जानी जाती है) शामिल है। कुंजियाँ एक साथ उत्पन्न होती हैं और उनके अलग-अलग उपयोग होते हैं। उदाहरण के लिए, निजी कुंजी को गुप्त रखने का इरादा है, और सार्वजनिक कुंजी का उद्देश्य उस व्यक्ति के लिए है जिसके साथ आप संदेशों का आदान-प्रदान करना चाहते हैं।

जब किसी संदेश को एन्क्रिप्ट और डिक्रिप्ट करने की बात आती है, तो संदेश को एन्क्रिप्ट करने के लिए प्राप्तकर्ता की सार्वजनिक कुंजी का उपयोग किया जाता है ताकि केवल प्राप्तकर्ता की निजी कुंजी ही संदेश को डिक्रिप्ट कर सके। सुरक्षा भाषा में, इसे "गोपनीयता प्रदान करना" कहा जाता है। हालाँकि, यह इस बात का प्रमाण नहीं देता है कि प्रेषक वही है जो वे कहते हैं कि वे हैं, क्योंकि कोई भी किसी को एन्क्रिप्टेड संदेश भेजने के लिए संभावित रूप से सार्वजनिक कुंजी का उपयोग कर सकता है।

ऐसे मामले हैं जहां हमें यह सत्यापित करने की आवश्यकता है कि संदेश वास्तव में इसके प्रेषक से आया था। इन मामलों में, हम यह सुनिश्चित करने के लिए हस्ताक्षर और हस्ताक्षर सत्यापन का उपयोग करते हैं कि प्रेषक वही है जो वे कहते हैं कि वे हैं (जिन्हें प्रामाणिकता). सार्वजनिक कुंजी में (जिसे असममित) क्रिप्टोग्राफी, यह आम तौर पर एक संदेश के हैश पर हस्ताक्षर करके किया जाता है, ताकि केवल सार्वजनिक कुंजी ही इसे सही ढंग से सत्यापित कर सके। हैश और प्रेषक की निजी कुंजी एक एल्गोरिथ्म के माध्यम से इसे चलाने के बाद एक हस्ताक्षर का उत्पादन करती है, और फिर कोई भी प्रेषक की सार्वजनिक कुंजी के साथ प्रेषक के संदेश को सत्यापित कर सकता है।

हम पासकी को कैसे एक्सेस करते हैं?

पासकी को एक्सेस करने के लिए, हमें सबसे पहले उन्हें जनरेट करना होगा और उन्हें कहीं स्टोर करना होगा। इस कार्यक्षमता में से कुछ को एक प्रमाणक के साथ प्रदान किया जा सकता है। एक प्रमाणक कोई भी हार्डवेयर या सॉफ़्टवेयर-समर्थित डिवाइस है जो क्रिप्टोग्राफ़िक कुंजी जनरेशन की क्षमता प्रदान करता है। उन वन-टाइम पासवर्ड के बारे में सोचें जिनसे आप प्राप्त करते हैं Google प्रमाणक, 1Passwordया, LastPass, दूसरों के बीच.

उदाहरण के लिए, एक सॉफ़्टवेयर प्रमाणक क्रेडेंशियल बनाने के लिए विश्वसनीय प्लेटफ़ॉर्म मॉड्यूल (TPM) या डिवाइस के सुरक्षित एन्क्लेव का उपयोग कर सकता है। क्रेडेंशियल्स को तब दूरस्थ रूप से संग्रहीत किया जा सकता है और पासकी जैसे उपकरणों में समन्वयित किया जा सकता है। एक हार्डवेयर ऑथेंटिकेटर कुछ इस तरह होगा YubiKey, जो डिवाइस पर ही चाबियां जनरेट और स्टोर कर सकता है।

प्रमाणक तक पहुँचने के लिए, ब्राउज़र को हार्डवेयर तक पहुँच की आवश्यकता होती है, और उसके लिए हमें एक इंटरफ़ेस की आवश्यकता होती है। हम यहां जिस इंटरफ़ेस का उपयोग करते हैं, वह क्लाइंट टू ऑथेंटिकेटर प्रोटोकॉल (CTAP) है। यह विभिन्न तंत्रों पर विभिन्न प्रमाणीकरणकर्ताओं तक पहुंच की अनुमति देता है। उदाहरण के लिए, हम सीटीएपी का उपयोग करके एनएफसी, यूएसबी और ब्लूटूथ पर प्रमाणीकरणकर्ता तक पहुंच सकते हैं।

पासकी का उपयोग करने के अधिक दिलचस्प तरीकों में से एक है अपने फोन को ब्लूटूथ पर किसी अन्य डिवाइस से कनेक्ट करना जो पासकी का समर्थन नहीं कर सकता है। जब उपकरणों को ब्लूटूथ पर जोड़ा जाता है, तो मैं अपने फोन को मध्यस्थ के रूप में उपयोग करके अपने कंप्यूटर पर ब्राउज़र में लॉग इन कर सकता हूं!

पासकी और वेबऑथन के बीच का अंतर

Passkeys और WebAuthn कुंजियाँ कई मायनों में भिन्न हैं। सबसे पहले, पासकी को मल्टी-डिवाइस क्रेडेंशियल माना जाता है और इसे सभी डिवाइस में सिंक किया जा सकता है। इसके विपरीत, WebAuthn कुंजियाँ एकल-डिवाइस क्रेडेंशियल हैं - यह कहने का एक शानदार तरीका है कि आप सत्यापन के लिए एक डिवाइस से बंधे हैं।

दूसरा, एक सर्वर को प्रमाणित करने के लिए, WebAuthn कुंजियों को लॉगिन के लिए उपयोगकर्ता हैंडल प्रदान करने की आवश्यकता होती है, जिसके बाद a allowCredentials सर्वर से क्लाइंट को सूची वापस कर दी जाती है, जो बताता है कि लॉग इन करने के लिए किन क्रेडेंशियल्स का उपयोग किया जा सकता है। पासकी इस चरण को छोड़ देते हैं और सर्वर के डोमेन नाम का उपयोग यह दिखाने के लिए करते हैं कि कौन सी कुंजियाँ पहले से ही उस साइट से जुड़ी हुई हैं। आप उस सर्वर से जुड़ी पासकी का चयन करने में सक्षम हैं, क्योंकि यह आपके सिस्टम द्वारा पहले से ही ज्ञात है।

अन्यथा, कुंजी क्रिप्टोग्राफ़िक रूप से समान हैं; वे केवल इस बात में भिन्न होते हैं कि वे कैसे संग्रहीत हैं और लॉगिन प्रक्रिया शुरू करने के लिए वे किस जानकारी का उपयोग करते हैं।

प्रक्रिया ... संक्षेप में

WebAuthn या पासकी बनाने की प्रक्रिया बहुत समान है: सर्वर से एक चुनौती प्राप्त करें और फिर navigator.credentials.create वेब एपीआई एक सार्वजनिक कुंजी जोड़ी उत्पन्न करने के लिए। फिर, चुनौती और सार्वजनिक कुंजी को संग्रहीत करने के लिए सर्वर पर वापस भेजें।

सार्वजनिक कुंजी और चुनौती प्राप्त करने पर, सर्वर चुनौती और उस सत्र को मान्य करता है जिससे इसे बनाया गया था। यदि वह जांच करता है, तो सार्वजनिक कुंजी संग्रहीत की जाती है, साथ ही डेटाबेस में उपयोगकर्ता पहचानकर्ता या प्रमाणन डेटा जैसी अन्य प्रासंगिक जानकारी भी संग्रहीत की जाती है।

उपयोगकर्ता के पास एक और कदम है - सर्वर से एक और चुनौती प्राप्त करें और उपयोग करें navigator.credentials.get एपीआई चुनौती पर हस्ताक्षर करने के लिए। हम सर्वर को हस्ताक्षरित चुनौती वापस भेजते हैं, और सर्वर चुनौती की पुष्टि करता है, फिर हस्ताक्षर पास होने पर हमें लॉग इन करता है।

बेशक, प्रत्येक चरण में काफी कुछ अधिक है। लेकिन आम तौर पर हम WebAuthn या पासकी का उपयोग करके किसी वेबसाइट में लॉग इन करते हैं।

मांस और आलू

पासकी का उपयोग दो अलग-अलग चरणों में किया जाता है: साक्षी और अभिकथन चरणों।

प्रमाणन चरण को पंजीकरण चरण के रूप में भी माना जा सकता है। आप एक नई वेबसाइट के लिए एक ईमेल और पासवर्ड के साथ साइन अप करेंगे, हालाँकि, इस मामले में, हम अपनी पासकी का उपयोग करेंगे।

अभिकथन चरण वैसा ही है जैसे आप साइन अप करने के बाद किसी वेबसाइट में लॉग इन करते हैं।

साक्षी

पासकीज़: क्या बकवास है और क्यों? प्लेटोब्लॉकचेन डेटा इंटेलिजेंस। लंबवत खोज. ऐ.
पूरा आकार देखो

RSI navigator.credentials.create एपीआई हमारे प्रमाणन चरण का फोकस है। हम सिस्टम में एक नए उपयोगकर्ता के रूप में पंजीकृत हैं और एक नई सार्वजनिक कुंजी जोड़ी बनाने की आवश्यकता है। हालाँकि, हमें यह निर्दिष्ट करने की आवश्यकता है कि हम किस प्रकार की कुंजी जोड़ी बनाना चाहते हैं। इसका मतलब है कि हमें विकल्प प्रदान करने की आवश्यकता है navigator.credentials.create.

// The `challenge` is random and has to come from the server
const publicKey: PublicKeyCredentialCreationOptions = { challenge: safeEncode(challenge), rp: { id: window.location.host, name: document.title, }, user: { id: new TextEncoder().encode(crypto.randomUUID()), // Why not make it random? name: 'Your username', displayName: 'Display name in browser', }, pubKeyCredParams: [ { type: 'public-key', alg: -7, // ES256 }, { type: 'public-key', alg: -256, // RS256 }, ], authenticatorSelection: { userVerification: 'preferred', // Do you want to use biometrics or a pin? residentKey: 'required', // Create a resident key e.g. passkey }, attestation: 'indirect', // indirect, direct, or none timeout: 60_000,
};
const pubKeyCredential: PublicKeyCredential = await navigator.credentials.create({ publicKey
});
const { id // the key id a.k.a. kid
} = pubKeyCredential;
const pubKey = pubKeyCredential.response.getPublicKey();
const { clientDataJSON, attestationObject } = pubKeyCredential.response;
const { type, challenge, origin } = JSON.parse(new TextDecoder().decode(clientDataJSON));
// Send data off to the server for registration

हम मिलेंगे PublicKeyCredential जिसमें एक है AuthenticatorAttestationResponse जो सृष्टि के बाद वापस आता है। क्रेडेंशियल में जेनरेट की गई कुंजी जोड़ी की आईडी है।

प्रतिक्रिया कुछ उपयोगी जानकारी प्रदान करती है। सबसे पहले, इस प्रतिक्रिया में हमारे पास हमारी सार्वजनिक कुंजी है, और हमें इसे सर्वर पर संग्रहीत करने के लिए भेजने की आवश्यकता है। दूसरा, हम भी वापस प्राप्त करते हैं clientDataJSON संपत्ति जिसे हम डिकोड कर सकते हैं, और वहां से वापस प्राप्त कर सकते हैं type, challenge, तथा origin पासकी का।

सत्यापन के लिए, हम इसे मान्य करना चाहते हैं type, challenge, तथा origin सर्वर पर, साथ ही सार्वजनिक कुंजी को उसके पहचानकर्ता के साथ संग्रहीत करें, जैसे कि बच्चा। हम वैकल्पिक रूप से स्टोर भी कर सकते हैं attestationObject अगर हम चाहें। स्टोर करने के लिए एक और उपयोगी संपत्ति है कोस एल्गोरिथ्म, जो हमारे में ऊपर परिभाषित किया गया है  PublicKeyCredentialCreationOptions साथ में alg: -7 or alg: -256, अभिकथन चरण में किसी भी हस्ताक्षरित चुनौती को आसानी से सत्यापित करने के लिए।

अभिकथन

पासकीज़: क्या बकवास है और क्यों? प्लेटोब्लॉकचेन डेटा इंटेलिजेंस। लंबवत खोज. ऐ.
पूरा आकार देखो

RSI navigator.credentials.get एपीआई अभिकथन चरण का फोकस होगा। वैचारिक रूप से, यह वह जगह होगी जहां साइन अप करने के बाद उपयोगकर्ता वेब एप्लिकेशन में लॉग इन करता है।

// The `challenge` is random and has to come from the server
const publicKey: PublicKeyCredentialRequestOptions = { challenge: new TextEncoder().encode(challenge), rpId: window.location.host, timeout: 60_000,
};
const publicKeyCredential: PublicKeyCredential = await navigator.credentials.get({ publicKey, mediation: 'optional',
});
const { id // the key id, aka kid
} = pubKeyCredential;
const { clientDataJSON, attestationObject, signature, userHandle } = pubKeyCredential.response;
const { type, challenge, origin } = JSON.parse(new TextDecoder().decode(clientDataJSON));
// Send data off to the server for verification

हम फिर से एक प्राप्त करेंगे PublicKeyCredential के साथ एक AuthenticatorAssertionResponse इस समय। क्रेडेंशियल में फिर से मुख्य पहचानकर्ता शामिल होता है।

हमें भी मिलता है type, challenge, तथा origin से  clientDataJSON फिर।  signature अब प्रतिक्रिया में शामिल किया गया है, साथ ही साथ authenticatorData. हमें उनकी और की आवश्यकता होगी clientDataJSON यह सत्यापित करने के लिए कि यह निजी कुंजी के साथ हस्ताक्षरित था।

RSI authenticatorData कुछ गुण शामिल हैं जो ट्रैकिंग के लायक हैं पहले आपके द्वारा उपयोग किए जा रहे मूल का SHA256 हैश है, जो पहले 32 बाइट्स के भीतर स्थित है, जो यह सत्यापित करने के लिए उपयोगी है कि अनुरोध उसी मूल सर्वर से आता है। दूसरा है signCount, जो बाइट 33 से 37 तक है। यह प्रमाणीकरणकर्ता से उत्पन्न होता है और इसकी तुलना इसके पिछले मूल्य से की जानी चाहिए ताकि यह सुनिश्चित किया जा सके कि कुंजी के साथ कुछ भी गलत नहीं हो रहा है। मान हमेशा 0 होना चाहिए जब यह एक मल्टी-डिवाइस पासकी हो और जब यह सिंगल-डिवाइस पासकी हो तो पिछले साइनकाउंट से बेतरतीब ढंग से बड़ा होना चाहिए।

एक बार जब आप अपने लॉगिन पर जोर देते हैं, तो आपको लॉग इन होना चाहिए — बधाई! Passkeys एक बहुत अच्छा प्रोटोकॉल है, लेकिन यह कुछ चेतावनियों के साथ आता है।

कुछ डाउनसाइड्स

पासकी में बहुत कुछ उल्टा है, हालाँकि, इस लेखन के समय इसके साथ कुछ समस्याएँ हैं। एक बात के लिए, पासकी कुछ हद तक शुरुआती समर्थन-वार है, केवल विंडोज़ पर सिंगल-डिवाइस क्रेडेंशियल्स की अनुमति है और लिनक्स सिस्टम के लिए बहुत कम समर्थन है। पासकी.देव प्रदान करता है एक अच्छी टेबल जो इस प्रोटोकॉल के कैनियस की तरह है.

साथ ही, Google और Apple के पासकी प्लेटफॉर्म एक दूसरे से संचार नहीं करते हैं। यदि आप अपने क्रेडेंशियल्स को अपने Android फ़ोन से अपने iPhone पर प्राप्त करना चाहते हैं... ठीक है, तो अभी आप भाग्य से बाहर हैं। यह कहना नहीं है कि कोई इंटरऑपरेबिलिटी नहीं है! आप एक प्रमाणक के रूप में अपने फ़ोन का उपयोग करके अपने कंप्यूटर में लॉग इन कर सकते हैं। लेकिन यह सिर्फ ऑपरेटिंग सिस्टम में निर्मित और विक्रेता स्तर पर लॉक किए बिना सिंक करने के लिए बहुत साफ होगा।

चीजें कहां जा रही हैं?

भविष्य का पासकी प्रोटोकॉल कैसा दिखता है? यह बहुत अच्छा लग रहा है! एक बार जब यह अधिक ऑपरेटिंग सिस्टम से समर्थन प्राप्त कर लेता है, तो इसके उपयोग में तेजी आनी चाहिए, और आप इसे जंगल में अधिक से अधिक उपयोग करते हुए देखना शुरू कर देंगे। कुछ पासवर्ड मैनेजर यहां तक ​​कि सीधे तौर पर उनका समर्थन करने जा रहे हैं।

पासकी किसी भी तरह से केवल वेब पर ही समर्थित नहीं हैं। Android और iOS दोनों प्रथम श्रेणी के नागरिकों के रूप में देशी पासकी का समर्थन करेंगे। हम अभी भी इस सब के शुरुआती दिनों में हैं, लेकिन उम्मीद करते हैं कि इसका अधिक से अधिक उल्लेख किया जाएगा।

आखिरकार, हम पासवर्ड की आवश्यकता को समाप्त करते हैं, और ऐसा करके दुनिया को इसके लिए सुरक्षित बनाते हैं!

उपयुक्त संसाधन चुनें

यदि आप पासकी के बारे में अधिक जानना चाहते हैं तो यहां कुछ और संसाधन दिए गए हैं। इस लेख के लिए मैंने एक रिपॉजिटरी और डेमो भी एक साथ रखा है।

समय टिकट:

से अधिक सीएसएस ट्रिक्स