डेवलपर टूल · UUID जनरेटर
क्या रैंडम UUID पासवर्ड रीसेट या सत्र टोकन के रूप में सुरक्षित है?
· यह क्यों मायने रखती है
uuid क्रिप्टोग्राफी ब्राउज़र-एपिस
CSPRNG के v4 UUID में बहुत अधिक एन्ट्रापी है, तो सुरक्षा समीक्षक अभी भी UUID टोकन पर क्यों नाराज़ होते हैं? यह पोस्ट एन्ट्रापी प्रश्न को डिज़ाइन प्रश्न से अलग करती है।
रीसेट लिंक जो पंक्ति के UUID का उपयोग करता है - एक सामान्य शॉर्टकट और दो बहुत अलग कारणों से यह असुरक्षित हो सकता है
एक सामान्य शॉर्टकट: पासवर्ड-रीसेट टोकन के रूप में उपयोगकर्ता की UUID पंक्ति पहचानकर्ता का उपयोग करें। तालिका में एक UUID कॉलम है; यह अद्वितीय है; इसका अनुमान लगाना कठिन है (यदि यह v4 है)। URL /reset है? टोकन=550e8400-e29b-41d4-a716-446655440000। एक सुरक्षा समीक्षक इसे तुरंत अस्वीकार कर देता है, इसलिए नहीं कि UUID कमज़ोर है, बल्कि इसलिए क्योंकि यह दो चिंताओं को जोड़ता है जिन्हें स्वतंत्र होना चाहिए। पंक्ति UUID स्थिर है और आमतौर पर सार्वजनिक रूप से दिखाई देती है (URL, APआई, लॉग में)। रीसेट टोकन एकल-उपयोग और गुप्त होना चाहिए। पंक्ति UUID को टोकन के रूप में पुन: उपयोग करने का मतलब है कि उपयोगकर्ता की पहचान और उनके रीसेट क्रेडेंशियल का मान समान है, और क्रेडेंशियल समाप्त होने के बजाय हमेशा के लिए रहता है। एक हमलावर जो उपयोगकर्ता की ID जानता है वह रीसेट कर सकता है। एक उपयोगकर्ता जिसने पांच साल पहले रीसेट लिंक को कॉपी-पेस्ट किया था, वह अभी भी इसका उपयोग कर सकता है। ये डिज़ाइन दोष हैं, एन्ट्रापी दोष नहीं।
एन्ट्रॉपी जाँच: 122 यादृच्छिक बिट्स - क्यों CSPRNG-जनरेटेड v4 का बलपूर्वक अनुमान नहीं लगाया जा सकता है
यादृच्छिकता जांच आवश्यक है लेकिन पर्याप्त नहीं है। संस्करण 4 चार संस्करण बिट्स और दो वैरिएंट बिट्स को आरक्षित करता है, जब कार्यान्वयन अन्य फ़ील्ड को यादृच्छिक रूप से भरता है तो 128 - 4 - 2 = 122 यादृच्छिक स्थिति छोड़ देता है। वह व्युत्पत्ति समाप्ति, भंडारण या प्राधिकरण के बारे में कुछ नहीं कहती है। जनरेटर जांच पूछती है कि क्या वे फ़ील्ड Math.random या टाइमस्टैम्प के बजाय CSPRNG से आए हैं। ToolAcre उस जनरेटर सीमा को संतुष्ट करता है। डिज़ाइन जांच एप्लिकेशन-विशिष्ट रहती है: रीसेट क्रेडेंशियल के लिए एक अलग जीवनचक्र, एक-तरफ़ा संग्रहीत प्रतिनिधित्व, सफल उपयोग के बाद अमान्यकरण और सेवा की जोखिम नीति से चुनी गई समाप्ति की आवश्यकता होती है। उपयोगकर्ता की स्थायी रिकॉर्ड ID का पुन: उपयोग करने से वह पृथक्करण विफल हो जाता है, भले ही ID सुरक्षित रूप से जेनरेट की गई हो।
जेनरेटर जांच: जहां UUID टोकन वास्तव में विफल होते हैं - Math.random-आधारित पीढ़ी, v1 टाइमस्टैम्प और MAC पते, और पूर्वानुमानित बीज
एक व्यावहारिक उदाहरण: एक पासवर्ड-रीसेट योजना जो विफल हो जाती है, फिर तीन जांचों में सफल हो जाती है। एन्ट्रॉपी जांच विफल हो जाती है: सर्वर Math.random() के माध्यम से एक रीसेट टोकन जारी करता है, जिसे v4 UUID के रूप में पैक किया जाता है। एक हमलावर तीन टोकन देखता है और चौथे की भविष्यवाणी करता है। जनरेटर जांच विफल: सर्वर रीसेट टोकन के रूप में v1 UUID का उपयोग करता है, जिसमें निर्माण टाइमस्टैम्प और मान में MAC पता शामिल होता है। एक हमलावर टाइमस्टैम्प पढ़ता है, सीखता है कि रीसेट कब जारी किया गया था, और खोज विंडो को संकीर्ण कर देता है। एन्ट्रॉपी जांच पास करता है लेकिन डिज़ाइन जांच में विफल रहता है: सर्वर crypto.getRandomValues से v4 UUID का उपयोग करता है, लेकिन इसे डेटाबेस में सादे पाठ में संग्रहीत करता है और समाप्ति निर्धारित नहीं करता है। एक हमलावर जो डेटाबेस का उल्लंघन करता है वह रीसेट टोकन पढ़ता है और हफ्तों बाद खातों को रीसेट करने के लिए उनका उपयोग करता है। तीन चेक स्वतंत्र हैं; तुम्हें तीनों में उत्तीर्ण होना होगा।
डिज़ाइन जांच: पहचानकर्ता बनाम क्रेडेंशियल - एक गुप्त जोड़े के रूप में रिकॉर्ड की प्राथमिक कुंजी का पुन: उपयोग क्यों दो चीजें हैं जिन्हें स्वतंत्र रूप से घूमना चाहिए
एक रीसेट टोकन योजना जो एन्ट्रापी और जनरेटर जांच से गुजरती है लेकिन डिजाइन जांच में विफल रहती है (कोई हैश नहीं, कोई समाप्ति नहीं, कोई प्रति-उपयोग अमान्य नहीं) अभी भी असुरक्षित है। टोकन सर्वर-साइड को संभालना: जब कोई उपयोगकर्ता पासवर्ड रीसेट का अनुरोध करता है, तो crypto.getRandomValues से एक नया यादृच्छिक टोकन (पंक्ति UUID नहीं) उत्पन्न करें। प्रस्तुत मूल्य के बजाय एक-तरफ़ा प्रतिनिधित्व संग्रहीत करें, पॉलिसी-विशिष्ट समाप्ति निर्धारित करें, और सफल उपयोग के बाद रिकॉर्ड को अमान्य कर दें। जब उपयोगकर्ता लिंक पर क्लिक करता है, तो ईमेल द्वारा उपयोगकर्ता को देखें, संग्रहीत हैश प्राप्त करें, दिए गए टोकन की हैश के साथ तुलना करें, समाप्ति की जांच करें, और रीसेट तभी निष्पादित करें जब टोकन वैध हो और अभी तक समाप्त न हुआ हो। टोकन को तुरंत अमान्य कर दें (इसे हटा दें या इसे प्रयुक्त के रूप में चिह्नित करें) ताकि इसका पुन: उपयोग न किया जा सके। कच्चे टोकन को कभी लॉग न करें; केवल उपयोगकर्ता ID और कार्रवाई लॉग करें।
टोकन सर्वर-साइड को संभालना - एक हैश संग्रहीत करें, एक समाप्ति तिथि सेट करें, उपयोग पर अमान्य करें, और कच्चे मूल्य को कभी भी लॉग न करें
टोकन को कभी भी त्रुटि संदेशों में या डेटाबेस में तब तक प्रकट नहीं होना चाहिए जब तक कि उसे हैश न किया गया हो। पूर्ण प्रमाणीकरण डिज़ाइन UUID आलेख के दायरे से परे है, लेकिन सिद्धांत मानते हैं: 122-बिट यादृच्छिक टोकन स्वाभाविक रूप से एक एक्सेस टोकन नहीं है। यादृच्छिकता आसान हिस्सा है; ToolAcre जेनरेटर आपको CSPRNG-समर्थित UUID देता है। कठिन हिस्सा डिज़ाइन है: भंडारण से पहले हैशिंग, समाप्ति समय निर्धारित करना, उपयोग पर अमान्य करना, अस्थायी रहस्यों के रूप में स्थायी ID के पुन: उपयोग को रोकना, ऑडिट करना कि किसने और कब एक्सेस किया। एक सुरक्षा समीक्षक जो अकेले टोकन की एन्ट्रापी के आधार पर रीसेट-लिंक योजना को मंजूरी देता है, बाकी विश्लेषण को छोड़ रहा है। एक डेवलपर जो सोचता है कि CSPRNG-समर्थित UUID हैशिंग, समाप्ति और अमान्यकरण के बिना पासवर्ड रीसेट लिंक के लिए पर्याप्त है, वह खतरे को कम आंक रहा है। यादृच्छिकता अनुमान लगाने से बचाती है; डिज़ाइन रीप्ले, समाप्ति और दुरुपयोग से बचाता है।
कारगर उदाहरण - प्रत्येक चेक के विरुद्ध रीसेट-लिंक योजना की समीक्षा करना और कमजोर हिस्सों को फिर से लिखना
ToolAcre जनरेटर यादृच्छिकता वाले हिस्से को ठीक से करता है; एप्लिकेशन को डिज़ाइन वाला भाग ठीक से करना होगा। तीनों जांचों के विरुद्ध अपने स्वयं के रीसेट-लिंक कोड का परीक्षण करें: क्या यह CSPRNG (crypto.getRandomValues, crypto.randomUUID, या क्रिप्टोग्राफी लाइब्रेरी) का उपयोग करता है, न कि Math.random का? क्या टोकन की कोई समाप्ति तिथि होती है? क्या भंडारण से पहले टोकन को धोया गया है? क्या उपयोग के बाद टोकन अमान्य हो जाता है? क्या कोड उपयोगकर्ता की स्थायी ID को अस्थायी टोकन के रूप में पुन: उपयोग करने से रोकता है? यदि आप इन सभी का उत्तर हाँ में देते हैं, तो आपका रीसेट लिंक डिज़ाइन सही है। ToolAcre जनरेटर CSPRNG भाग है; बाकी एप्लिकेशन कोड है जिसकी आपको सावधानीपूर्वक समीक्षा करनी चाहिए। तीन सुरक्षा परतों को समझने से आपको तृतीय-पक्ष UUID लाइब्रेरी और फ़्रेमवर्क का ऑडिट करने में मदद मिलती है। जब आप किसी लाइब्रेरी का मूल्यांकन करते हैं, तो जांच लें कि यह CSPRNG (एन्ट्रॉपी जांच) का उपयोग करता है, कमजोर यादृच्छिक स्रोत का नहीं। जांचें कि यह दस्तावेज करता है कि यह किन स्रोतों का उपयोग करता है और क्यों (जनरेटर जांच)।
इसमें क्या शामिल नहीं है - पूर्ण प्रमाणीकरण डिज़ाइन, MFA और दर सीमित करना, जो टोकन एन्ट्रापी जितना ही मायने रखता है
जांचें कि उदाहरण कोड और दस्तावेज़ीकरण डिज़ाइन सिद्धांतों पर जोर देते हैं: हैशिंग, समाप्ति, अमान्यकरण (डिज़ाइन जांच)। तीनों जांचों पर खरा उतरने वाले पुस्तकालय दुर्लभ हैं; अकेले एन्ट्रापी पर सबसे अधिक ध्यान केंद्रित करें। ToolAcre जनरेटर crypto.getRandomValues का उपयोग करके एन्ट्रापी और जनरेटर जांच पास करता है। डिज़ाइन की जाँच आपकी ज़िम्मेदारी है; लाइब्रेरी आपकी समाप्ति आवश्यकताओं या हैशिंग रणनीति को नहीं जान सकती। टूटे हुए रीसेट-लिंक सिस्टम को डीबग करने से आमतौर पर तीन विफलताओं में से एक का पता चलता है। यदि उपयोगकर्ता रीसेट लिंक प्राप्त करने की रिपोर्ट करते हैं जो अब काम नहीं करते हैं, तो संभावित समस्या समाप्ति है: टोकन जारी किया गया था लेकिन उपयोगकर्ता द्वारा लिंक पर क्लिक करने से पहले ही समाप्त हो गया। यदि टोकन का कई बार पुन: उपयोग किया जाता है, तो अमान्यकरण टूट जाता है। यदि टोकन त्रुटि संदेशों या डीबग आउटपुट में दिखाई देते हैं, तो लॉगिंग उन्हें लीक कर रही है। यदि रीसेट लिंक एक उपयोगकर्ता के लिए काम करते हैं लेकिन दूसरे के लिए नहीं, तो समाप्ति गणना के साथ डेटाबेस प्रतिकृति अंतराल या टाइमज़ोन समस्याएं हो सकती हैं। यदि वैध रीसेट अनुरोध यादृच्छिक रूप से विफल हो जाते हैं, तो CSPRNG टूट सकता है (दुर्लभ)।
टेकअवे: यादृच्छिकता आसान हिस्सा है - ToolAcre जनरेटर आपको CSPRNG-समर्थित UUID देता है; बाकी डिज़ाइन अनुशासन है
लॉगिंग से प्रारंभ करें: रीसेट-लिंक जनरेशन और सत्यापन के लिए विस्तृत ऑडिट लॉग सक्षम करें, फिर समस्या को पुन: उत्पन्न करें और प्रवाह का पता लगाएं। ToolAcre जनरेटर यह सुनिश्चित करता है कि पहले दो चेक पास हो जाएं; रीसेट-लिंक समस्याओं का निवारण लगभग हमेशा डिज़ाइन कैटेगरी में आता है। उत्पादन रीसेट-लिंक सिस्टम के लिए सर्वोत्तम प्रथाओं में शामिल हैं: प्रत्येक रीसेट अनुरोध के लिए एक नया यादृच्छिक टोकन उत्पन्न करें, पुराने टोकन का पुन: उपयोग न करें। खाते और निर्माण मेटाडेटा के साथ एक-तरफ़ा प्रतिनिधित्व संग्रहीत करें, फिर सेवा की दस्तावेज़ीकृत जोखिम नीति से समाप्ति चुनें। सफल सत्यापन के तुरंत बाद टोकन को अमान्य करें। ऑडिटिंग के लिए लॉग रीसेट अनुरोध और सफलताएँ। क्रूर-बल के हमलों को रोकने के लिए दर-सीमित लागू करें। रीसेट लिंक केवल ईमेल के माध्यम से भेजें, SMS या अनएन्क्रिप्टेड चैनलों के माध्यम से नहीं। उपयोगकर्ता को पासवर्ड-रीसेट प्रयासों के बारे में सूचित करें (ताकि वे अनधिकृत रीसेट का पता लगा सकें)। ToolAcre जनरेटर आपको यादृच्छिकता देता है; इन प्रथाओं का पालन करने से आपको सुरक्षा मिलती है।