सुरक्षित पासवर्ड इतिहास कैसे लागू करें

Question

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

हालाँकि, आमतौर पर आपको अंतिम एन पासवर्ड को स्टोर करने और विभिन्न पासवर्डों के बीच न्यूनतम जटिलता और न्यूनतम परिवर्तन को लागू करने की आवश्यकता होती है (उपयोगकर्ता को पासवर्ड अनुक्रम, पासवर्ड, ..., पासवर्ड_ एन जैसे अनुक्रम का उपयोग करने से रोकने के लिए )। यह सादे पाठ पासवर्ड के साथ तुच्छ होगा, लेकिन आप केवल हैश का भंडारण करके ऐसा कैसे कर सकते हैं?

दूसरे शब्दों में: सुरक्षित पासवर्ड इतिहास तंत्र को लागू करना कैसे संभव है?

Comments

संबंधित: Security.stackexchange.com/questions/4704/… (और BTW कि साइट इस प्रश्न के लिए बेहतर स्थान हो सकती है)। जहाँ तक 'न्यूनतम परिवर्तन' का है, मैं उन सभी विकल्पों को उत्पन्न करने के लिए किसी भी विकल्प के बारे में नहीं सोच सकता हूँ जो 'न्यूनतम परिवर्तन' के रूप में योग्य होंगे (जो आपकी परिभाषा के आधार पर बहुत कुछ हो सकता है!) और हैश की तुलना करते हुए। 'न्यूनतम परिवर्तन' की परिभाषा क्या है?

— केविन वर्मेयर

नवीनतम एन पासवर्ड को संग्रहीत करने का मतलब केवल यह है कि उपयोगकर्ता 1 से n + 1 तक चलने वाले अनुक्रम का चयन करेगा ।

— जोकिम सॉउर

मुझे बहुत संदेह है कि इस तरह की पासवर्ड नीति सुरक्षा में सुधार करती है; IMHO, यह संभावना बढ़ाता है कि लोग अपने पासवर्ड को एक चिपचिपा नोट पर रखने का सहारा लेंगे। केविन की कड़ी एक अच्छी चर्चा है। @ केविनवर्मियर - आप वास्तव में लेवेंसहाइट दूरी ( en.wikipedia.org/wiki/Levenshtein_distance ) के रूप में परिवर्तन की मात्रा को माप सकते हैं , जिसे "एडिट दूरी" के रूप में भी जाना जाता है।

— नाथन लॉन्ग

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

— रिएक्टगुलर

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

— मटनज़

Answer 1

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

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

Comments

इसलिए, यदि उपयोगकर्ता पासवर्ड 6 में प्रवेश करता है, तो मुझे संख्यात्मक भाग का पता लगाना चाहिए, और उदाहरण के लिए पासवर्ड 4 , पासवर्ड 5 , पासवर्ड 7 और इसी तरह का प्रयास करना चाहिए । क्या वो सही है?

— जादूगर

@ लोरेंजो: सही। विकल्प उत्पन्न करना उतना ही जटिल हो सकता है जितना आप इसे चाहते हैं, बस यह सुनिश्चित करें कि आप जटिलता और जोखिम के बीच सही ट्रेडऑफ़ पाते हैं (जोखिम को गायब होने की संभावना के साथ सभी संभावनाओं की जांच करते समय अपने उपयोगकर्ताओं को 5 मिनट प्रतीक्षा न करें)।

— मार्टीजन पीटरर्स

मुझे यकीन नहीं है कि अंत में संख्या को गुप्त रखने का सुझाव उपयोगकर्ताओं के लिए एक अच्छा सुझाव है - यह केवल थोड़ा सा पूर्वानुमान है। और तेजी से और अधिक हो जाता है अगर आप उपयोगकर्ताओं को ऐसा करने के लिए कह रहे हैं।

— वायट बार्नेट

@YattBarnett: कोई भी उपयोगकर्ताओं को ऐसा करने के लिए कह रहा है। मुद्दा यह है कि ऐसा करने वाले उपयोगकर्ताओं का पता लगाया जाए और 'बढ़े हुए' पासवर्ड को इस्तेमाल होने से रोका जाए।

— मार्टिज़न पीटर्स

आह, पूरी तरह से यहाँ कुछ गलत है। माफ़ कीजिये।

— वायट बार्नेट

Answer 2

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

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

Comments

वैसे यह निश्चित रूप से एक चतुर समाधान है यदि आपको एन पिछले पासवर्ड के खिलाफ परीक्षण की आवश्यकता नहीं है , हालांकि समय में सिर्फ विकल्प उत्पन्न करने का सुझाव बेहतर है। लेकिन दोनों पासवर्ड के विकल्प उत्पन्न करना और भी बेहतर है!

— जादूगर

@ लॉरेंज़ो: विचार यह है कि आप एन पिछले पासवर्ड के खिलाफ एक सीधा परीक्षण करते हैं और पिछले पासवर्ड के खिलाफ एक मजबूत परीक्षण करते हैं। यह एक समझौता है।

— ब्रायन

हाँ। यदि उनका वर्तमान पासवर्ड है potatoSalad1और वे अपडेट करना चाहते हैं potatoSalad2, तो आप बताएं कि परिवर्तन बहुत छोटा है क्योंकि आपके पास उस समय दोनों सादे पाठ पासवर्ड हैं। लेकिन इससे भी आगे, आपके पास केवल हैश है, और हैश की प्रकृति यह है कि आप यह नहीं बता सकते हैं कि दो हैश में इनपुट के रूप में समान या पूरी तरह से अलग पाठ है।

— नाथन लॉन्ग

Answer 3

@ martijnPieter के उत्तर को जोड़ने के लिए नए और पिछले पासवर्ड (जो आप दोनों के पास उपलब्ध है) के आधार पर एक संक्षिप्त जानवर बल द्वारा न्यूनतम परिवर्तन लागू किया जा सकता है

उदाहरण के लिए, आप नए पासवर्ड से 1 या 2 की दूरी के साथ सभी पासवर्डों पर पुनरावृति कर सकते हैं और देख सकते हैं कि यह पुराने पास से मेल खाता है या नहीं

लेकिन आप यह नोट करना चाहते हैं कि इससे उपयोगकर्ताओं का विश्वास कम हो सकता है कि आप हैशिंग पासवर्ड हैं (जैसा कि आप अनिवार्य रूप से कह रहे हैं कि आप एक नया पासवर्ड अस्वीकार करने के लिए पिछला पासवर्ड प्राप्त कर सकते हैं)

Comments

लेकिन बड़े हैमिंग दूरियों के साथ कई क्रम हैं जैसे कि फरवरी २०१२ -> मार्च २०१२ या शुक्र-९ -२-12-१२-१२-> Tue-११-२ T-१२ (तारीखें), Password_Alpha -> Password_Beta, Pass_1111 - Pass_2222, Pass_qwer, Pass_tyui, पास पास, _op [], या ग्यारह -> बारह (वैकल्पिक गिनती प्रणाली), या फ्रैंकस्मिथ -> फ्रेडजोन -> फ्रिटकॉक या क्रोध -> जानवर -> सेब (एक कंपनी निर्देशिका में नाम या एक शब्दकोष में शब्द) जो एक हमलावर के साथ पिछला पासवर्ड आसानी से अनुमान लगा सकता है, लेकिन आपके एल्गोरिथ्म को बनाने का एक अत्यंत कठिन समय होगा।

— केविन वर्मेयर

@KevinVermeer तब आपके लिए वैरिएशन जनरेटर में खाता है, और स्वीकार करते हैं कि आपको कभी भी सब कुछ नहीं मिलेगा

— शाफ़्ट फ्रीक

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

— टिम पोस्ट

Answer 4

यह वास्तव में @ ब्रायन के चतुर उत्तर के परिशिष्ट से अधिक है। @Martijn पीटर को भी सलाम करता है कि कैसे मौजूदा पासवर्ड के आधार पर पुराने पासवर्डों को भंग करने के लिए और "हैटिंग दूरी" के लिए @ratchet फ्रीक को मजबूर करें। मैं अपना उत्तर नहीं हटा रहा हूं क्योंकि मुझे लगता है कि यह उन्हें वापस करने के लिए दिलचस्प पृष्ठभूमि प्रदान करता है।

स्टेट ऑफ़ द आर्ट पासवर्ड स्टोरेज के लिए प्रत्येक उपयोगकर्ता के लिए अद्वितीय नमक (128-बिट +) के साथ एक मजबूत वन-वे क्रिप्टोग्राफ़िक हैश (SHA-512 +) के कई राउंड का उपयोग करने की आवश्यकता होती है। लेकिन प्रत्येक पासवर्ड के बारे में अतिरिक्त जानकारी संग्रहीत करने के लिए परीक्षा न करें। जितनी अधिक जानकारी आप प्रत्येक पासवर्ड के बारे में संग्रहीत करेंगे, उतना ही आप अपने हैशिंग एल्गोरिथ्म की सुरक्षा को कम कर देंगे।

उदाहरण

गौर करें कि अगर आपको पता है कि पासवर्ड को रोकना कितना आसान है?

• यह 7 अक्षर लंबा है
• अक्षर 3-5 अपर केस (4 कम है)
• 1 और 7 नंबर हैं
• 6 का प्रतीक है

एक यूएस कीबोर्ड में 95 प्रिंट करने योग्य वर्ण होते हैं, इसलिए यह जानते हुए कि पासवर्ड 7 वर्ण लंबी पैदावार है 95 ^ 7 = 69,833,729,610,000 = 7x10 ^ 13 क्रमपरिवर्तन। यदि यह वास्तव में यादृच्छिक था, तो इसे एक सिंगल 3Ghz प्रोसेसर पर क्रैक करने में एक साल लग सकता है। परंतु:

• केवल 26 अपर-केस और 26 लोअर-केस पात्र हैं
• उन दो नंबरों के लिए केवल 100 अंक देने वाले 10 अंक हैं
• केवल 32 प्रतीक हैं

तो (@Hellion के लिए सही धन्यवाद):

         26^4 (charcters 2-5 are known upper or lower-case)
        x 100 (characters 1 & 7 are digits)
        x  32 (character 6 is a symbol)
         ====
1,462,323,200 possible passwords.

यह दरार करने के लिए 50,000 गुना आसान है! इस मामले में समान पासवर्ड को रोकने के लिए अच्छी जानकारी संग्रहीत करने से आपके क्रैक का समय 7-वर्ण के पासवर्ड के लिए एक वर्ष से नीचे कुछ घंटों तक हो गया है। एक अच्छा वीडियो कार्ड और थोड़े धैर्य के साथ एक शक्तिशाली मल्टी-प्रोसेसर डेस्कटॉप पर अपने सभी पासवर्ड को डिकोड करना अब बहुत संभव है। मुझे उम्मीद है कि यह सरल उदाहरण प्रदर्शित करता है कि आप जितने सार्थक तरीके से समान पासवर्डों की तुलना कर सकते हैं, उतना ही आपके हैशिंग कम सुरक्षित होंगे।

मजबूत हाशिंग का महत्व

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

समापन विचार

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

Comments

माइनर नाइट: पासवर्ड संभावनाएं अभी भी कई गुना अधिक हैं, इसलिए यह (26 ^ 4) * 100 * 32 = 1,462,323,200 है। यदि हम मानते हैं कि क्रैकिंग (95 ^ 7) की संभावनाओं में एक वर्ष लगता है, तो इस छोटी संख्या की संभावनाओं को क्रैक करने में लगभग 11 मिनट लगेंगे।

— नक्षत्र २

@ हेलियन - उफ़! यह बात बताने के लिए धन्यवाद। मैंने इसे सुधारा है।

— ग्लेनपेटर्सन

Answer 5

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

यदि (आपके लिए) इन दो पासवर्डों की सीधे "n" पिछले पासवर्डों से तुलना करना बहुत महत्वपूर्ण है, तो आपको इन पासवर्डों को संग्रहीत करना होगा (एन्क्रिप्ट किया गया) बाद में उन्हें पुनः प्राप्त करने में सक्षम होना चाहिए।

हालांकि इसे ऐसा करने के लिए सुरक्षा दोष के रूप में देखा जा सकता है, लेकिन पर्याप्त सुरक्षा प्रदान करने के लिए एन्क्रिप्शन विधियों को लागू किया जा सकता है।

1. अंतिम "n" पासवर्ड के लिए प्रत्येक पासवर्ड (एन्क्रिप्टेड) ​​को स्टोर करें।
2. उस दिनांक और समय को संग्रहीत करें जो सबसे हालिया पासवर्ड बनाया गया था।
3. सबसे हाल के पासवर्ड के हैश को स्टोर करें।
4. वर्तमान पासवर्ड के हैश (नमकीन), और पासवर्ड निर्माण टाइमस्टैम्प का उपयोग करके सभी पासवर्डों को एन्क्रिप्ट करें, और शायद एक खाता संख्या या ईमेल पते जैसा कुछ।
5. हर बार एक नया पासवर्ड बनाए जाने पर सभी पासवर्डों को अन-इनक्रिप्ट और री-एन्क्रिप्ट करें।

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

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

इसके अलावा, पुराने पासवर्ड के लिए, उन्हें कड़ाई से सादे पाठ में संग्रहीत नहीं करना पड़ सकता है। उन्हें कुछ मोटे तरीके से संग्रहीत किया जा सकता है। या पासवर्ड में वर्णों की एक वर्णमाला सूची के रूप में संग्रहीत।

मैं यह नहीं कह रहा हूं कि यह सामान्य मामले में करने के लिए एक अनुशंसित चीज है, लेकिन आपके द्वारा वर्णित कार्य को आपके मामले में आवश्यक है, तो यह कुछ सुरक्षा उपायों के साथ इसे पूरा करने का एक तरीका है।

Comments

यह जवाब सुरक्षा के लिहाज से कई भयानक सुझाव देता है। हमें पासवर्डों को आसानी से डिक्रिप्ट करने में सक्षम नहीं होना चाहिए, न ही उन्हें दृढ़ता से एन्क्रिप्ट करने के बजाय "कुछ अस्पष्ट तरीके से" स्टोर करना चाहिए।

— user45623