डिक्रिप्टेबल पासवर्ड स्टोर करने का सुरक्षित तरीका

Question

मैं PHP में एक एप्लिकेशन बना रहा हूं और एक आवश्यकता है कि उपयोगकर्ता को विभिन्न सिस्टम में स्विच करने के साथ भविष्य में समस्याओं से बचने के लिए पासवर्ड को डिक्रिप्ट करना संभव हो। इस बात पर विचार करें कि इस भविष्य की सिस्टम की पासवर्ड विधि को संशोधित करना संभव नहीं है और मुझे पासवर्ड उत्पन्न करने के लिए सादे पाठ पासवर्ड की आवश्यकता है।

योजना उपयोगकर्ता के पासवर्ड को सर्वर पर संग्रहीत सार्वजनिक कुंजी के साथ एन्क्रिप्ट करना है। इनपुट एन्क्रिप्ट करके और परिणामों की तुलना करके प्रमाणीकरण किया जाता है। कोई डिक्रिप्शन नहीं किया गया है। डिक्रिप्शन करने में सक्षम निजी कुंजी बाद के उपयोग के लिए ऑफ-साइट संग्रहीत की जाती है।

आप क्या एन्क्रिप्शन/डिक्रिप्शन एल्गोरिथ्म सुझाव है? क्या एन्क्रिप्टेड पासवर्ड अभी भी हैशिंग (MD5/SHA1) के रूप में सुरक्षित हैं जब आप मानते हैं कि निजी कुंजी हमलावर के लिए उपलब्ध नहीं है?

Answer 1

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

Answer 2

सबसे अनुप्रयोगों के लिए यह पासवर्ड का SHA-1 हैश स्टोर करने के लिए पर्याप्त से अधिक है।

हां, अधिकांश हैशिंग एल्गोरिदम में ज्ञात टकराव हैं, लेकिन यह वास्तविक हमले वेक्टर का अर्थ नहीं है। विशेष रूप से जब आप हैश को सलाम कर रहे हैं।

अपने नमक के लिए: इसे एक कॉन्फ़िगरेशन फ़ाइल में संग्रहीत करें जो बाहर से उपलब्ध नहीं है लेकिन आपके PHP स्थापना द्वारा पढ़ा जा सकता है।

Answer 3

पासवर्ड डिक्रिप्ट न करें। यदि आपको भविष्य में पासवर्ड सिस्टम को बदलने की ज़रूरत है, तो storage_type (या जो कुछ भी) नामक फ़ील्ड जोड़ें।

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

Answer 4

मैं जैमर का दृष्टिकोण अलग तरीके से व्यक्त करता हूँ -

1. एक सार्वजनिक/निजी कुंजी युग्म उत्पन्न करें। अपने वेबसर्वर पर सार्वजनिक कुंजी हार्ड कोड। वेबसर्वर/डेटाबेस/किसी भी डेवलपर की पहुंच के बाहर, निजी कुंजी को भौतिक बैंक लॉकर में स्टोर करें।
2. जब उपयोगकर्ता रजिस्टरों, एन्क्रिप्ट पासवर्ड + नमक सार्वजनिक कुंजी का उपयोग कर। यह चरण हैश एल्गोरिदम का उपयोग करने के समान है। डेटाबेस में एन्क्रिप्टेड पासवर्ड + नमक स्टोर करें।
3. आप पासवर्ड सत्यापित इसे फिर से एन्क्रिप्ट, और डेटाबेस में संग्रहीत मूल्य की तुलना करना चाहते हैं।

एक हमलावर डेटाबेस हो जाता है, वह पासवर्ड डीक्रिप्ट नहीं कर सकते क्योंकि वह निजी कुंजी नहीं है। उन्हें निजी कुंजी नहीं मिल सकती क्योंकि यह उनकी पहुंच के बाहर एक बैंक वॉल्ट में है। नमक की वजह से डेटाबेस में दो समान पासवर्ड अभी भी अलग-अलग संग्रहीत किए जाएंगे।

मैं उपर्युक्त दृष्टिकोण का उपयोग करने की अनुशंसा नहीं करता क्योंकि भविष्य में किसी भी समय कोई व्यक्ति निजी कुंजी का दुरुपयोग कर सकता है और सभी पासवर्ड तक पहुंच प्राप्त कर सकता है।

लेकिन अगर आप गारंटी देते हैं कि निजी कुंजी हमेशा निजी रहेगी, तो मैं एक तकनीकी दोष नहीं दिख रहा।

मैं निश्चित रूप से गलत, हो सकता है।

Answer 5

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

आप सार्वजनिक कुंजी का उपयोग करने के लिए सीधे पासवर्ड + नमक एन्क्रिप्ट करना चाहते हैं।

1. सामान्य सार्वजनिक/निजी कुंजी एन्क्रिप्शन अपनी निजी कुंजी की दुकान के खिलाफ
2. हमलों के खिलाफ हमलों:

   तो आपके सिस्टम के खिलाफ हमलों के लिए नीचे उबाल।