प्रॉम्प्ट और संदर्भ
ऐप ब्राउज़र में स्थानीय डेटा को एन्क्रिप्ट करता है और इसे सेशन्स के दौरान एक कुंजी (key) की आवश्यकता होती है। डिज़ाइन को की (key) के जोखिम को कम करना चाहिए, लेकिन इसकी सीमाओं को भी स्पष्ट करना चाहिए: मूल (origin) में चलने वाला कोड अभी भी अनुमत ऑपरेशन्स को लागू कर सकता है और उपयोगकर्ता रिकवरी की क्षमता खो सकते हैं।
साक्षात्कारकर्ता क्या जांचता है
- सिक्योर कॉन्टेक्स्ट, CryptoKey एक्सट्रेक्टेबिलिटी और की (key) के उपयोगों की समझ।
- एन्क्रिप्टेड डेटा स्टोरेज को की-रिकवरी और थ्रेट मॉडलिंग से अलग करना।
- यह समझाना कि ब्राउज़र क्रिप्टोग्राफी XSS को हानिरहित क्यों नहीं बनाती है।
उत्तर देने से पहले स्पष्ट करने वाले प्रश्न
- क्या खतरा चोरी हुआ स्टोरेज रिकॉर्ड है, कोई पैसिव अटैकर है, या सक्रिय सेम-ओरिजिन स्क्रिप्ट है?
- क्या डेटा को लॉगआउट, डिवाइस खोने, पासवर्ड रीसेट और ब्राउज़र प्रोफ़ाइल डिलीट होने के बाद भी बचा रहना चाहिए?
- क्या उपयोगकर्ता द्वारा दिया गया पासफ़्रेज़ या WebAuthn क्रेडेंशियल एक रैपिंग कुंजी (wrapping key) को अनलॉक कर सकता है?
- किन एल्गोरिदम, की-यूसेज, ब्राउज़र सपोर्ट और माइग्रेशन पाथ की आवश्यकता है?
30-सेकंड का उत्तर ढांचा
मैं HTTPS को अनिवार्य करूँगा, extractable को false पर सेट करके और केवल आवश्यक उपयोगों के साथ एक CryptoKey जनरेट या इम्पोर्ट करूँगा, और रॉ की बाइट्स को एक्सपोर्ट करने के बजाय IndexedDB में की-हैंडल स्टोर करूँगा। सिफरटेक्स्ट, नॉनस (nonce), एल्गोरिदम पैरामीटर्स और वर्ज़न को की (key) से अलग रखा जाता है। मैं इसे CSP, सख्त डिपेंडेंसी नियंत्रण और एक रिकवरी प्लान के साथ जोड़ूंगा, साथ ही यह स्पष्ट करूंगा कि ऐप खुला होने पर सक्रिय सेम-ओरिजिन स्क्रिप्ट अभी भी एन्क्रिप्शन API को कॉल कर सकती है या प्लेनटेक्स्ट पढ़ सकती है।
चरण-दर-चरण गहन विश्लेषण
1. थ्रेट मॉडल को परिभाषित करें
Non-extractability आकस्मिक एक्सपोर्ट और स्टोरेज चोरी के कई रास्तों को सीमित करती है। यह उस अटैकर को नहीं रोकती जो ओरिजिन में स्क्रिप्ट निष्पादित करके ऐप से डेटा डिक्रिप्ट करने के लिए कहता है या मेमोरी में प्लेनटेक्स्ट पढ़ता है। सुरक्षा का वादा करने से पहले उस सीमा को स्पष्ट करें।
2. कुंजी बनाएं या इम्पोर्ट करें
एक समर्थित एल्गोरिदम और उद्देश्य-विशिष्ट उपयोगों जैसे encrypt और decrypt का उपयोग करें। एक सिक्योर कॉन्टेक्स्ट में की (key) जनरेट करें या वांछित एक्सट्रेक्टेबिलिटी फ़्लैग के साथ रैप्ड सामग्री को इम्पोर्ट करें। अप्रत्याशित एल्गोरिदम पैरामीटर्स को अस्वीकार करें और लोकल स्टोरेज में रॉ की मैटेरियल को स्टोर करने से बचें।
3. सिफ़रटेक्स्ट को सुरक्षित रूप से बनाए रखें (Persist)
सिफ़रटेक्स्ट, प्रति एन्क्रिप्शन एक नया नॉनस (nonce), प्रमाणित मेटाडेटा, की-वर्ज़न और स्कीमा वर्ज़न स्टोर करें। एक ही कुंजी के तहत अद्वितीय नॉनस के साथ AES-GCM जैसे प्रमाणित एन्क्रिप्शन का उपयोग करें। टेनेंट या उपयोगकर्ता स्कोप को एसोसिएटेड डेटा में रखें, न कि एक अंतर्निहित विश्वास निर्णय के रूप में।
4. रिकवरी और रोटेशन की योजना बनाएं
प्रोफ़ाइल डिलीट होने या डिवाइस खो जाने के बाद एक non-extractable की (key) अनुपयोगी हो सकती है। बिना चुपचाप प्लेनटेक्स्ट में डाउनग्रेड किए, एक सुविचारित रिकवरी पाथ प्रदान करें, उदाहरण के लिए पासफ़्रेज़-व्युत्पन्न रैपिंग कुंजी या सर्वर-मध्यस्थता वाला पुनः-एन्क्रिप्शन फ़्लो। कुंजियों का वर्ज़न बनाएं और रिकॉर्ड्स को ट्रांज़ैक्शनल रूप से माइग्रेट करें।
5. परीक्षण और संचालन करें
असमर्थित एल्गोरिदम, असुरक्षित संदर्भों, कोटा त्रुटियों, बाधित राइट्स, नॉनस के पुन: उपयोग, वर्ज़न माइग्रेशन, लॉगआउट और रिकवरी विफलता का परीक्षण करें। CSP और डिपेंडेंसी समीक्षा लागू करें, संवेदनशील लॉग से बचें, और प्लेनटेक्स्ट रिकॉर्ड किए बिना डिक्रिप्शन विफलताओं को मापें।
उच्च गुणवत्ता वाला नमूना उत्तर
“मैं HTTPS अनिवार्य करूँगा, extractable को false पर सेट करके एक उद्देश्य-सीमित CryptoKey जनरेट करूँगा, और IndexedDB में केवल इसके ब्राउज़र-प्रबंधित हैंडल को बनाए रखूँगा। प्रत्येक रिकॉर्ड सिफ़रटेक्स्ट, एक अद्वितीय नॉनस, प्रमाणित मेटाडेटा और की-वर्ज़न स्टोर करता है। मैं शिप करने से पहले रिकवरी को परिभाषित करूँगा क्योंकि प्रोफ़ाइल खोने से एक non-extractable कुंजी अप्राप्य हो सकती है। CSP और डिपेंडेंसी नियंत्रण सक्रिय-स्क्रिप्ट जोखिम को कम करते हैं, लेकिन ओरिजिन में चलने वाला एक XSS पेलोड अभी भी अनुमत डिक्रिप्ट ऑपरेशन्स को लागू कर सकता है या ऐप खुला होने पर प्लेनटेक्स्ट पढ़ सकता है।”
सामान्य गलतियाँ
- रॉ की को localStorage में स्टोर करना → स्टोरेज चोरी से प्लेनटेक्स्ट एक्सेस उजागर होता है → एक non-extractable की-हैंडल को बनाए रखें।
- AES-GCM के साथ नॉनस का पुन: उपयोग करना → गोपनीयता और अखंडता विफल हो सकती है → प्रति कुंजी और रिकॉर्ड एक अद्वितीय नॉनस जनरेट करें।
- दावा करना कि XSS हल हो गया है → सेम-ओरिजिन कोड ऐप के अधिकारों का उपयोग कर सकता है → सक्रिय-स्क्रिप्ट की सीमा बताएं।
- रिकवरी डिज़ाइन को छोड़ देना → प्रोफ़ाइल खोने से डेटा एक्सेस नष्ट हो जाता है → रैपिंग, रीसेट और माइग्रेशन फ़्लो परिभाषित करें।
अनुवर्ती प्रश्न और उत्तर
क्या IndexedDB कुंजी को XSS से सुरक्षित बनाता है?
नहीं। यह एक साधारण स्टोरेज API में रॉ बाइट्स रखने से बचाता है, लेकिन सेम-ओरिजिन स्क्रिप्ट डेटाबेस तक पहुँच सकती है या एप्लिकेशन कोड को कॉल कर सकती है। CSP, विश्वसनीय डिपेंडेंसी और एक यथार्थवादी थ्रेट मॉडल का उपयोग करें।
डिवाइस खोने के बाद कोई उपयोगकर्ता कैसे रिकवर कर सकता है?
उपयोगकर्ता के पास मौजूद सीक्रेट या रिकवरी क्रेडेंशियल से प्राप्त की (key) के साथ डेटा की को रैप करें, या प्रमाणित सर्वर फ़्लो के माध्यम से पुनः एन्क्रिप्ट करें। ऑफ़लाइन और रीसेट ट्रेड-ऑफ़ को समझाएं; कभी भी चुपचाप एक नई कुंजी न बनाएं जो पुराने डेटा को डिक्रिप्ट न कर सके।
क्या रोटेशन के दौरान कुंजी को एक्सपोर्ट किया जा सकता है?
केवल तभी जब नीति इसकी अनुमति देती है। दोनों वर्ज़न उपलब्ध होने पर एक नई कुंजी जनरेट करने और रिकॉर्ड्स को पुनः एन्क्रिप्ट करने को प्राथमिकता दें; यदि रैपिंग की आवश्यकता है, तो रैपिंग की को सुरक्षित रखें और ट्रांज़िशन का ऑडिट करें।