बैकएंड इंटरव्यू: पासवर्ड्स को सुरक्षित रूप से कैसे स्टोर करें और लेगेसी हैशेस को कैसे माइग्रेट करें?

प्रश्न और दायरा

10,000,000 खातों वाला एक SaaS प्रोडक्ट पासवर्ड ऑथेंटिकेशन को फिर से बना रहा है। लगभग 7,000,000 डेटाबेस रिकॉर्ड्स कॉस्ट 10 के साथ bcrypt का उपयोग करते हैं, 2,000,000 रिकॉर्ड्स 210000 इटरेशन्स के साथ PBKDF2-HMAC-SHA256 का उपयोग करते हैं, और 1,000,000 रिकॉर्ड्स बिना प्रति-रिकॉर्ड सॉल्ट के SHA-256 का उपयोग करते हैं। मौजूदा फॉर्मेट्स असंगत हैं, और कुछ पंक्तियाँ सीधे अपने एल्गोरिदम और पैरामीटर्स की पहचान नहीं करती हैं। पीक पर, ऑथेंटिकेशन सर्विस को प्रति सेकंड 1500 पासवर्ड वेरिफिकेशन्स संभालने होंगे। प्रत्येक इंस्टेंस अधिकतम 24 समवर्ती (कंकरेंट) महंगे हैशेस की अनुमति देता है।

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

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

इंटरव्यूअर क्या मूल्यांकन कर रहा है

पहला, क्या उम्मीदवार ऑनलाइन अनुमान लगाने (गेसिंग) और ऑफ़लाइन क्रैकिंग के बीच अंतर कर सकता है? रेट लिमिट्स एक लॉगिन एंडपॉइंट को सीमित करती हैं, लेकिन वे उस हमलावर को सीमित नहीं करती हैं जिसने हैश डेटाबेस प्राप्त कर लिया है। पासवर्ड कम-एंट्रॉपी वाले मानवीय रहस्य हैं। SHA-256 जैसा तेज़ डाइजेस्ट हमलावर को उम्मीदवारों को जल्दी से इन्यूमरेट करने देता है; एक पासवर्ड-विशिष्ट हैश प्रति-रिकॉर्ड सॉल्ट, ट्यूनेबल कम्प्यूटेशन और मेमोरी कॉस्ट के माध्यम से प्रत्येक अनुमान की लागत को बढ़ाता है।

दूसरा, क्या उम्मीदवार समझता है कि पैरामीटर्स को वास्तविक क्षमता के आधार पर मापा जाना चाहिए? "Argon2id का उपयोग करें" एक एल्गोरिदम चुनता है लेकिन डिज़ाइन को पूरा नहीं करता है। एक पूर्ण उत्तर मेमोरी m, इटरेशन्स t, पैरेललिज्म p, सॉल्ट की लंबाई, और आउटपुट की लंबाई का चयन करता है, फिर गणना करता है कि समवर्ती वेरिफिकेशन मेमोरी, CPU, लेटेंसी, और डिनायल-ऑफ-सर्विस जोखिम को कैसे प्रभावित करता है। उच्च पैरामीटर्स अपने आप अधिक सुरक्षित नहीं होते हैं। यदि हमले का ट्रैफ़िक सर्विस मेमोरी को समाप्त कर देता है, तो ऑथेंटिकेशन की उपलब्धता सबसे पहले विफल हो जाती है।

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

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

उत्तर देने से पहले स्पष्टीकरण

• क्या प्रत्येक मौजूदा फॉर्मेट की विश्वसनीय रूप से पहचान की जा सकती है? एल्गोरिदम, पैरामीटर्स, कैरेक्टर एन्कोडिंग, सॉल्ट लोकेशन और ऐतिहासिक लाइब्रेरी वर्ज़न स्थापित करें। किसी फॉर्मेट का अनुमान न लगाएं और किसी अज्ञात पंक्ति के लिए कई वेरिफायर्स को आज़माने की कोशिश न करें।
• लेगेसी bcrypt ने 72 बाइट्स से अधिक के इनपुट्स को कैसे संभाला? ऐतिहासिक कार्यान्वयन की एन्कोडिंग और ट्रंकेशन सेमेंटिक्स को पुन: उत्पन्न करें ताकि माइग्रेशन उपयोगकर्ता के प्रभावी क्रेडेंशियल को चुपचाप न बदले।
• क्या डेटाबेस, बैकअप, या लेगेसी हैश सेट कभी उजागर (एक्सपोज़) हुआ है? वर्तमान डेटाबेस को रैप करने से पहले से उजागर बिना सॉल्ट वाले तेज़ डाइजेस्ट को वापस नहीं लिया जा सकता है। जबरन रीसेट और सेशन कार्रवाई आवश्यक हो सकती है।
• ऑथेंटिकेशन इंस्टेंस का वास्तविक रिसोर्स बजट क्या है? बेसलाइन मेमोरी, CPU कोटा, हैश-कंकरेंसी सीमा, ऑटोस्केलिंग गति, लक्षित p95 और p99 लेटेंसी, और स्वीकार्य विफलता दर प्राप्त करें।
• क्या FIPS या अन्य अनुपालन (कंप्लायंस) बाधाएं लागू होती हैं? वे एल्गोरिदम और कार्यान्वयन को बाधित कर सकते हैं, लेकिन एक कंप्लायंस लेबल पैरामीटर मेजरमेंट या माइग्रेशन डिज़ाइन की जगह नहीं लेता है।
• क्या कोई पेपर पहले से मौजूद है? इसके स्टोरेज, कॉल डिपेंडेंसी, वर्ज़न्स, रोटेशन क्षमता, ऑडिट सीमा और की-सर्विस अनुपलब्ध होने पर इसके व्यवहार की पुष्टि करें।
• पासवर्ड परिवर्तन और सेशन जारी करने के लिए ट्रांजेक्शन सीमाएं क्या हैं? माइग्रेशन, समवर्ती रीसेट, और सेशन जारी करने का क्रम स्पष्ट होना चाहिए, अन्यथा एक पुराना पासवर्ड रीसेट के बाद एक नया सेशन प्राप्त कर सकता है।
• व्यावसायिक मूल्य और जोखिम को लंबे समय से निष्क्रिय खातों को कैसे विभाजित करना चाहिए? विशेषाधिकार प्राप्त, हाल ही में सक्रिय, और वर्षों से निष्क्रिय खातों की अलग-अलग समय सीमाएं और पुनः-सत्यापन आवश्यकताएं हो सकती हैं।

30-सेकंड उत्तर का फ्रेमवर्क

"मैं प्राथमिक लक्ष्य को हैश-डेटाबेस ब्रीच के बाद ऑफ़लाइन अनुमान लगाने के प्रतिरोध के रूप में परिभाषित करूंगा और ऑनलाइन ऑथेंटिकेशन क्षमता की अलग से रक्षा करूंगा। नए पासवर्ड एक स्वतंत्र रैंडम सॉल्ट के साथ Argon2id का उपयोग करते हैं। रिकॉर्ड में एल्गोरिदम, वर्ज़न, m/t/p, सॉल्ट और आउटपुट शामिल होते हैं। यदि हम पेपर का उपयोग करते हैं, तो यह डेटाबेस के बाहर एक की-सिस्टम में रहता है। मैं एक मूल्य की नकल करने के बजाय, उम्मीदवार शुरुआती बिंदु के रूप में OWASP के वर्तमान न्यूनतम का उपयोग करूंगा, फिर समवर्ती मेमोरी, CPU और p99 लेटेंसी के लिए प्रोडक्शन-समतुल्य इंस्टेंस पर लोड-टेस्ट करूंगा।

लॉगिन पर, घोषित रिकॉर्ड वर्ज़न ठीक एक लेगेसी वेरिफायर का चयन करता है। सफल सत्यापन के बाद, मैं वर्तमान Argon2id रिकॉर्ड की गणना करता हूं और पुराने हैश के विरुद्ध कम्पेयर-एंड-स्वैप करता हूं। यदि कोई समवर्ती परिवर्तन इसे विफल कर देता है, तो मैं पासवर्ड रीसेट को ओवरराइट करने के बजाय नवीनतम रिकॉर्ड को पुनः लोड और सत्यापित करता हूं। नए और रीसेट पासवर्ड तुरंत वर्तमान फॉर्मेट का उपयोग करते हैं। बिना सॉल्ट वाले SHA-256 खातों को एक छोटी माइग्रेशन समय सीमा मिलती है; जब सुरक्षित रैपिंग अनुपलब्ध होती है या एक्सपोज़र हुआ होता है, तो उन्हें रीसेट करना होगा।

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

चरण-दर-चरण स्पष्टीकरण

चरण 1: ऑनलाइन और ऑफ़लाइन अटैक सरफेसेस को अलग करें

सामान्य लॉगिन ऑनलाइन पाथ है। एंडपॉइंट थ्रूपुट, प्रति-खाता नियंत्रण, स्रोत नियंत्रण, जोखिम प्रणाली और निगरानी हमलावर को सीमित करते हैं। डेटाबेस ब्रीच के बाद अनुमान लगाना ऑफ़लाइन पाथ है: हमलावर एप्लिकेशन की दर सीमाओं के बिना अपने स्वयं के GPUs, ASICs, या क्लाउड इंस्टेंसेस पर वेरिफायर चलाता है। पासवर्ड स्टोरेज मुख्य रूप से उस दूसरे पाथ पर प्रत्येक उम्मीदवार प्रयास की लागत को बढ़ाता है।

बिना सॉल्ट वाले SHA-256 में दो समस्याएं हैं। यह तेज़ है, और वही पासवर्ड वही डाइजेस्ट उत्पन्न करता है, इसलिए एक हमलावर पूर्व-गणना किए गए कार्य का पुन: उपयोग कर सकता है और पासवर्ड का पुन: उपयोग करने वाले समूहों की पहचान कर सकता है। प्रत्येक रिकॉर्ड के लिए एक स्वतंत्र रैंडम सॉल्ट समान पासवर्ड को अलग-अलग आउटपुट उत्पन्न करने के लिए बाध्य करता है और प्रति-रिकॉर्ड कार्य करने के लिए मजबूर करता है। सॉल्ट को हैश के साथ संग्रहीत किया जा सकता है और इसे गुप्त रखने की आवश्यकता नहीं है। एक सॉल्ट तेज़ SHA-256 को एक उपयुक्त पासवर्ड हैश में नहीं बदलता है; सार्थक प्रतिरोध एक समर्पित, ट्यूनेबल, अधिमानतः मेमोरी-हार्ड एल्गोरिदम से आता है।

पेपर एक अलग नियंत्रण है। यह रिकॉर्ड्स में साझा किया गया या वर्ज़न द्वारा प्रबंधित एक सर्वर-साइड सीक्रेट है, और इसे पासवर्ड डेटाबेस से अलग किया जाना चाहिए, आमतौर पर एक की-मैनेजमेंट सर्विस, HSM, या संरक्षित निष्पादन वातावरण में। यह केवल-डेटाबेस ब्रीच के प्रभाव को कम कर सकता है, लेकिन यह न तो प्रति-रिकॉर्ड सॉल्ट की जगह लेता है और न ही धीमे हैशिंग की। यदि डेटाबेस और पेपर दोनों उजागर हो जाते हैं, तो डेटाबेस बैच प्रोसेसिंग प्रभावित रिकॉर्ड्स को सुरक्षित रूप से पुनः की (rekey) नहीं कर सकती है क्योंकि सर्विस के पास उपयोगकर्ताओं के प्लेनटेक्स्ट पासवर्ड नहीं होते हैं।

चरण 2: पैरामीटर्स का चयन करें और ऑथेंटिकेशन क्षमता की गणना करें

नए रिकॉर्ड्स के लिए, एक मेनटेन किए गए Argon2id कार्यान्वयन का उपयोग करें। एक वर्तमान OWASP न्यूनतम उम्मीदवार m=19456 KiB, t=2, और p=1 है। RFC 9106 उच्च-मेमोरी सामान्य सिफारिशें देता है, जिसमें मेमोरी-बाधित विकल्प के लिए 64 MiB, तीन पास और चार लेन शामिल हैं। दस्तावेज़ विभिन्न परिचालन बाधाओं को लक्षित करते हैं, इसलिए कोई भी एक टुपल सार्वभौमिक वेब-सर्विस स्थिरांक नहीं है।

अधिक उचित चयन प्रक्रिया इस प्रकार है:

1. प्रोडक्शन में उपयोग किए जाने वाले समान CPU, मेमोरी सीमा और रनटाइम पर समीक्षित उम्मीदवार से शुरुआत करें।
2. एकल-सत्यापन माध्यिका, p95, p99, वास्तविक रेजिडेंट मेमोरी, और CPU समय को मापें।
3. सामान्य पीक ट्रैफ़िक, लॉगिन बर्स्ट, गलत पासवर्ड और गैर-मौजूद खातों के मिश्रण का लोड-टेस्ट करें।
4. कंकरेंसी को सीमित करें और कतार समय, कंटेनर OOMs, CPU थ्रॉटलिंग, और अपस्ट्रीम टाइमआउट का निरीक्षण करें।
5. उपलब्धता बजट के भीतर उच्चतम संधारणीय हमलावर लागत चुनें, और हार्डवेयर, लाइब्रेरी वर्ज़न और माप की तारीख रिकॉर्ड करें।

19 MiB पर, 24 एक साथ संचालन के लिए सैद्धांतिक हैश वर्किंग मेमोरी पहले से ही 456 MiB है, प्रोसेस बेसलाइन, लाइब्रेरी ओवरहेड, रिक्वेस्ट ऑब्जेक्ट्स और सुरक्षा मार्जिन से पहले। यदि लक्षित इंस्टेंस पर एक सत्यापन में 250 मिलीसेकंड लगते हैं, तो इसका अनुमानित अधिकतम लगभग 96 पूर्णता प्रति सेकंड है। 1500 प्रति सेकंड की सेवा के लिए कम से कम लगभग 16 लगातार उपलब्ध समकक्ष इंस्टेंस की आवश्यकता होती है, जिसमें टेल लेटेंसी, विफलताओं और ऑटोस्केलिंग लैग के लिए अतिरिक्त हेडरूम होता है। ये गणनाएँ क्षमता के परिमाण के क्रम (ऑर्डर ऑफ मैग्नीट्यूड) को उजागर करती हैं; लोड परीक्षण अंतिम मान निर्धारित करते हैं।

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

चरण 3: क्रेडेंशियल रिकॉर्ड्स को सेल्फ-डिस्क्राइबिंग और विकसित होने योग्य बनाएं

रिकॉर्ड में सत्यापन के लिए आवश्यक गैर-गुप्त जानकारी होनी चाहिए। एक Argon2 एन्कोडिंग इस तरह दिख सकती है:

$argon2id$v=19$m=19456,t=2,p=1$SALT_BASE64$TAG_BASE64

लेगेसी फॉर्मेट्स को {bcrypt}, {pbkdf2-sha256}, और {sha256-legacy} जैसे नियतात्मक (डिटर्मिनिस्टिक) मैपिंग की भी आवश्यकता होती है। एक लेबल एक पार्सिंग प्रोटोकॉल है, कोई सुरक्षा समर्थन नहीं। किसी अज्ञात लेबल, अनुपलब्ध फ़ील्ड, अमान्य Base64 मान, या नीति से बाहर के पैरामीटर को अस्वीकार करें और खाते को एक नियंत्रित पुनर्प्राप्ति कतार में भेजें। एक के मेल खाने तक क्रम में एल्गोरिदम को न आज़माएं।

पैरामीटर पार्सिंग को ऊपरी सीमाओं की आवश्यकता होती है। यदि कोई हमलावर रिकॉर्ड के साथ छेड़छाड़ कर सकता है, तो वे अत्यधिक मेमोरी या इटरेशन मान सेट कर सकते हैं और लॉगिन अनुरोध के माध्यम से सर्विस संसाधनों का उपभोग कर सकते हैं। वेरिफायर केवल तैनात एल्गोरिदम और अनुमत पैरामीटर श्रेणियों को स्वीकार करता है। सीमा से बाहर का रिकॉर्ड संवेदनशील डेटा के बिना एक सुरक्षा घटना उत्पन्न करता है और खाता पुनर्प्राप्ति की आवश्यकता होती है।

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

चरण 4: सफल लॉगिन के बाद सुरक्षित रूप से अपग्रेड करें

माइग्रेशन फ़ंक्शन रिकॉर्ड को पार्स करता है और एक मिलान वाले वेरिफायर को इनवोक करता है। केवल एक लेगेसी क्रेडेंशियल के सफल होने के बाद ही सर्विस के पास इस अनुरोध से सही प्लेनटेक्स्ट होता है और वह वर्तमान Argon2id रिकॉर्ड की गणना कर सकती है। महंगे काम को छोटे डेटाबेस लेनदेन से बाहर रखें और पुराने रिकॉर्ड पर राइट की शर्त लगाएं:

record = loadCredential(userId)
ok = verifyByDeclaredScheme(record.hash, submittedPassword)
if !ok: rejectWithGenericError()

if needsRehash(record.hash):
  upgraded = hashWithCurrentPolicy(submittedPassword)
  changed = compareAndSwap(userId, expected=record.hash, replacement=upgraded)
  if !changed:
    latest = loadCredential(userId)
    if !verifyByDeclaredScheme(latest.hash, submittedPassword):
      rejectAndAskForFreshLogin()

issueSessionAfterCredentialStateIsConfirmed()

कम्पेयर-एंड-स्वैप एक लॉगिन अपग्रेड को समवर्ती पासवर्ड रीसेट को ओवरराइट करने से रोकता है। एक असफल सशर्त अपडेट का मतलब यह हो सकता है कि किसी अन्य लॉगिन ने उसी माइग्रेशन को पूरा कर लिया है या उपयोगकर्ता ने सिर्फ एक अलग पासवर्ड चुना है। नवीनतम रिकॉर्ड के विरुद्ध वर्तमान इनपुट को पुनः लोड और सत्यापित करें; केवल इसलिए सेशन जारी न करें क्योंकि पुराना रिकॉर्ड एक बार मेल खाता था। पंजीकरण, स्वैच्छिक पासवर्ड परिवर्तन और पासवर्ड रिकवरी सीधे वर्तमान फॉर्मेट को लिखते हैं और कभी भी दूसरा लेगेसी रिकॉर्ड नहीं बनाते हैं।

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

चरण 5: स्वीकार्य और उच्च-जोखिम वाले लेगेसी फॉर्मेट्स के साथ अलग-अलग व्यवहार करें

Bcrypt और पर्याप्त रूप से मजबूत PBKDF2 एक नियंत्रित माइग्रेशन अवधि के दौरान केवल-पढ़ने (रीड-ओनली) के लिए सत्यापन बनाए रख सकते हैं और सफल लॉगिन के बाद अपग्रेड कर सकते हैं। लेगेसी वेरिफायर्स के एक्सपोज़र को न्यूनतम करें: वे केवल मौजूदा रिकॉर्ड्स की सेवा करते हैं और नए क्रेडेंशियल्स नहीं बना सकते हैं। प्रत्येक फॉर्मेट के लिए शेष खातों, गतिविधि और माइग्रेशन गति को ट्रैक करें। इसकी समय सीमा पर एक वेरिफायर को हटाने से पहले, उस पर निर्भर रहने वाले प्रत्येक खाते का समाधान करें।

बिना सॉल्ट वाले SHA-256 में अधिक जोखिम होता है। यदि कोई एक्सपोज़र नहीं हुआ है और तत्काल सार्वभौमिक रीसेट संभव नहीं है, तो सर्विस अस्थायी डेटाबेस हार्डनिंग के रूप में मौजूदा डाइजेस्ट को नए सॉल्ट वाले धीमे बाहरी एल्गोरिदम के इनपुट के रूप में मान सकती है। सत्यापन पहले ऐतिहासिक SHA-256 ऑपरेशन को पुन: प्रस्तुत करता है और फिर बाहरी परत को सत्यापित करता है। एक सफल लॉगिन के बाद, सर्विस अभी भी सबमिट किए गए पासवर्ड से गणना किए गए एक मानक Argon2id रिकॉर्ड के साथ इसे बदल देती है।

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

चरण 6: पेपर वर्ज़न्स और ब्रीच रिस्पॉन्स डिज़ाइन करें

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

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

सबूत के आधार पर ब्रीच रिस्पॉन्स को स्तरित करें:

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

एक सफल रोटेशन ऐतिहासिक एक्सपोज़र को मिटा नहीं देता है। घटना रिकॉर्ड में प्रभावित वर्ज़न्स, खाता दायरा, बैकअप, सेशन्स, अधिसूचना, पूर्णता प्रतिशत और अवशिष्ट अपवाद शामिल होने चाहिए।

चरण 7: इन्यूमरेसन और रिसोर्स एग्जॉशन का एक साथ विरोध करें

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

महंगा हैशिंग स्वयं एक डिनायल-ऑफ-सर्विस सतह बनाता है। हैश कतार से पहले, मोटे स्रोत थ्रॉटलिंग और अनुरोध-वैधता जांच करें जो यह प्रकट नहीं करते हैं कि कोई खाता मौजूद है या नहीं। स्वीकृत कार्य के लिए, स्वतंत्र खाता और स्रोत कोटा, एक वैश्विक सीमित कतार, और प्रति इंस्टेंस 24 कंकरेंसी परमिट लागू करें। आईपी-और-यूज़रनेम जोड़ी द्वारा कीड की गई एक एकल बकेट हमलावर को बार-बार एक आयाम बदलने और कुल सीमाओं से बचने की अनुमति देती है।

जब कतार भरी हो, तो बिना किसी सीमा के काम जमा करने के बजाय एकसमान अस्थायी प्रतिक्रिया के साथ तेज़ी से विफल (fail fast) हों। स्केलिंग संकेतों में कतार समय, सक्रिय हैश, मेमोरी हेडरूम और CPU थ्रॉटलिंग शामिल होने चाहिए, न कि केवल अनुरोध संख्या। लॉग्स में एक अपरिवर्तनीय आंतरिक खाता पहचानकर्ता, कम-कार्डिनैलिटी योजना वर्ज़न, परिणाम वर्ग, थ्रॉटलिंग आयाम और लेटेंसी बकेट शामिल होते हैं। उनमें कोई सबमिट किया गया पासवर्ड, पूर्ण क्रेडेंशियल रिकॉर्ड या की सामग्री नहीं होती है।

चरण 8: चरणों में रोल आउट करें और सबूतों के साथ स्वीकार करें

केवल-पढ़ने योग्य इन्वेंट्री के साथ शुरुआत करें। पुष्टि करें कि प्रत्येक लेगेसी रिकॉर्ड पार्स होता है, और एक अलग वातावरण में ज्ञात परीक्षण वैक्टर के साथ ऐतिहासिक कार्यान्वयन को सत्यापित करें। फिर ऐसा कोड तैनात करें जो प्रत्येक समर्थित लेगेसी फॉर्मेट को पढ़ सकता है लेकिन केवल वर्तमान फॉर्मेट लिखता है। नए पंजीकरण और पासवर्ड परिवर्तन पहले Argon2id लिखें। एक छोटे समूह के लिए लॉगिन अपग्रेड सक्षम करें, CAS संघर्षों, सत्यापन विफलताओं और संसाधन वक्रों का निरीक्षण करें, और धीरे-धीरे विस्तार करें।

पूर्ण रिलीज़ से पहले, कम से कम सत्यापित करें:

• प्रत्येक ऐतिहासिक फॉर्मेट के लिए सही-पासवर्ड, गलत-पासवर्ड, सीमा-लंबाई, यूनिकोड और विकृत-रिकॉर्ड व्यवहार।
• लॉगिन अपग्रेड और समवर्ती पासवर्ड रीसेट के बीच रेस, यह साबित करते हुए कि एक पुराना लॉगिन नए पासवर्ड को ओवरराइट नहीं कर सकता है या अमान्य सेशन जारी नहीं कर सकता है।
• वर्तमान, पिछले और अज्ञात पेपर वर्ज़न्स के लिए रोटेशन और विफलता अभ्यास।
• मिश्रित हमला ट्रैफ़िक के साथ लक्षित 1500 सत्यापन प्रति सेकंड पर लेटेंसी, मेमोरी, CPU, कतार और स्केलिंग।
• गैर-मौजूद खातों और प्रत्येक विफलता वर्ग के लिए संदेश, स्थिति, आकार और लेटेंसी वितरण।
• डेटाबेस, बैकअप, लॉग्स, मेट्रिक्स और त्रुटि ट्रैकिंग में संवेदनशील फ़ील्ड्स के लिए स्कैन।

माइग्रेशन डैशबोर्ड एल्गोरिदम और जोखिम स्तर के आधार पर समूहीकृत करता है: कुल संख्या, हाल ही में सक्रिय संख्या, दैनिक सफल अपग्रेड, विफलता के कारण, अनिवार्य-रीसेट पूर्णता और समय सीमा। तकनीकी पूर्णता का अर्थ है कि प्रत्येक नया राइट वर्तमान नीति का उपयोग करता है; बिना सॉल्ट वाले SHA-256 और उजागर वर्ज़न्स शून्य पर हैं; अनावश्यक लेगेसी वेरिफायर्स हटा दिए गए हैं; किसी भी शेष स्वीकार्य लेगेसी फॉर्मेट्स में प्रलेखित अपवाद हैं; पीक-लोड और रेस परीक्षण पास होते हैं; पेपर रोटेशन और रिकवरी अभ्यासों के सबूत हैं; और ऑथेंटिकेशन SLO समझौते के भीतर रहता है।

उच्च-गुणवत्ता वाला नमूना उत्तर

"मैं पहले दो अटैक सरफेसेस को अलग करूंगा। एंडपॉइंट नियंत्रण ऑनलाइन हमलों को बाधित करते हैं; वे हैश-डेटाबेस ब्रीच के बाद ऑफ़लाइन हमलों को बाधित नहीं करते हैं। इसलिए पासवर्ड्स को एक स्वतंत्र रैंडम सॉल्ट और ट्यूनेबल लागत के साथ एक समर्पित मेमोरी-हार्ड हैश की आवश्यकता होती है। नए रिकॉर्ड्स एक परिपक्व Argon2id कार्यान्वयन का उपयोग करते हैं और एल्गोरिदम वर्ज़न, m/t/p, सॉल्ट और आउटपुट को सेल्फ-डिस्क्राइब करते हैं। यदि सक्षम किया गया है, तो पेपर्स को डेटाबेस और उसके बैकअप के बाहर एक की-सिस्टम में वर्ज़न किया जाता है।

मैं किसी ब्लॉग से सीधे पैरामीटर्स कॉपी नहीं करूंगा। मैं OWASP के वर्तमान 19 MiB, t=2, p=1 को एक न्यूनतम उम्मीदवार के रूप में उपयोग करूंगा और प्रोडक्शन-समतुल्य इंस्टेंस पर एकल और समवर्ती p50, p95, p99, CPU और वास्तविक मेमोरी को मापूंगा, फिर सामान्य पीक और अटैक ट्रैफ़िक का लोड-टेस्ट करूंगा। उन्नीस MiB गुणा 24 समवर्ती संचालन पहले से ही 456 MiB वर्किंग मेमोरी है, इसलिए सर्विस को एक सीमित कतार, कंकरेंसी परमिट और पर्याप्त इंस्टेंस हेडरूम की आवश्यकता होती है। एक परिपक्व लाइब्रेरी प्रति रिकॉर्ड एक रैंडम सॉल्ट उत्पन्न करती है, और रिकॉर्ड भविष्य के अपग्रेड के लिए पैरामीटर्स रखता है।

लॉगिन पर, घोषित फॉर्मेट ठीक एक वेरिफायर का चयन करता है। एक लेगेसी पासवर्ड के सफल होने के बाद, मैं डेटाबेस लेनदेन के बाहर वर्तमान Argon2id रिकॉर्ड की गणना करता हूं और केवल तभी अपडेट करता हूं जब पुराना हैश अभी भी मेल खाता हो। यदि CAS विफल हो जाता है, तो मैं नवीनतम क्रेडेंशियल को पुनः लोड करता हूं और इस इनपुट को फिर से सत्यापित करता हूं। समवर्ती लॉगिन तब कन्वर्ज हो सकते हैं, जबकि एक पुराना लॉगिन समवर्ती पासवर्ड रीसेट को ओवरराइट नहीं कर सकता है। मैं वर्तमान क्रेडेंशियल स्थिति की पुष्टि करने के बाद ही एक सेशन जारी करता हूं। पंजीकरण, स्वैच्छिक परिवर्तन और रिकवरी पहले दिन से केवल नए फॉर्मेट को लिखते हैं।

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

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

सामान्य गलतियाँ और सुधार

• पासवर्ड्स को सॉल्टेड SHA-256 के रूप में संग्रहीत करना → सॉल्ट क्रॉस-अकाउंट कार्य के पुन: उपयोग को रोकता है लेकिन एक रिकॉर्ड के तेज़ अनुमान को नहीं → एक समर्पित, ट्यूनेबल, मेमोरी-हार्ड पासवर्ड हैश का उपयोग करें।
• यह दावा करना कि हैशेस को क्रैक नहीं किया जा सकता → उम्मीदवार का अनुमान लगाना अभी भी कमजोर पासवर्ड ढूंढता है → लक्ष्य को ऑफ़लाइन लागत बढ़ाने के रूप में बताएं, साथ ही समझौता किए गए पासवर्ड को ब्लॉक करना और MFA शामिल करें।
• OWASP पैरामीटर्स को स्थायी रूप से इष्टतम मानना → हार्डवेयर, लाइब्रेरी, इंस्टेंस संसाधन और ट्रैफ़िक बदलते हैं → बेंचमार्क वातावरण रिकॉर्ड करें, पुनः मापें और वर्ज़न द्वारा अपग्रेड करें।
• प्रत्येक bcrypt रिकॉर्ड को ऑफ़लाइन Argon2id में कनवर्ट करना → प्लेनटेक्स्ट के बिना एक मानक नया हैश प्राप्त नहीं किया जा सकता है → सफल सत्यापन के बाद रीहैश करें और शेष को जोखिम के अनुसार रैप, रीसेट या फ़्रीज़ करें।
• पुराने मान की शर्त के बिना माइग्रेशन को अपडेट करना → लॉगिन एक पूर्ण पासवर्ड रीसेट को ओवरराइट कर सकता है → कम्पेयर-एंड-स्वैप का उपयोग करें, फिर विफलता के बाद पुनः लोड और पुनः सत्यापित करें।
• हैशिंग के दौरान उपयोगकर्ता-पंक्ति (user-row) लॉक रखना → महंगा काम लॉक की अवधि और पूल अधिभोग को बढ़ाता है → लेनदेन के बाहर गणना करें और एक छोटा सशर्त राइट निष्पादित करें।
• पेपर को उसी डेटाबेस कॉन्फ़िगरेशन टेबल में रखना → एक डेटाबेस ब्रीच दोनों परतों को प्राप्त कर लेता है → की को स्वतंत्र रूप से संरक्षित सिस्टम में स्टोर करें और वर्ज़न द्वारा ऑडिट करें।
• एक पर्यावरण चर (environment variable) को बदलकर पेपर को रोटेट करना → पुराने रिकॉर्ड्स को नई की के साथ सीधे सत्यापित नहीं किया जा सकता है → दो वर्ज़न्स को संक्षेप में रखें, फिर सफल लॉगिन के बाद पुनर्गणना करें या रीसेट की आवश्यकता रखें।
• गैर-मौजूद खाते के लिए तुरंत लौटना → प्रतिक्रिया समय खाते के अस्तित्व को प्रकट करता है → एकसमान त्रुटियों, एक डमी हैश और अनुभवजन्य लेटेंसी-वितरण परीक्षणों का उपयोग करें।
• कंकरेंसी सीमा के बिना Argon2id चलाना → एक हमलावर मेमोरी और CPU खपत को बढ़ा सकता है → दो-आयामी सीमाएं लागू करें, फिर एक सीमित कतार और कंकरेंसी परमिट।
• bcrypt की इनपुट सीमा को अनदेखा करना → ऐतिहासिक 72-बाइट व्यवहार माइग्रेशन के दौरान प्रभावी क्रेडेंशियल को बदल सकता है → लेगेसी वेरिफायर को पुन: उत्पन्न करें और प्रभावित खातों के लिए एक स्पष्ट पासवर्ड परिवर्तन की आवश्यकता रखें।
• केवल यह जांचना कि नए पंजीकरण Argon2id का उपयोग करते हैं → सक्रिय या उच्च-जोखिम वाले लेगेसी रिकॉर्ड उजागर रहते हैं → एल्गोरिदम, जोखिम और गतिविधि द्वारा इन्वेंट्री को ट्रैक करें, शून्य और अपवाद मानदंडों के साथ।

फॉलो-अप प्रश्न

फॉलो-अप 1: एक सॉल्ट को प्लेनटेक्स्ट में क्यों संग्रहीत किया जा सकता है जबकि एक पेपर को गुप्त रहना चाहिए?

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

फॉलो-अप 2: क्या डेटाबेस सीधे Argon2id इटरेशन संख्या बढ़ा सकता है?

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

फॉलो-अप 3: CAS विफल होने के बाद तुरंत लॉगिन की अनुमति क्यों नहीं दी जाती?

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

फॉलो-अप 4: क्या उच्च Argon2id पैरामीटर्स हमेशा बेहतर होते हैं?

उच्च मेमोरी या समय लागत ऑफ़लाइन हमले की लागत और वैध-लॉगिन संसाधन उपयोग को बढ़ाती है। अत्यधिक पैरामीटर्स टेल लेटेंसी, कतार निर्माण, इंस्टेंस OOMs, और सस्ते अनुरोधों के लिए डिनायल-ऑफ-सर्विस एम्पलीफायर बनाते हैं। सही नीति वास्तविक हार्डवेयर, कंकरेंसी, स्केलिंग और SLO बाधाओं के तहत मापी गई उच्चतम संधारणीय लागत है, और हार्डवेयर और खतरों के बदलने पर इसका पुनर्मूल्यांकन किया जाना चाहिए।

फॉलो-अप 5: उस खाते का क्या होना चाहिए जो पांच साल से निष्क्रिय है और अभी भी bcrypt का उपयोग करता है?

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