प्रॉम्प्ट और संदर्भ
यह प्रश्न परीक्षण करता है कि क्या कोई फ़्रंटएंड इंजीनियर WebAuthn एक्सटेंशन को वास्तविक एंड-टू-एंड एन्क्रिप्शन फ़्लो में एकीकृत कर सकता है। PRF क्लाइंट-साइड की मटीरियल प्राप्त करने के लिए क्रेडेंशियल-बाउंड स्यूडोरैंडम आउटपुट प्रदान कर सकता है; यह कोई लॉगिन हस्ताक्षर नहीं है और यह मल्टी-डिवाइस उपयोग, बैकअप, डिलीशन या ब्राउज़र कम्पैटिबिलिटी का समाधान नहीं करता है। एक सशक्त उत्तर में ब्राउज़र API, क्रिप्टोग्राफ़िक सीमाएँ, उपयोगकर्ता अनुभव और रिकवरी जोखिम शामिल होते हैं।
साक्षात्कारकर्ता क्या मूल्यांकन कर रहा है
- क्या आप पासकी प्रमाणीकरण और PRF की-मटीरियल के उपयोग के बीच अंतर करते हैं।
- क्या आप एक्सटेंशन समर्थन, उपयोगकर्ता सत्यापन, साल्ट्स, डेरिवेशन और सर्वर स्टोरेज को अलग करते हैं।
- क्या आप डिवाइस नामांकन, क्रेडेंशियल डिलीशन, सिंक्रोनाइज़ेशन और अपरिवर्तनीय डेटा हानि को संभालते हैं।
- क्या आप फ़ॉलबैक, त्रुटि स्थितियों और उस सीमा को परिभाषित करते हैं जो की मटीरियल को सर्वर से दूर रखती है।
पहले पूछे जाने वाले स्पष्टीकरण प्रश्न
थ्रेट मॉडल को स्पष्ट करें: क्या सर्वर अविश्वसनीय है, क्या क्लाइंट सप्लाई चेन दायरे में है, और क्या क्रॉस-डिवाइस सिंक आवश्यक है? क्या डेटा को संपूर्ण रूप से एन्क्रिप्ट किया गया है या फ़ील्ड के आधार पर, और क्या उपयोगकर्ता क्रेडेंशियल खोने के बाद स्थायी नुकसान स्वीकार कर सकते हैं? क्या लक्षित ब्राउज़र और WebViews नियंत्रित हैं, और क्या उपयोगकर्ता कई पासकी पंजीकृत कर सकते हैं? सर्वर को कौन सा सिफरटेक्स्ट, साल्ट्स, क्रेडेंशियल IDs और वर्जन्स स्टोर करने चाहिए?
30-सेकंड का उत्तर ढांचा
मैं PRF को क्लाइंट-साइड की मटीरियल के स्रोत के रूप में मानूँगा, एन्क्रिप्शन की के रूप में लॉगिन असर्शन का उपयोग नहीं करूँगा। रजिस्ट्रेशन के दौरान, PRF-सक्षम क्रेडेंशियल बनाएं या चुनें और प्रत्येक उद्देश्य के लिए एक अप्रत्याशित साल्ट उत्पन्न करें। अनलॉक के दौरान, PRF इनपुट के साथ एक असर्शन निष्पादित करें, ब्राउज़र में एक मानक KDF के साथ रैपिंग की प्राप्त करें, और डेटा की को अनरैप करें। सर्वर पब्लिक कीज़, साल्ट्स, सिफरटेक्स्ट और वर्जन्स को स्टोर करता है, कभी भी PRF आउटपुट को नहीं। मैं वास्तविक एक्सटेंशन परिणामों और उपयोगकर्ता सत्यापन की जांच करूँगा, मल्टी-क्रेडेंशियल रिकवरी या स्पष्ट डेटा हानि की चेतावनी तैयार करूँगा, और PRF अनुपलब्ध होने पर एंड-टू-एंड एन्क्रिप्शन का दावा करने से मना करूँगा। मैं विफलताओं, रिकवरी और कम्पैटिबिलिटी को मापने के बाद ही समर्थन का विस्तार करूँगा।
चरण-दर-चरण विस्तृत विश्लेषण
1. प्रमाणीकरण को एन्क्रिप्शन कीज़ से अलग करें
WebAuthn लॉगिन क्रेडेंशियल के स्वामित्व को साबित करने के लिए एक चैलेंज पर हस्ताक्षर लौटाता है। PRF एक्सटेंशन इनपुट से क्रेडेंशियल-संबंधित स्यूडोरैंडम आउटपुट उत्पन्न करता है। किसी हस्ताक्षर, क्रेडेंशियल ID, या क्लाइंट-एक्सटेंशन JSON का उपयोग सीधे AES की के रूप में नहीं किया जाना चाहिए। डिज़ाइन को एक स्वतंत्र डेटा की और एक स्पष्ट डेरिवेशन तथा रैपिंग संबंध की आवश्यकता होती है।
2. रजिस्ट्रेशन और साल्ट्स डिज़ाइन करें
रजिस्ट्रेशन के दौरान PRF एक्सटेंशन का अनुरोध करें और उपयोगकर्ता सत्यापन की मांग करें। प्रत्येक एन्क्रिप्शन डोमेन या की वर्जन के लिए एक रैंडम साल्ट उत्पन्न करें, फिर साल्ट, क्रेडेंशियल ID और एल्गोरिदम वर्जन को सार्वजनिक मेटाडेटा के रूप में स्टोर करें। साल्ट कोई रहस्य नहीं है, लेकिन उद्देश्यों को अलग किया जाना चाहिए; उद्देश्य बदलने या की को रोटेट करने के लिए एक नए साल्ट की आवश्यकता होती है। अनुरोध से समर्थन का अनुमान लगाने के बजाय लौटाए गए क्लाइंट एक्सटेंशन आउटपुट की जांच करें।
3. अनलॉक और डेरिवेशन डिज़ाइन करें
सर्वर से साल्ट्स और सिफरटेक्स्ट मेटाडेटा प्राप्त करें, फिर PRF इनपुट के साथ एक असर्शन निष्पादित करें। ब्राउज़र में लौटाए गए एक्सटेंशन संरचना और लंबाई को मान्य करें, एक मानक KDF के साथ एक रैपिंग की प्राप्त करें, एक बेतरतीब ढंग से उत्पन्न डेटा की को अनरैप करें, और सामग्री को डिक्रिप्ट करें। PRF आउटपुट और मध्यवर्ती कीज़ को मेमोरी में केवल आवश्यकतानुसार ही रखें; उन्हें कभी भी लॉग्स या टेलीमेट्री में न डालें।
4. क्षमता का पता लगाना और कम्पैटिबिलिटी संभालना
वास्तविक परिणाम का निरीक्षण करने के लिए दस्तावेजी क्षमता जांच और getClientExtensionResults() का उपयोग करें। असमर्थित एक्सटेंशन, उपयोगकर्ता रद्दीकरण, अप्रारंभीकृत क्रेडेंशियल और नेटवर्क विफलता के बीच अंतर करें। W3C कार्यान्वयन स्थिति को अभी भी लक्षित ब्राउज़रों, ऑपरेटिंग सिस्टम और WebViews में सत्यापन की आवश्यकता है; एक ब्राउज़र की सफलता पूरे प्लेटफ़ॉर्म की गारंटी नहीं है। रोलआउट नीति में कम्पैटिबिलिटी मैट्रिक्स और न्यूनतम वर्जन्स रिकॉर्ड करें।
5. मल्टीपल डिवाइसेस और रिकवरी डिज़ाइन करें
प्रति डिवाइस एक अलग क्रेडेंशियल नामांकित करें और प्रत्येक के लिए समान डेटा की की अलग से रैप की गई प्रतिलिपि रखें। एक नए डिवाइस को डेटा की को फिर से रैप करने के लिए पहले से अनलॉक किए गए डिवाइस, एक रिकवरी की, या एक नियंत्रित आमंत्रण की आवश्यकता होती है; अकेले सर्वर लॉगिन को इसे डिक्रिप्ट नहीं करना चाहिए। यदि प्रत्येक क्रेडेंशियल हटा दिया जाता है और कोई रिकवरी मटीरियल मौजूद नहीं है, तो स्पष्ट रूप से बताएं कि डेटा पुनर्प्राप्त करने योग्य नहीं है और सुविधा को सक्षम करने से पहले पुष्टि प्राप्त करें।
6. फ़ॉलबैक और माइग्रेशन की योजना बनाएं
जब PRF अनुपलब्ध हो, तो थ्रेट मॉडल के आधार पर, सर्वर-पठनीय एन्क्रिप्शन मोड बनाए रखें, उपयोगकर्ता को समर्थित ब्राउज़र पर निर्देशित करें, या एंड-टू-एंड मोड को ब्लॉक करें। फ़ॉलबैक को स्पष्ट रूप से लेबल करें; एकल UI में सुरक्षा स्तरों को मिश्रित न करें। एल्गोरिदम, साल्ट्स और सिफरटेक्स्ट प्रारूपों को वर्जन दें ताकि भविष्य में माइग्रेशन और पुराने क्रेडेंशियल निरस्तीकरण संभव रहे।
उच्च गुणवत्ता वाला मॉडल उत्तर
मैं WebAuthn PRF का उपयोग क्लाइंट-साइड की मटीरियल के रूप में करूँगा, कभी भी लॉगिन हस्ताक्षर या क्रेडेंशियल ID को एन्क्रिप्शन की के रूप में नहीं मानूँगा। रजिस्ट्रेशन के समय, PRF का अनुरोध करें, उपयोगकर्ता सत्यापन की आवश्यकता रखें, प्रति एन्क्रिप्शन डोमेन एक रैंडम साल्ट उत्पन्न करें, और क्रेडेंशियल ID, साल्ट और एल्गोरिदम वर्जन स्टोर करें। अनलॉक के समय, मेटाडेटा प्राप्त करें, PRF इनपुट के साथ असर्शन निष्पादित करें, ब्राउज़र में मानक KDF के साथ रैपिंग की प्राप्त करें, बेतरतीब ढंग से उत्पन्न डेटा की को अनरैप करें और डिक्रिप्ट करें। सर्वर पब्लिक कीज़, सिफरटेक्स्ट और सार्वजनिक मेटाडेटा स्टोर करता है; PRF आउटपुट, मध्यवर्ती कीज़ और प्लेनटेक्स्ट क्लाइंट-साइड रहते हैं। मैं असमर्थित, अप्रारंभीकृत, रद्द और नेटवर्क-त्रुटि स्थितियों के बीच अंतर करने के लिए getClientExtensionResults() का निरीक्षण करूँगा। प्रत्येक डिवाइस को अपना क्रेडेंशियल और रैप्ड डेटा-की प्रति मिलती है; डिवाइस जोड़ने के लिए अनलॉक डिवाइस या रिकवरी मटीरियल की आवश्यकता होती है, और सभी क्रेडेंशियल्स खोना स्पष्ट रूप से अपूरणीय है। यदि PRF अनुपलब्ध है, तो मैं एक स्पष्ट फ़ॉलबैक दिखाऊंगा या सक्रियण को ब्लॉक कर दूंगा, फिर ब्राउज़र मैट्रिक्स, विफलता दर और रिकवरी सफलता के आधार पर विस्तार करूँगा।
सामान्य गलतियाँ
- WebAuthn हस्ताक्षर, क्रेडेंशियल ID, या क्लाइंट-एक्सटेंशन JSON का सीधे सिमेट्रिक की के रूप में उपयोग करना।
- वास्तविक आउटपुट और आरंभीकरण की जांच करने के बजाय केवल यह जांचना कि अनुरोध में PRF पैरामीटर शामिल है।
- साल्ट्स को रहस्य मानना या कई उद्देश्यों में एक साल्ट का पुन: उपयोग करना।
- PRF आउटपुट को सर्वर पर भेजना या लॉग्स, ट्रेसिंग या एनालिटिक्स में की मटीरियल रिकॉर्ड करना।
- नामांकन, डिलीशन और रिकवरी के बिना केवल सिंगल-डिवाइस हैप्पी पाथ डिज़ाइन करना।
- एंड-टू-एंड एन्क्रिप्शन लेबल करते हुए चुपचाप कमज़ोर मोड पर स्विच करना।
अनुवर्ती प्रश्न और उत्तर
क्या PRF आउटपुट का उपयोग सीधे AES-GCM की के रूप में किया जा सकता है?
पहले एक मानक KDF और डोमेन पृथक्करण का उपयोग करें, फिर एक निश्चित लंबाई की रैपिंग की प्राप्त करें। कई एन्क्रिप्शन उद्देश्यों के लिए प्रोटोकॉल आउटपुट को उजागर न करें। एक रैंडम डेटा की उत्पन्न करें और इसे रैप करें; प्रत्येक सिफरटेक्स्ट की को क्रेडेंशियल का सीधा फ़ंक्शन न बनाएं।
क्या सर्वर लॉगिन के बाद किसी अन्य डिवाइस पर उपयोगकर्ता को अनलॉक कर सकता है?
सर्वर साल्ट्स, सिफरटेक्स्ट और क्रेडेंशियल मेटाडेटा प्रदान कर सकता है, लेकिन लॉगिन से PRF आउटपुट का पुनर्निर्माण नहीं कर सकता है। एक अनलॉक किए गए डिवाइस, एक रिकवरी की, या एक स्पष्ट रूप से डिज़ाइन किए गए की-शेयरिंग फ़्लो को नए डिवाइस के लिए डेटा की को रैप करना होगा।
आप कैसे जानते हैं कि कोई ब्राउज़र वास्तव में PRF का समर्थन करता है?
एक्सटेंशन घोषित करें, असर्शन से क्लाइंट-एक्सटेंशन आउटपुट पढ़ें, और अपेक्षित फ़ील्ड, लंबाई और त्रुटि स्थितियों की जांच करें। लक्षित ब्राउज़रों, ऑपरेटिंग सिस्टम और WebViews के लिए एक अनुभवजन्य मैट्रिक्स बनाए रखें। एक क्षमता API यह बताता है कि एक्सटेंशन का अनुरोध किया जा सकता है; यह वास्तविक समारोह का स्थान नहीं लेता है।
यदि सर्वर द्वारा डिलीवर की गई स्क्रिप्ट को इंजेक्ट किया जाता है, तो क्या एंड-टू-एंड एन्क्रिप्शन अभी भी सुरक्षित है?
PRF फ़्रंटएंड स्क्रिप्ट के सक्रिय छेड़छाड़ का समाधान नहीं करता है। आपको सामग्री सुरक्षा नीति (CSP), निर्भरता और रिलीज़ अखंडता, संवेदनशील-संचालन अलगाव और ऑडिटिंग की भी आवश्यकता है। स्पष्ट रूप से बताएं कि "सर्वर ऐतिहासिक सिफरटेक्स्ट नहीं पढ़ सकता" और "क्लाइंट रनटाइम विश्वसनीय है" अलग-अलग धारणाएं हैं।