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




passwords username (2)

कैसा रहेगा:

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

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

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

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

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

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

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

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

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

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

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

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





salt