डेटाबेस में पासवर्ड स्टोर करने का सबसे अच्छा तरीका [बंद]

Question

मैं एक ऐसे प्रोजेक्ट पर काम कर रहा हूं जिसमें प्रमाणीकरण (उपयोगकर्ता नाम और पासवर्ड) होना चाहिए

यह एक डेटाबेस से भी जुड़ता है, इसलिए मुझे लगा कि मैं उपयोगकर्ता नाम और पासवर्ड को स्टोर करूंगा। हालाँकि, ऐसा लगता है कि डेटाबेस पर बैठे टेबल में सिर्फ टेक्स्ट फ़ील्ड के रूप में पासवर्ड रखना इतना अच्छा विचार नहीं है।

मैं C # का उपयोग कर रहा हूं और 2008 के एक्सप्रेस सर्वर से जुड़ रहा हूं। क्या कोई सुझाव दे सकता है (यथासंभव कई उदाहरणों के साथ) इस प्रकार के डेटा को संग्रहीत करने का सबसे अच्छा तरीका क्या होगा?

पुनश्च मैं इस विचार के लिए खुला हूं कि यह जानकारी डेटाबेस में संग्रहीत नहीं की जाए यदि एक अच्छा कारण प्रदान किया जा सकता है

Comments

आप जो कुछ भी करते हैं, यदि आप एन्क्रिप्शन के साथ जाते हैं, तो कोड में कुंजी को पिछले पोस्टर के रूप में संग्रहीत न करें। यह सिर्फ गरीबों का अभ्यास है।

— वुडी

'पासवर्ड सही कैसे करें?' एक महत्वपूर्ण सवाल है। यह एक कठिन समस्या है और गलतियों के गंभीर परिणाम हैं (याद करें कि टेस्को और लिंक्डइन का क्या हुआ)। मुझे लगता है कि इस सवाल को programmers.stackexchange.com

— कर्नल दहशत

मानकों पर

— टिके

इस प्रश्न का सुरक्षा फोरम में बड़े पैमाने पर उत्तर दिया गया है: security.stackexchange.com/questions/211/…

— gioele

Answer 1

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

इसलिए, जबकि यह एक अच्छी बात है जो आप इस बारे में सोच रहे हैं और यह एक अच्छा सवाल है, यह वास्तव में इन सवालों की नकल है (कम से कम:

• उपयोगकर्ता जानकारी और उपयोगकर्ता लॉगिन और पासवर्ड को कैसे स्टोर करें
• डेटाबेस पासवर्ड संग्रहीत करने के लिए सर्वोत्तम अभ्यास
• आपका पासवर्ड सलाम करना: सर्वश्रेष्ठ अभ्यास?
• क्या php वैरिएबल या php स्थिरांक में सादे पाठ में पासवर्ड स्टोर करना कभी ठीक है?

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

Comments

मेरा मतलब था कि डेटाबेस में पासवर्ड को रखने के रूप में इसे कहीं और संग्रहीत करने का विरोध करना। उस वाक्य को संदर्भ से बाहर ले जाने से ऐसा लगता है जैसे मैं सादे पासवर्ड का समर्थन कर रहा हूं, यदि आप बाकी को पढ़ते हैं तो मैं स्पष्ट रूप से नहीं करता हूं।

— पाओलो बरगीनो

न केवल यह कि मैंने जो कहा, मैंने उसे लवणों और ऐसी चर्चा करने वाले पदों के ढेरों के लिए निर्देशित किया ...

— पाओलो बरगिनिनो

@Paolo Bergantino: आपको यकीन है कि आपकी पोस्ट में कोई टाइपो नहीं है? इसमें कहा गया है, "अधिकांश मामलों के लिए जिनका आप सामना कर रहे हैं (और मैं ईमानदारी से किसी भी काउंटर-उदाहरण के बारे में नहीं सोच सकता) डेटाबेस में पासवर्ड को स्टोर करना उचित काम है।" ??? यह आपकी टिप्पणियों के विपरीत लगता है

— मिच गेहूं

क्या कहा पाओलो ने सीधे ही विरोधाभासी बातें कही। पासवर्ड का नमकीन हैश पासवर्ड नहीं है। डेटाबेस में पासवर्ड का नमकीन हैश स्टोर करने से डेटाबेस में पासवर्ड स्टोर नहीं हो रहा है। जवाब का शरीर पूरी तरह से उपयुक्त है, लेकिन इसका पहला वाक्य बेहद भ्रामक है।

— रॉबर्ट रोसनी

@ रॉबर्ट: यह खतरनाक रूप से एक क्षुद्र शब्दार्थ खेल के करीब हो रहा है, लेकिन मैं इसे फिर भी ठीक कर लूंगा ...

— पाओलो बर्गेंटिनो

Answer 2

पृष्ठभूमि आप कभी नहीं ... वास्तव में ... उपयोगकर्ता के पासवर्ड को जानने की आवश्यकता है। आप बस एक आने वाले उपयोगकर्ता को सत्यापित करना चाहते हैं कि किसी खाते के लिए पासवर्ड पता है।

हैश इट: स्टोर यूजर पासवर्ड हैश (वन-वे एन्क्रिप्शन) एक मजबूत हैश फ़ंक्शन के माध्यम से। "सी # एन्क्रिप्ट पासवर्ड" की खोज उदाहरणों का एक भार देती है।

एक हैश फ़ंक्शन क्या उत्पन्न करता है (लेकिन एक SHH1 के रूप में SHA1 का उपयोग न करें, SHA256 जैसे कुछ मजबूत का उपयोग करें) के विचार के लिए ऑनलाइन SHA1 हैश निर्माता देखें ।

अब, एक हैशेड पासवर्ड का अर्थ है कि आप (और डेटाबेस चोर) उस हैश को मूल पासवर्ड में वापस करने में सक्षम नहीं होना चाहिए।

इसका उपयोग कैसे करें: लेकिन, आप कहते हैं, मैं डेटाबेस में संग्रहीत इस मैस्ड अप पासवर्ड का उपयोग कैसे करूं?

जब उपयोगकर्ता लॉग इन करता है, तो वे आपको उपयोगकर्ता नाम और पासवर्ड (इसके मूल पाठ में) सौंप देंगे। आप संग्रहीत संस्करण को प्राप्त करने के लिए उसी हैश कोड का उपयोग उस हैश टाइप पासवर्ड में करते हैं।

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

अतिरिक्त श्रेय:

प्रश्न: अगर मेरे पास आपका डेटाबेस होता, तो क्या मैं सिर्फ जॉन द रिपर की तरह पटाखा नहीं ले सकता था और जब तक मैं आपके संग्रहीत, हैशेड पासवर्ड से मेल नहीं खाता तब तक हैश बनाना शुरू कर देता? (चूँकि उपयोगकर्ता कम-से-कम शब्द चुनते हैं, इसलिए ... यह आसान होना चाहिए)

उत्तर: हां ... हां वे कर सकते हैं।

तो, आपको अपने पासवर्ड को 'नमक' करना चाहिए। नमक पर विकिपीडिया लेख देखें

देखें "कैसे नमक के साथ हैश आंकड़ों के" सी # उदाहरण

Comments

अच्छी पोस्ट, एक बात को छोड़कर: md5 और sha1 दोनों को तोड़ा जा चुका है। आपको शायद एक मजबूत एल्गोरिथ्म के साथ जाना चाहिए, जैसे कि शायद SHA2 परिवार।

— पाओलो बरगीनो

धन्यवाद पाओलो - आप सही हैं। चूंकि SHA2 का उपयोग MD5 और SHA1 का उपयोग करना जितना आसान है, कृपया मजबूत हैश एल्गोरिथ्म का उपयोग करें।

— जोज

SHA-1 को तोड़ा नहीं गया है। लेकिन ब्रूस श्नाइयर को पैराफेज करने के लिए: वॉक, एसएचए -2 तक न चलाएं।

— इयान बॉयड

"तो, आपको अपने पासवर्ड को नमक करना चाहिए" ... लेकिन नमक आमतौर पर पासवर्ड के साथ डेटाबेस में संग्रहीत किया जाता है, तो यह कैसे मदद करता है? ते हमलावर को केवल उस शब्द हमले के वाक्यांशों में नमक जोड़ना होगा जो वह परीक्षण कर रहा है। यह कैसे अधिक सुरक्षित है इसके अलावा अन्य डुप्लिकेट पासवर्ड प्रकट नहीं करेंगे?

— 21

@joej "आप कभी नहीं ... वास्तव में ... उपयोगकर्ता के पासवर्ड को जानने की आवश्यकता है" - यह एक बहुत ही कम देखी गई धारणा है। कई तरह के एप्लिकेशन हैं जहां एक पासवर्ड को इस तरह से संग्रहित किया जा सकता है जिसे पुनर्प्राप्त किया जा सकता है। उदाहरण के लिए, एक ऐसा एप्लिकेशन जिसे उपयोगकर्ता द्वारा संग्रहीत और अपडेट किए गए संग्रहित क्रेडेंशियल्स के साथ अक्सर किसी अन्य सिस्टम में लॉगिन करना पड़ता है।

— फ्रांसिस्को ज़ाराबोज़ो

Answer 3

एक कुंजी-कठोर नमकीन हैश के रूप में, एक सुरक्षित एल्गोरिथ्म जैसे कि श-512 का उपयोग करके।

Comments

मेरी राय में, आपको पासवर्ड स्टोर करने के लिए हमेशा धीमी एल्गोरिदम (जैसे ब्लोफिश, उदाहरण के लिए) का उपयोग करना चाहिए। : इस writeup एक बेहतर जवाब है security.stackexchange.com/questions/211/... । बस इसे यहां डाल रहा है, क्योंकि यह पृष्ठ अभी भी खोज परिणामों में उच्च दिखाई देता है।

— डायनाम

पासवर्ड भंडारण के लिए इस सलाह का पालन करना गलत तरीके से गलत होगा।

— एमएलसनेर

Answer 4

सबसे अच्छा सुरक्षा अभ्यास पासवर्ड को बिल्कुल भी संग्रहीत नहीं करना है (एन्क्रिप्टेड भी नहीं है), लेकिन एन्क्रिप्ट किए गए पासवर्ड के नमकीन हैश (एक अद्वितीय नमक प्रति पासवर्ड के साथ) को संग्रहीत करना है।

इस तरह यह एक सादा पासवर्ड प्राप्त करने के लिए (व्यावहारिक रूप से) असंभव है।

Comments

वेन, हैश की गणना करने से पहले नमकीन करके, इंद्रधनुष तालिका को प्रभावी रूप से पराजित किया जाता है, बशर्ते कि नमक पर्याप्त आकार का हो।

— माइक रोसेनब्लम

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

— इयान बॉयड

Answer 5

मैं पूरी तरह से इंद्रधनुष टेबल्स के साथ पर्याप्त लेख पढ़ने की सलाह दूंगा: सुरक्षित पासवर्ड योजनाओं के बारे में आपको क्या जानने की जरूरत है [मृत लिंक, इंटरनेट आर्काइव पर कॉपी ] और कैसे सुरक्षित रूप से एक पासवर्ड स्टोर करें ।

खुद को शामिल करने वाले बहुत सारे कोडर सोचते हैं कि वे सुरक्षा और हैशिंग को समझते हैं। अफसोस की बात है कि हम में से ज्यादातर बस नहीं है।

Comments

@ जोहान लगता है अब लिंक टूट गया है जो एक शर्म की बात है। यहाँ एक वैकल्पिक codahale.com/how-to-safely-store-a-password

— zebrabox

Answer 6

जैसा कि आपने उपयोगकर्ता नाम और पासवर्ड की आवश्यकता का उल्लेख किया है, मैं थोड़ा हटकर हो सकता हूं और इस मुद्दे की मेरी समझ सबसे अच्छी नहीं है, लेकिन ओपनआईडी कुछ विचार करने लायक है?

यदि आप OpenID का उपयोग करते हैं, तो आप किसी भी क्रेडेंशियल को संग्रहीत करना समाप्त नहीं करते हैं यदि मैं तकनीक को सही ढंग से समझता हूं और उपयोगकर्ता आपके पास विशिष्ट पहचान बनाने के लिए क्रेडेंशियल का उपयोग कर सकते हैं, जो एक नई पहचान बनाने की आवश्यकता से बचने के लिए है।

यह उपयुक्त नहीं हो सकता है यदि प्रश्न में आवेदन पूरी तरह से आंतरिक उपयोग के लिए है

RPX किसी एप्लिकेशन में OpenID समर्थन को इंटरग्रेट करने का एक अच्छा आसान तरीका प्रदान करता है।

Comments

मैं मानता हूं कि ओपनआईडी चट्टानें लोगों का सामना करती हैं, लेकिन इस एप्लिकेशन के लिए यह एक कंपनी के लिए एक घर डेटाबेस में है मुझे संदेह है कि वे किसी भी पुराने व्यक्ति को लॉग ऑन करने के लिए आ रहे हैं। इस ऐप को सही ढंग से काम करने के लिए वेब एक्सेस की भी आवश्यकता नहीं है, इसलिए मुझे इसकी आवश्यकता होगी।

— क्रैश89 3

Answer 7

आपके परिदृश्य में, आप asp.net सदस्यता पर एक नज़र डाल सकते हैं, डेटाबेस में उपयोगकर्ता के पासवर्ड को हैशेड स्ट्रिंग के रूप में संग्रहीत करना अच्छा है। आप डेटाबेस में संग्रहीत एक के साथ हैशेड इनकमिंग पासवर्ड की तुलना करके उपयोगकर्ता को प्रमाणित कर सकते हैं।

सब कुछ इस उद्देश्य के लिए बनाया गया है, asp.net सदस्यता की जाँच करें

Answer 8

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

Comments

मैं हैशिंग के लिए MD5 का उपयोग नहीं करूंगा - यह मूल रूप से टूट गया है mscs.dal.ca/~selinger/md5collision

— zebrabox

दरअसल, यह टूटा नहीं है। वे जो कर सकते हैं वह दो अलग-अलग फ़ाइलों के लिए समान हैश मान पा रहा है। वे क्या नहीं कर सकते MD5 रिवर्स और एक काम कर रहे पासवर्ड मिलता है।

— waiwai933

खैर, तब भी नहीं तोड़ा जाएगा? आप बस एक ही हैश उत्पन्न करने वाला दूसरा पासवर्ड दर्ज करते हैं, और आप अंदर हैं। आपको मूल पासवर्ड जानने की आवश्यकता नहीं है। इसे ठीक करने का तरीका है यदि आप हैशिंग से पहले पासवर्ड नमक करते हैं।

— मुजरेज

@ mjuarez यदि आप पासवर्ड के लिए एक नमक जोड़ते हैं तो आप एमडी 5 का उपयोग करें टकराव कोई मायने नहीं रखता है क्योंकि आप दूसरे पासवर्ड का उपयोग नहीं कर सकते हैं

— WiiMaxx