hash नमक और हैशिंग, उपयोगकर्ता नाम का उपयोग क्यों नहीं करते?




passwords username (3)

मुझे वेब अनुप्रयोगों के लिए प्रासंगिक उच्चतर तकनीकी सुरक्षा मुद्दों पर काफी हद तक अज्ञानी होने के लिए कबूल करना चाहिए, लेकिन एक बात यह है कि मुझे कम से कम सोचा था कि मैं पूछ सकता हूं क्योंकि यह एक ठोस उत्तर (उम्मीद है) के साथ एक सीधा सवाल है।

इस वेबसाइट को लें: http://www.15seconds.com/issue/000217.htm

यह थोड़ा सा दिखाता है कि वे मेज में नमक मूल्य को स्टोर करते हैं, मैं नमक का उपयोग करने के पीछे सिद्धांतों और गणित को समझता हूं, लेकिन मैं यह सोच रहा हूं:

  • उन्होंने एक उत्पन्न करने के बजाय उपयोगकर्ता नाम को नमक मूल्य के रूप में क्यों नहीं उपयोग किया?

नमक का बिंदु अद्वितीय होना है। नमक हमले की लागत साझा करने से रोकने के लिए है, यानी एक हमलावर एक पर हमला करने की लागत से दोगुनी से कम के लिए दो हैश किए गए पासवर्ड पर हमला करने की कोशिश कर रहा है।

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

उपयोगकर्ता का नाम पर्याप्त रूप से अद्वितीय नहीं है:

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

नमक एन्ट्रॉपी वास्तव में महत्वपूर्ण नहीं है, सिवाय इसके कि यह एक यादृच्छिक पीढ़ी सेटिंग में विशिष्टता सुनिश्चित करता है।


कैसा रहेगा:

Salt = CryptoHash( CryptoHash(SubmittedEmailOrUsername) . CryptoHash(SubmittedPasswd) ) ?

ऐसा प्रतीत होता है

  1. नमक को स्टोर करने की आवश्यकता नहीं है क्योंकि इसका गतिशील रूप से गणना की जा सकती है,
  2. जबकि अभी भी अच्छी एंट्रॉपी है (सादे टेक्स्ट के बजाय हैश-आधारित), और

  3. एक नमक प्रदान करता है जो एक क्रिप्टोग्राफिक हैश जैसे 128-512 बिट्स है?

एक समस्या यह होगी कि अगर सिस्टम ने दो उपयोगकर्ता को उपयोगकर्ता नाम और पासवर्ड (हालांकि ईमेल एडीआर के साथ नहीं होगा) की अनुमति दी है, लेकिन क्या इस योजना के साथ कोई अन्य समस्या है?


चूंकि उपयोगकर्ता नामों में यादृच्छिक नमक की तुलना में कम एन्ट्रॉपी होती है, इसलिए वे आपके नमक को उचित नमक से कम फैलते हैं।

ऐसा नहीं है कि उस पृष्ठ पर उदाहरण वैसे भी शानदार है। मैं हमेशा एक GUID उत्पन्न करता हूं और इसका उपयोग करता हूं।

मुझे संदेह है कि शोर में यह सब नीचे है, जहां तक ​​वास्तविक जीवन सुरक्षा चिंता का विषय है, और यहां तक ​​कि प्रति उपयोगकर्ता नमक की थोड़ी सी मात्रा भी सुरक्षा में एक बड़ा अंतर बनाती है, क्योंकि नमक बहुत जटिल हो जाता है।







salt