प्रॉम्प्ट और संदर्भ
प्रदाता एक टाइमस्टैम्प और रॉ बॉडी पर हस्ताक्षर करता है। अनुरोध विलंबित, डुप्लिकेट, विकृत (malformed), या JSON पार्सिंग द्वारा परिवर्तित हो सकते हैं। कार्यान्वयन को तुलना के समय (comparison timing) को लीक किए बिना छेड़छाड़ और रीप्ले को अस्वीकार करना चाहिए।
साक्षात्कारकर्ता क्या जांचता है
- सटीक बाइट्स को सुरक्षित रखना और एक संरचित सिग्नेचर हेडर को सुरक्षित रूप से पार्स करना।
- निर्दिष्ट एल्गोरिदम के साथ HMAC की गणना करना और कॉन्स्टेंट टाइम में तुलना करना।
- टाइमस्टैम्प सहनशीलता (tolerance) और स्पष्ट विफलता व्यवहार को लागू करना।
उत्तर देने से पहले स्पष्ट करने वाले प्रश्न
- प्रदाता कौन सी सटीक हस्ताक्षरित स्ट्रिंग, डाइजेस्ट एल्गोरिदम, एन्कोडिंग और हेडर प्रारूप निर्दिष्ट करता है?
- क्या JSON पार्सिंग से पहले बॉडी रॉ बाइट्स के रूप में उपलब्ध है?
- क्लॉक-स्क्यू सहनशीलता और किस रीप्ले पहचानकर्ता की आवश्यकता है?
- क्या विकृत इनपुट को यह बताए बिना कि कौन सी जांच विफल रही, एक सामान्य अस्वीकृति लौटानी चाहिए?
30-सेकंड का उत्तर ढांचा
मैं रॉ बाइट्स को पढूंगा, उनके प्रकारों पर भरोसा किए बिना टाइमस्टैम्प और सिग्नेचर को पार्स करूंगा, अनुमत विंडो से बाहर के टाइमस्टैम्प को अस्वीकार करूंगा, और प्रदाता द्वारा परिभाषित विहित (canonical) स्ट्रिंग पर HMAC की गणना करूंगा। मैं एक कॉन्स्टेंट-टाइम प्रिमिटिव के साथ डिकोड किए गए MAC बाइट्स की तुलना करूंगा, फिर कतार में डालने से पहले इवेंट ID को डिडुप्लिकेट करूंगा। त्रुटियां एक सामान्य अस्वीकृति लौटाती हैं जबकि आंतरिक मेट्रिक्स विफलता को वर्गीकृत करते हैं।
चरण-दर-चरण गहन विश्लेषण
1. रॉ बॉडी को बनाए रखें
सत्यापन के लिए पार्स किए गए JSON को स्ट्रिंगिफ़ाई न करें। व्हाइटस्पेस, कुंजी क्रम (key order), और यूनिकोड एस्केपिंग बाइट्स को बदल सकते हैं। बॉडी को एक बार पढ़ें, आकार सीमा लागू करें, और सत्यापन व बाद की पार्सिंग के लिए समान बाइट्स पास करें।
2. हेडर को पार्स और मान्य करें
हेडर को टाइमस्टैम्प और संस्करणित हस्ताक्षरों में विभाजित करें, डुप्लिकेट या अमान्य एन्कोडिंग को अस्वीकार करें, और टाइमस्टैम्प की लंबाई को सीमित करें। टाइमस्टैम्प को एक पूर्णांक में बदलें और महंगे कार्य से पहले कॉन्फ़िगर की गई स्क्यू विंडो के बाहर के मानों को अस्वीकार करें।
3. गणना करें और तुलना करें
सटीक हस्ताक्षरित संदेश का निर्माण करें, कॉन्फ़िगर किए गए डाइजेस्ट के साथ HMAC की गणना करें, प्रदान किए गए हस्ताक्षर को डिकोड करें, और एक कॉन्स्टेंट-टाइम फ़ंक्शन के साथ समान लंबाई वाले बाइट ऐरे की तुलना करें। जब कोई हमलावर प्रतिक्रिया समय को माप सकता हो, तो साधारण समानता के साथ हेक्साडेसिमल स्ट्रिंग्स की तुलना कभी न करें।
4. रीप्ले को रोकें
हस्ताक्षर सत्यापन के बाद, एक स्थिर इवेंट ID की आवश्यकता होती है और इसे कम से कम स्वीकृत टाइमस्टैम्प विंडो जितनी लंबी अवधारण अवधि के साथ परमाणु रूप से (atomically) रिकॉर्ड करें। एक डुप्लिकेट मान्य अनुरोध व्यावसायिक प्रभाव को दोहराए बिना सफलता लौटा सकता है।
5. सीमाओं का परीक्षण करें
परिवर्तित बाइट्स, गलत सीक्रेट, गलत एल्गोरिदम, विकृत हेडर, पुराने और भविष्य के टाइमस्टैम्प, डुप्लिकेट हस्ताक्षर, खाली बॉडी, बड़े आकार की बॉडी और बार-बार आने वाले इवेंट IDs का परीक्षण करें। लॉग को सीक्रेट और संपूर्ण पेलोड से मुक्त रखें।
उच्च गुणवत्ता वाला नमूना उत्तर
“मैं रॉ बॉडी को सुरक्षित रखूंगा, टाइमस्टैम्प को पार्स और सीमित करूंगा, रीप्ले विंडो के बाहर अस्वीकार करूंगा, और प्रदाता की सटीक हस्ताक्षरित स्ट्रिंग का निर्माण करूंगा। मैं आवश्यक डाइजेस्ट के साथ HMAC की गणना करूंगा, हस्ताक्षर को डिकोड करूंगा, और एक कॉन्स्टेंट-टाइम बाइट तुलना का उपयोग करूंगा। सत्यापन के बाद, मैं कतार में डालने से पहले इवेंट ID को परमाणु रूप से डिडुप्लिकेट करूंगा। विकृत इनपुट को एक सामान्य अस्वीकृति मिलती है; आंतरिक काउंटर पार्सिंग, समय, MAC और रीप्ले विफलताओं में अंतर करते हैं।”
सामान्य गलतियाँ
- पार्स किए गए JSON को सत्यापित करना → क्रमांकन (serialization) हस्ताक्षरित बाइट्स को बदल सकता है → रॉ बॉडी को सत्यापित करें।
- साधारण स्ट्रिंग समानता का उपयोग करना → समय आंशिक मिलान प्रकट कर सकता है → कॉन्स्टेंट-टाइम बाइट तुलना का उपयोग करें।
- टाइमस्टैम्प जांच को छोड़ना → मान्य हस्ताक्षरों को रीप्ले किया जा सकता है → एक सीमित विंडो और ईवेंट डिडुप्लिकेशन लागू करें।
- हेडर और पेलोड लॉग करना → सीक्रेट या व्यक्तिगत डेटा लीक हो सकता है → केवल सुरक्षित IDs और विफलता वर्गों को लॉग करें।
अनुवर्ती प्रश्न और उत्तर
पार्स करने से पहले सत्यापित क्यों करें?
पहले पार्स करने से बाइट्स सामान्यीकृत (normalize) हो सकते हैं और यह वन-शॉट रिक्वेस्ट स्ट्रीम का उपभोग कर सकता है। सत्यापन में वही शामिल होना चाहिए जो प्रदाता ने हस्ताक्षरित किया है; स्वीकृति के बाद ही पार्स करें।
क्या रोटेशन के दौरान दो हस्ताक्षर स्वीकार किए जा सकते हैं?
हाँ, यदि प्रदाता ओवरलैप का दस्तावेजीकरण करता है। एक सीमित विंडो के भीतर केवल सक्रिय और सेवानिवृत्त (retiring) संस्करणों का प्रयास करें, रिकॉर्ड करें कि कौन सा संस्करण पास हुआ, और पुराने सीक्रेट को समाप्त करें।
क्या रीप्ले सुरक्षा के लिए टाइमस्टैम्प सत्यापन पर्याप्त है?
नहीं। एक वैध अनुरोध को विंडो के भीतर बार-बार रीप्ले किया जा सकता है। एक स्थिर इवेंट ID या डाइजेस्ट को परमाणु रूप से संग्रहीत करें और व्यावसायिक संचालन को इडेम्पोटेंट (idempotent) बनाएं।