WebAuthn में अटेस्टेशन क्या है?

अटेस्टेशन तीन चीजों का उल्लेख कर सकता है (अक्सर बोलचाल की भाषा में इन्हें एक दूसरे के स्थान पर उपयोग किया जाता है, हालांकि सटीक रूप से देखने पर इनका मतलब अलग होता है):

1. सबसे पहले और अधिक सामान्य रूप से, क्रिप्टोग्राफ़िक क्षेत्र में अटेस्टेशन एक शब्द है जहाँ एक पक्ष दूसरे पक्ष को क्रिप्टोग्राफ़िक रूप से एक बयान "प्रमाणित" करता है।

2. दूसरे, WebAuthn में पंजीकरण चरण के दौरान ऑथेंटिकेटर द्वारा एक अटेस्टेशन ऑब्जेक्ट बनाया जाता है और रिलाइंग पार्टी को लौटाया जाता है। यह एक कंटेनर ऑब्जेक्ट है जिसमें निम्नलिखित जानकारी होती है:

   • अटेस्टेशन स्टेटमेंट फॉर्मेट (fmt)
   • अटेस्टेशन स्टेटमेंट (attStmt - नीचे देखें)
   • ऑथेंटिकेटर डेटा (authData)

Become part of our Passkeys Community for updates & support.

Join

3. तीसरे, WebAuthn में, एक अटेस्टेशन स्टेटमेंट अटेस्टेशन ऑब्जेक्ट का एक वैकल्पिक तत्व है। यह स्टेटमेंट, जब शामिल किया जाता है, तो अटेस्टेशन प्रक्रिया में शामिल ऑथेंटिकेटर (डिवाइस) की कुछ विशेषताओं को सत्यापित करता है। हालांकि, कुछ डिवाइस निर्माता (जैसे Apple) अटेस्टेशन स्टेटमेंट की पेशकश नहीं करते हैं क्योंकि विनिर्देश का यह पहलू पासकी सिंक्रनाइज़ेशन के लिए नहीं था और जब क्रेडेंशियल्स को विभिन्न डिवाइसों में सिंक किया जा सकता है तो सुरक्षा विशेषताओं को प्रभावी ढंग से सत्यापित करने में विफल रहता है (उदाहरण के लिए, एक पासकी एक iPhone पर बनाई जाती है लेकिन उसी iCloud Keychain के माध्यम से सिंक होने के कारण MacBook पर भी उपयोग की जाती है)। जब अटेस्टेशन स्टेटमेंट प्रदान किया जाता है तो दी जा सकने वाली विशेषताएँ:
   • यह सबूत देना कि प्रमाणीकरण के दौरान एक वास्तविक और विश्वसनीय डिवाइस का उपयोग किया गया था।
   • डिवाइस की उत्पत्ति, मॉडल और अन्य प्रासंगिक जानकारी के बारे में विवरण प्रदान करना।
   • सुरक्षा उपायों को बढ़ाना, विशेष रूप से उन परिदृश्यों में जहां डिवाइस की विश्वसनीयता महत्वपूर्ण है (जैसे स्वास्थ्य सेवा जैसे कुछ विनियमित उद्योग)।

पंजीकरण की निम्नलिखित प्रक्रिया प्रवाह WebAuthn में अटेस्टेशन (ऑब्जेक्ट) की भूमिका को दर्शाता है:

{
    "root": {
        "id": "QFPlQVypLmmx71e0tmS3IfCFky0",
        "rawId": "QFPlQVypLmmx71e0tmS3IfCFky0",
        "response": {
            "attestationObject": {
                "fmt": "none",
                "attStmt": {},
                "authData": {
                    "rpIdHash": "t8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADc",
                    "flags": {
                        "userPresent": true,
                        "userVerified": true,
                        "backupEligible": true,
                        "backupStatus": true,
                        "attestedData": true,
                        "extensionData": false
                    },
                    "counter": 0,
                    "aaguid": "00000000-0000-0000-0000-000000000000",
                    "credentialID": "QFPlQVypLmmx71eOtmS3IfCFky0",
                    "credentialPublicKey": "pQECAyYgASFYIEa-lpSiQ4P...",
                    "parsedCredentialPublicKey": {
                        "keyType": "EC2 (2)",
                        "algorithm": "ES256 (-7)",
                        "curve": 1,
                        "x": "Rr6WlKJDg8MlbIq9mmHQzk2p2c_s7QoNKr7yMa7I8pM",
                        "y": "tAELYp7h3sYNjZZIZgHPYiaSzF×QVT18cgZ_7wm13Vw"
                    }
                }
            },
            "clientDataJSON": {
                "type": "webauthn.create",
                "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp",
                "origin": "https://passkeys.eu",
                "crossOrigin": false
            },
            "transports": ["hybrid", "internal"],
            "publicKeyAlgorithm": -7
        },
        "authenticatorAttachment": "cross-platform"
    }
}

ऊपर दिए गए स्क्रीनशॉट में, कोई AAGUID और कोई अटेस्टेशन स्टेटमेंट प्रदान नहीं किया गया है।

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

सबसे महत्वपूर्ण विशेषताओं के तकनीकी विश्लेषण के लिए पढ़ना जारी रखें।

WebAuthn में, अटेस्टेशन यह सुनिश्चित करता है कि उपयोगकर्ता प्रमाणीकरण सुरक्षित और पारदर्शी है। अटेस्टेशन स्टेटमेंट के साथ, आप यह सुनिश्चित कर सकते हैं कि एक क्रेडेंशियल एक विशिष्ट ऑथेंटिकेटर / डिवाइस पर बनाया गया था।

ये अटेस्टेशन प्रकार अटेस्टेशन स्टेटमेंट को संदर्भित करते हैं (अटेस्टेशन ऑब्जेक्ट को नहीं)। इन्हें रिलाइंग पार्टी द्वारा एक वरीयता माना जाता है (इसलिए ऑथेंटिकेटर अलग तरह से व्यवहार कर सकता है क्योंकि यह केवल एक वरीयता है)।

• कोई अटेस्टेशन नहीं (none): उन मामलों के लिए जहां गोपनीयता अत्यंत महत्वपूर्ण है या सिंक किए गए डिवाइस उपयोग में हैं, यह प्रकार डिवाइस के बारे में कोई जानकारी प्रदान नहीं करता है, जिससे उपयोगकर्ता की गोपनीयता बनी रहती है। इस मान का उपयोग करने का एक और कारण सर्टिफिकेट अथॉरिटी (CA) के लिए राउंडट्रिप बचाना हो सकता है। none डिफ़ॉल्ट मान भी है।
• अप्रत्यक्ष अटेस्टेशन (indirect): रिलाइंग पार्टी अटेस्टेशन प्राप्त करना पसंद करती है लेकिन क्लाइंट को यह तय करने की अनुमति देती है कि अटेस्टेशन स्टेटमेंट कैसे प्राप्त करें। क्लाइंट उपयोगकर्ता की गोपनीयता की रक्षा के लिए ऑथेंटिकेटर-जनित अटेस्टेशन स्टेटमेंट को अनाम अटेस्टेशन स्टेटमेंट से बदल सकता है।
• प्रत्यक्ष अटेस्टेशन (direct): यह सबसे पारदर्शी रूप है। यहां, रिलाइंग पार्टी ऑथेंटिकेटर को बताती है कि वह एक अटेस्टेशन स्टेटमेंट चाहती है, ताकि रिलाइंग पार्टी को डिवाइस के बारे में विस्तृत जानकारी मिल सके, जिसमें उसका ब्रांड, मॉडल और अन्य विवरण शामिल हैं। हालांकि यह उच्चतम पारदर्शिता प्रदान करता है, यह कुछ परिदृश्यों में गोपनीयता संबंधी चिंताएं बढ़ा सकता है या सिंक किए गए क्रेडेंशियल्स के लिए वास्तव में प्रयोग करने योग्य नहीं हो सकता है।
• एंटरप्राइज़ अटेस्टेशन (enterprise): रिलाइंग पार्टी एक अटेस्टेशन स्टेटमेंट प्राप्त करना चाहती है जिसमें अद्वितीय पहचान जानकारी शामिल हो सकती है। इस प्रकार का अटेस्टेशन आमतौर पर उन व्यवसायों या संगठनों में उपयोग किया जाता है जो विशिष्ट डिवाइस / ऑथेंटिकेटर्स का ट्रैक रखना चाहते हैं। वेब ब्राउज़र (उपयोगकर्ता एजेंट) को यह विस्तृत अटेस्टेशन तब तक प्रदान नहीं करना चाहिए जब तक कि उनकी सेटिंग्स अनुरोध करने वाली पार्टी के लिए विशेष रूप से इसकी अनुमति न दें। यदि सेटिंग्स इसकी अनुमति देती हैं, तो ब्राउज़र को डिवाइस को यह बताना चाहिए कि इसकी आवश्यकता कब है (प्रक्रिया की शुरुआत में) कि इस विशिष्ट प्रकार के अटेस्टेशन का अनुरोध किया जा रहा है। ब्राउज़र को फिर डिवाइस की अद्वितीय आईडी और अटेस्टेशन प्रूफ को ठीक वैसे ही पास करना चाहिए जैसे वे उन्हें रिलाइंग पार्टी को प्राप्त करते हैं।

Subscribe to our Passkeys Substack for the latest news.

Subscribe

अटेस्टेशन ऑब्जेक्ट में कई विशेषताएँ होती हैं, यहाँ कुछ चुनिंदा विशेषताओं का संक्षिप्त विवरण दिया गया है:

"attestationObject": {
        "fmt": "none",
        "attStmt": {},
        "authData": {
          "rpIdHash": "t8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADc",
          "flags": {
            "userPresent": true,
            "userVerified": true,
            "backupEligible": true,
            "backupStatus": true,
            "attestedData": true,
            "extensionData": false
          },
          "counter": 0,
          "aaguid": "00000000-0000-0000-0000-000000000000",
          "credentialID": "QFPlQVypLmmx71eOtmS3IfCFky0",
          "credentialPublicKey": "pQECAyYgASFYIEa-lpSiQ4P...",
          "parsedCredentialPublicKey": {
            "keyType": "EC2 (2)",
            "algorithm": "ES256 (-7)",
            "curve": 1,
            "x": "Rr6WlKJDg8MlbIq9mmHQzk2p2c_s7QoNKr7yMa7I8pM",
            "y": "tAELYp7h3sYNjZZIZgHPYiaSzF×QVT18cgZ_7wm13Vw"
          }
        }

attestationObject एक CBOR एन्कोडेड ऑब्जेक्ट है, जिसमें नए बनाए गए क्रेडेंशियल्स, पब्लिक की और अन्य प्रासंगिक डेटा के बारे में जानकारी होती है:

• fmt अटेस्टेशन फॉर्मेट का प्रतिनिधित्व करता है, क्योंकि ऑथेंटिकेटर्स विभिन्न तरीकों से अटेस्टेशन डेटा प्रदान कर सकते हैं। यह सर्वर को बताता है कि सर्वर को अटेस्टेशन डेटा को कैसे मान्य करना चाहिए। अनुमत मान "packed", "tpm", "android-key", "android-safetynet", "fido-u2f", "apple" या "none" हैं। विवरण यहां देखें।
• attStmt अटेस्टेशन स्टेटमेंट है। पासकी के लिए, जैसे iOS या Android डिवाइस पर, इसे खाली छोड़ दिया जाता है क्योंकि iOS या Android पर पासकी सिंक की जा सकती हैं, और अन्य डिवाइस जैसे कि Windows या हार्डवेयर सुरक्षा कीज़ के लिए भरा जाता है।
• authData मानों का एक बफर है जिसमें निम्नलिखित डेटा होता है:
  
  अटेस्टेड क्रेडेंशियल डेटा यहाँ एक महत्वपूर्ण भूमिका निभाता है। इसमें शामिल हैं:
  • AAGUID,
  • क्रेडेंशियल आईडी की लंबाई,
  • क्रेडेंशियल आईडी और
  • क्रेडेंशियल पब्लिक की।

ऊपर दिए गए अटेस्टेशन ऑब्जेक्ट के विपरीत जहां पठनीयता के कारणों से attStmt को खाली छोड़ दिया गया था, एक भरा हुआ अटेस्टेशन स्टेटमेंट ऐसा दिखेगा।

{
    "alg": -65535,
    "sig": "MBHX7qov53SWqqPYCrxE5fcoAeDI83a0DzVJ2-N1KI6IAaCGGvINAIFzTEn44F6giANKte-8yEMDZbvbgDG1weaRj7SqsVaTty-TEQ",
    "ver": "2.0",
    "x5c": [
        "MIIFwDCCA6oIaK6tZ7M",
        "MIIG6zCCBNpG18-MCJrHyrpMT-ul7RgxE4dFxqcG59ftTXqJ1f-X_Lpo7K-d7OgKoQrUgzxgATz8YXtFAk3rE1cHXvW9W52V637eAihKn9-UKC0ijzVXrBGX4Iq1o1M0ZfR-tFoOn498xasMCTnharKiM562GBLVJtlvV3DMSLEBl5SfuGM-qYjQgTQknXccks9guCmNaN_b2fo1DisbufXfjM3DVaMqx7IJpSc3wAnxooMrAYGpPM"
    ],
    "pubArea": "AAEACwAw_c3Ousz865mUPx8O3w",
    "certInfo": "_1RDR4AXAniCekfsiDI"
}

• alg: alg प्रॉपर्टी क्रिप्टोग्राफ़िक एल्गोरिथम पहचानकर्ता को इंगित करती है जिसका उपयोग ऑथेंटिकेटर द्वारा अटेस्टेशन स्टेटमेंट पर हस्ताक्षर करने के लिए किया जाता है।
• sig: sig प्रॉपर्टी में ऑथेंटिकेटर द्वारा उत्पन्न डिजिटल हस्ताक्षर होता है। इस हस्ताक्षर का उपयोग अटेस्टेशन स्टेटमेंट की प्रामाणिकता को सत्यापित करने के लिए किया जाता है।
• ver: ver प्रॉपर्टी अटेस्टेशन स्टेटमेंट फॉर्मेट के संस्करण को निर्दिष्ट करती है।
• x5c: x5c ऐरे में एक या अधिक X.509 प्रमाणपत्र होते हैं जो एक प्रमाणन पथ बनाते हैं, जो अटेस्टेशन को मान्य करने में सहायता करता है।
• pubArea: pubArea प्रॉपर्टी में पब्लिक की और ऑथेंटिकेटर की विशेषताओं के बारे में विस्तृत जानकारी होती है।
• certInfo: certInfo प्रॉपर्टी में आमतौर पर एक विश्वसनीय पक्ष द्वारा ऑथेंटिकेटर के प्रमाणीकरण के बारे में जानकारी शामिल होती है।

"clientDataJSON": {
        "type": "webauthn.create",
        "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp",
        "origin": "https://www.passkeys-debugger.io",
        "crossOrigin": false
      }

clientDataJSON के बारे में अधिक जानकारी संबंधित शब्दावली लेख में पढ़ें।

"transports": [
        "hybrid",
        "internal"
      ]

transports-प्रॉपर्टी उन तंत्रों को इंगित करती है जिनके माध्यम से एक ऑथेंटिकेटर क्लाइंट के साथ संवाद कर सकता है। कुछ सामान्य, नमूना मान संयोजन हैं:

• "transports": ["internal","hybrid"]: पासकी का उपयोग प्लेटफ़ॉर्म ऑथेंटिकेटर (जैसे Face ID, Touch ID, Windows Hello) से या क्रॉस-डिवाइस प्रमाणीकरण ( QR कोड और ब्लूटूथ का उपयोग करके) के माध्यम से किया जा सकता है।
• "transports": ["internal"]: पासकी का उपयोग प्लेटफ़ॉर्म ऑथेंटिकेटर (जैसे Face ID, Touch ID, Windows Hello) से किया जा सकता है।
• कोई transports प्रॉपर्टी सेट नहीं है: डिफ़ॉल्ट व्यवहार जो कोई संकेत नहीं देता है।

WebAuthn में अटेस्टेशन (अटेस्टेशन स्टेटमेंट) महत्वपूर्ण है क्योंकि यह एक ऑथेंटिकेटर की वास्तविकता का प्रमाण प्रदान करता है। यह सुनिश्चित करता है कि प्रमाणीकरण प्रक्रिया एक विश्वसनीय डिवाइस द्वारा की जाती है, जिससे संभावित सुरक्षा खतरों से बचाव होता है।

Ben Gould

Head of Engineering

I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.

3,000+ डेवलपर्स Corbado पर भरोसा करते हैं और पासकी के साथ इंटरनेट को सुरक्षित बनाते हैं। कोई प्रश्न हैं? हमने पासकी पर 150+ ब्लॉग पोस्ट लिखे हैं।

पासकी समुदाय में शामिल हों

हाँ, क्योंकि पासकी को डिवाइसों के बीच सिंक किया जा सकता है (जैसे iPhone से MacBook तक Keychain के माध्यम से), रिलाइंग पार्टी अब वास्तव में यह निर्धारित नहीं कर सकती हैं कि कौन सा प्रमाणित डिवाइस वास्तव में किसी ऐप या वेबसाइट में लॉग इन कर रहा है। इसलिए, Apple और Google ने फैसला किया है कि सिंक की गई पासकी के लिए, वे अब अटेस्टेशन स्टेटमेंट प्रदान नहीं करेंगे। हालांकि, रिलाइंग पार्टी के लिए UX को बेहतर बनाने और उन्हें Apple और Google इकोसिस्टम (iCloud Keychain और Google Password Manager) से पासकी को पहचानने और प्रदर्शित करने का अवसर देने के लिए, AAGUID अभी भी प्रदान किया जाएगा (जब तक कि WebAuthn सर्वर सेटिंग्स में PublicKeyCredentialCreationOptions के लिए अटेस्टेशन direct या indirect पर सेट है)। विवरण के लिए यह GitHub मुद्दा देखें।

यदि आप अपनी वेबसाइट और ऐप में पासकी प्रमाणीकरण को एकीकृत करना चाहते हैं, और अपने उपयोगकर्ताओं को एक बेहतरीन पासकी UX प्रदान करना चाहते हैं, तो आपको निम्नलिखित पर विचार करना चाहिए। हम मानते हैं कि आप अपना समाधान मुख्य रूप से एक ऐसे परिदृश्य के लिए बनाते हैं जहां आपके अधिकांश उपयोगकर्ता Windows, iOS, macOS या Android ऑपरेटिंग सिस्टम का उपयोग करते हैं। इसके अलावा, हम मानते हैं कि अधिकांश पासकी (Windows को छोड़कर) सिंक की गई पासकी हैं। चूंकि न तो iOS, macOS और न ही Android अब एक अटेस्टेशन स्टेटमेंट भेजते हैं, इसलिए एक ऑथेंटिकेटर का वास्तविक सत्यापन अब उपयोग नहीं किया जाता है (Windows के लिए यह अभी भी काम करता है, शायद इसलिए कि Windows अभी तक Windows Hello के माध्यम से सिंक की गई पासकी की पेशकश नहीं करता है)। हालांकि, AAGUID प्राप्त करने के लिए, जैसे कि खाता सेटिंग्स में बेहतर पासकी प्रबंधन के लिए, हम अटेस्टेशन वरीयता को indirect पर सेट करने की सलाह देते हैं, क्योंकि यह अभी भी AAGUID प्राप्त करने की अनुमति देगा जबकि अटेस्टेशन स्टेटमेंट या तो भेजा जाता है (Windows) या नहीं भेजा जाता है (iOS, macOS, Android)।

FIDO मेटाडेटा सेवा विभिन्न ऑथेंटिकेटर्स के लिए मेटाडेटा का एक भंडार प्रदान करती है। अटेस्टेशन के दौरान, इस सेवा से ऑथेंटिकेटर के बारे में विवरण प्राप्त करने और मान्य करने के लिए पूछताछ की जा सकती है, जिससे प्रक्रिया की सटीकता और विश्वसनीयता बढ़ती है। FIDO मेटाडेटा सेवा अटेस्टेशन स्टेटमेंट (अटेस्टेशन ऑब्जेक्ट नहीं) की जाँच करती है।

हाँ, प्रत्यक्ष अटेस्टेशन (अटेस्टेशन स्टेटमेंट में), डिवाइस के बारे में विस्तृत जानकारी प्रदान करके उच्चतम पारदर्शिता प्रदान करते हुए, कुछ परिदृश्यों में गोपनीयता संबंधी चिंताएँ बढ़ा सकता है। अटेस्टेशन के प्रकार का चयन करते समय पारदर्शिता बनाम गोपनीयता की आवश्यकता का आकलन करना महत्वपूर्ण है।

WebAuthn विभिन्न प्रकार की अटेस्टेशन वरीयताएँ प्रदान करता है - कोई नहीं, अप्रत्यक्ष, प्रत्यक्ष और एंटरप्राइज़। उन परिदृश्यों के लिए जहां उपयोगकर्ता की गोपनीयता महत्वपूर्ण है, attestation=none का उपयोग किया जा सकता है, जो डिवाइस के बारे में कोई विवरण प्रदान नहीं करता है, जिससे उपयोगकर्ता की गोपनीयता सुरक्षित रहती है।