SHA1 बनाम md5 बनाम SHA256: जो PHP लॉगिन के लिए उपयोग करना है?


133

मैं एक php लॉगिन बना रहा हूं, और मैं यह तय करने की कोशिश कर रहा हूं कि SHA1 या Md5, या SHA256 का उपयोग करना है या नहीं, जिसे मैं एक अन्य स्टैकओवरफ्लो लेख में पढ़ता हूं। क्या उनमें से कोई भी अन्य की तुलना में अधिक सुरक्षित हैं? SHA1 / 256 के लिए, क्या मैं अभी भी एक नमक का उपयोग करता हूं?

इसके अलावा, क्या यह पासवर्ड को mysql में हैश के रूप में संग्रहीत करने का एक सुरक्षित तरीका है?

function createSalt()
{
    $string = md5(uniqid(rand(), true));
    return substr($string, 0, 3);
}

$salt = createSalt();

$hash = sha1($salt . $hash);


इस उत्तर को भी देखें और पासवर्ड हैशिंग के बारे में अनुभाग पढ़ें।
जौक

जवाबों:


110

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

PHP 5.5+ में bcrypt का उपयोग करना

PHP 5.5 पासवर्ड हैशिंग के लिए नए कार्य प्रदान करता है । यह आधुनिक वेब अनुप्रयोगों में पासवर्ड भंडारण के लिए सिफारिश दृष्टिकोण है।

// Creating a hash
$hash = password_hash($password, PASSWORD_DEFAULT, ['cost' => 12]);
// If you omit the ['cost' => 12] part, it will default to 10

// Verifying the password against the stored hash  
if (password_verify($password, $hash)) {
    // Success! Log the user in here.
}

यदि आप PHP के पुराने संस्करण का उपयोग कर रहे हैं , तो आपको वास्तव में अपग्रेड करना चाहिए , लेकिन जब तक आप इस एपीआई को उजागर करने के लिए password_compat का उपयोग कर सकते हैं ।

इसके अलावा, कृपया password_hash()आप के लिए नमक उत्पन्न करते हैं। यह एक CSPRNG का उपयोग करता है ।

Bcrypt के दो कैविएट

  1. Bcrypt चुपचाप 72 अक्षरों से अधिक किसी भी पासवर्ड को काट देगा।
  2. Bcrypt किसी भी NULवर्ण के बाद छोटा हो जाएगा ।

( दोनों कैविएट के लिए अवधारणा का प्रमाण यहां)

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

अपनी स्वयं की योजना लिखने के बजाय, किसी मौजूदा पुस्तकालय का उपयोग करें और / या सुरक्षा विशेषज्ञों द्वारा मूल्यांकन किया गया हो।

टीएल; डीआर - बीसीक्रिप्ट का उपयोग करें


1
भी, मैं इस पर बहुत नया हूँ: sha1, sha256, और md5 सभी 'हैश' जिसे आप संदर्भित कर रहे हैं?
टोनी स्टार्क

3
हाँ। मैं SHA1, SHA256 और MD5 और गति के लिए अनुकूलित अन्य हैश की एक श्रृंखला की बात कर रहा हूँ। आप पासवर्ड सुरक्षित करने के लिए गति के लिए अनुकूलित हैश का उपयोग नहीं करना चाहते हैं। कई अच्छे लेख हैं क्यों, और मुझे यह विशेष रूप से पसंद है: chargen.matasano.com/chargen/2007/9/7/…
जोहान्स गोर्सेट

4
यह PHP 5.3 के बाद से "क्रिप्ट" फ़ंक्शन में शामिल है। यदि आपके पास पहले वाला संस्करण है, तो मैं अगले सबसे अच्छी चीज़ के लिए "फ़ास" ढांचे में देखूंगा।
जोहान्स गोर्सेट

3
@Stanislav Palatnik SHA512 एक अच्छा विकल्प है। मुझे गलत मत समझो; मैं यह नहीं कह रहा हूं कि एक बढ़ा हुआ और नमकीन SHA512 हैश असुरक्षित है। यह सुरक्षित है। फिर भी, तथ्य यह है कि bcrypt अधिक सुरक्षित है, और इसलिए मुझे इसका उपयोग न करने का कोई कारण नहीं दिखता है।
जोहान्स गोर्सेट

10
@ क्रेफ़: bcryptको समान रूप से दरार करने के लिए धीमा होने के हित में धीमा होने के लिए डिज़ाइन किया गया है।
जोहान्स गोर्सेट

23

मुझे लगता है कि md5 या sha256 या गति के लिए अनुकूलित किसी भी हैश का उपयोग करना पूरी तरह से ठीक है और किसी भी अन्य उपयोगकर्ताओं को हो सकता है सुनने के लिए बहुत उत्सुक हूं। यहाँ मेरे कारण हैं

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

  2. यदि आपके एसएसएल का उपयोग नहीं किया गया है या प्रमाण पत्र नहीं है, तो ट्रैफ़िक सुनने वाले हमलावर पासवर्ड और किसी भी प्रयास को जावास्क्रिप्ट के साथ एन्क्रिप्ट करने में सक्षम होंगे या जैसे क्लाइंट साइड है और आसानी से क्रैक और पार हो गया है। फिर यह सर्वर साइड पर डेटा एन्क्रिप्शन के साथ कुछ करने के लिए नहीं जा रहा है।

  3. जानवर बल के हमले कमजोर पासवर्डों का लाभ उठाएंगे और फिर से क्योंकि आप उपयोगकर्ता को डेटा दर्ज करने की अनुमति देते हैं यदि आपके पास 3 की लॉगिन सीमा या थोड़ी अधिक भी नहीं है, तो समस्या फिर से डेटा एन्क्रिप्शन के साथ कुछ भी नहीं करेगी ।

  4. यदि आपके डेटाबेस में समझौता हो जाता है, तो सबसे अधिक संभावना है कि आपकी हैशिंग तकनीक सहित हर चीज से समझौता किया गया है, चाहे आप इसे कितना भी गूढ़ बना लें। फिर से यह एक असंतुष्ट कर्मचारी XSS हमले या sql इंजेक्शन या कुछ अन्य हमले हो सकते हैं जिनका आपके पासवर्ड एन्क्रिप्शन से कोई लेना-देना नहीं है।

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

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

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


1
अच्छी तरह से कहा हुआ। हैशिंग तकनीकों पर साइबर सुरक्षा को प्राथमिकता दी जाएगी, वे न केवल आपके डेटा को बचाते हैं बल्कि सर्वर डिफेंस को भी तैयार रखते हैं।
CZZ 30'13

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

6
यह बुरी सलाह है। यदि कोई आपके डेटाबेस को चुरा लेता है और आपके सभी हैशेड पासवर्ड प्राप्त कर लेता है, भले ही उन्होंने आपके डेटाबेस के अन्य हिस्सों से भी समझौता किया हो, फिर भी उन्हें पासवर्ड क्रैक करने और लॉग ऑन करने से रोकना महत्वपूर्ण हो सकता है। (उदाहरण के लिए, किसी बैंकिंग वेबसाइट के बारे में सोचें।) स्पीड-ऑप्टिमाइज़्ड एल्गोरिदम हमलावरों को चुराए गए हैश के खिलाफ कई उम्मीदवारों का परीक्षण करने में सक्षम बनाता है जब तक कि उन्हें एक मैच न मिले। Bcrypt और scrypt जैसे एल्गोरिथ्म हैश के खिलाफ उम्मीदवारों का परीक्षण करने के लिए धीमी और महंगी बनाते हैं, भले ही वे जानते हों कि आप किस एल्गोरिथ्म का उपयोग करते हैं। इसलिए अगर कोई चोरी करता है तो वे उसे बेहतर सुरक्षा देते हैं।
रिचर्ड

6
"यदि आपका डेटाबेस समझौता हो जाता है, तो सबसे अधिक संभावना है कि आपकी हैशिंग तकनीक सहित हर चीज से समझौता किया गया हो, चाहे आपने इसे कितना भी गूढ़ बनाया हो।" ऐसा इसलिए है क्यों bcrypt बहुत महत्वपूर्ण है। Bcrypt के साथ, यह वास्तव में कोई फर्क नहीं पड़ता कि किसी के पास हैश है। SHA1 / MD5 जैसे तेज़ हैशिंग एल्गोरिथ्म के साथ, यह करता है।
सिजयोज़

मुझे लगता है कि आप में से कुछ बिंदु गायब हैं, यह कोई फर्क नहीं पड़ता कि पासवर्ड 1000% सुरक्षित है जब अन्य सभी डेटा स्पष्ट-पाठ है। उदाहरण के लिए, यदि पूरे डेटाबेस से छेड़छाड़ की जाती है, तो हैकर के पास अब सभी स्पष्ट-टेक्स्ट क्रेडिट कार्ड नंबर हैं। हां, कई लोग अलग-अलग वेब-साइटों पर एक ही पासवर्ड का उपयोग करते हैं, लेकिन उन्हें पहले ही कहा जा चुका है कि ऐसा नहीं करना है, इसलिए यह अब हमारी समस्या नहीं है। यदि डेटाबेस में स्वयं संवेदनशील जानकारी है, और इसका समझौता एक चिंता का विषय है, तो पूरे डेटाबेस को एन्क्रिप्ट करें, जैसा कि आपको लगता है कि आवश्यक है।
UnAAlby 21

15

के रूप में जोहानिस Gorset ने कहा, Matasano Security से थॉमस Ptacek द्वारा पोस्ट बताता है कि क्यों सरल, इस तरह के MD5, SHA1, SHA256 और SHA512 के रूप में सामान्य प्रयोजन हैशिंग कार्यों गरीब पासवर्ड हैशिंग विकल्प हैं

क्यों? वे बहुत तेज़ हैं - आप आधुनिक कंप्यूटर के साथ प्रति सेकंड कम से कम 1,000,000 एमडी 5 हैश की गणना कर सकते हैं, इसलिए ब्रूट बल उन अधिकांश पासवर्डों के खिलाफ संभव है जो लोग उपयोग करते हैं। और यह GPU आधारित क्रैकिंग सर्वर क्लस्टर से बहुत कम है!

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

उपयोगकर्ता @ कहता है:

हर कोई इस बारे में बात कर रहा है जैसे कि उन्हें इंटरनेट पर हैक किया जा सकता है। जैसा कि पहले ही कहा गया है, प्रयासों को सीमित करने से इंटरनेट पर पासवर्ड क्रैक करना असंभव हो जाता है और इसका हैश से कोई लेना-देना नहीं है।

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

फिर वह ऑफ़लाइन आक्रमण परिदृश्य पर वापस जाता है:

सुरक्षा वास्तव में खेल में आती है जब पूरे डेटाबेस से समझौता किया जाता है और एक हैकर md5h के खिलाफ प्रति सेकंड 100 मिलियन पासवर्ड प्रयास कर सकता है। SHA512 लगभग 10,000 गुना धीमा है।

नहीं, SHA512 MD5 की तुलना में 10000 गुना धीमा नहीं है - यह केवल लगभग दो बार लेता है। दूसरी ओर, Crypt / SHA512 , एक बहुत ही अलग जानवर है, जो कि अपने BCrypt समकक्ष की तरह, मुख्य स्ट्रेचिंग करता है , एक यादृच्छिक नमक के साथ एक बहुत अलग हैश का निर्माण करता है और 500 और 999999 के बीच कुछ भी लेगा जितना कि गणना करेगा। (स्ट्रेचिंग ट्यून करने योग्य है)।

SHA512 => aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d
Crypt/SHA512 => $6$rounds=5000$usesomesillystri$D4IrlXatmP7rx3P3InaxBeoomnAihCKRVQP22JZ6EY47Wc6BkroIuUUBOov1i.S5KPgErtP/EN5mcO.ChWQW21

तो PHP के लिए विकल्प या तो क्रिप्ट / ब्लोफिश (BCrypt), क्रिप्ट / SHA256 या क्रिप्ट / SHA512 है। या कम से कम क्रिप्ट / एमडी 5 (पीएचके)। Www.php.net/manual/en/function.crypt.php देखें


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

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

यदि सुरक्षा की आवश्यकता वास्तव में इतनी तीव्र है, तो पासवर्ड कहीं और संग्रहीत करना एक अच्छा विचार हो सकता है। आपके डेटा (और स्रोत-कोड) की रक्षा करने के कई तरीके हैं- "if / जब" ... .. लेकिन "gazillion बिट्स" तक हैशिंग पासवर्ड केवल उतना ही सुरक्षित है: पासवर्ड निर्माता / अतिथि-सिस्टम , डेटा ट्रांसमिशन और सर्वर हार्डवेयर की सेवा करने वाले मानव। .. कहा जा रहा है: मैं यह नहीं कह रहा हूँ कि हैशिंग बेकार है, हालाँकि मैं कह रहा हूँ कि यदि आपका समाधान सिर्फ अधिक जटिल हैश है, तो मुझे डर है कि यह निकट भविष्य में काम करने वाला नहीं है, क्वांटम कंप्यूटर के बारे में।

पुनरावर्ती हैशिंग किसी भी हैकिंग प्रयासों में काम / लागत जोड़ता है। अधिक पुनरावृत्तियों, दरार करने के लिए कठिन है, इसलिए SHA256 जैसे तेज हैश का भी उपयोग किया जा सकता है। Iterations यादृच्छिक होना चाहिए और इसे सार्वजनिक किया जा सकता है। password_hash()हैश में ही लागत को दर्शाता है।
विक्टर स्टोडार्ड

@VictorStoddard हां, आप अपनी स्वयं की हैशिंग योजना को रोल कर सकते हैं और ट्यून करने योग्य कुंजी खींच सकते हैं। लेकिन तुम क्यों हैं चाहते हैं कि ऐसा करने के लिए पहले से ही प्रयोग मौजूदा के बजाय, और अधिक अच्छी तरह से छानबीन एल्गोरिदम है कि विशेषज्ञों ने बनाया है और वास्तव में इस उद्देश्य के लिए उपलब्ध कराया है?
लेक्सएलिथियस

13

का उपयोग करें SHA256। यह सही नहीं है, जैसा SHA512कि एक तेज़ हैश के लिए आदर्श होगा, लेकिन विकल्पों में से, इसकी निश्चित पसंद। किसी भी हैशिंग तकनीक के अनुसार, अतिरिक्त सुरक्षा के लिए हैश को नमक करना सुनिश्चित करें।

एक जोड़ा नोट के रूप में, FRKT, कृपया मुझे दिखाओ, जहां कोई आसानी से एक नमकीन SHA256 हैश क्रैक कर सकता है? मैं वास्तव में इसे देखने के लिए बहुत इच्छुक हूं।

महत्वपूर्ण संपादन:

आगे बढ़ते हुए कृपया bcryptएक कठोर हैश के रूप में उपयोग करें । अधिक जानकारी यहां पाई जा सकती है


नमस्कार पर संपादित करें:

एक यादृच्छिक संख्या, या यादृच्छिक बाइट स्ट्रीम आदि का उपयोग करें। आप अपने डेटाबेस में नमक के रूप में रिकॉर्ड के अनूठे क्षेत्र का उपयोग कर सकते हैं, इस तरह नमक प्रति उपयोगकर्ता अलग है।


1
लेकिन उनकी गति के लिए अनुकूलित, जिसका अर्थ है कि वे जानवर-बल हैकिंग को सक्षम करते हैं।
8

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

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

1
कुछ भी तेजी से खराब / असुरक्षित हो जाता है / आदि के रूप में कंप्यूटिंग विकसित होता है। जब तक SHA512 आदि को हैक किया जाता है, तब तक अधिक सुरक्षित एल्गोरिदम उपलब्ध होंगे। यह किसी भी मामले में कंप्यूटिंग की प्रकृति है।
काइल रोज़ेंडो

1
php में नमक बनाने का एक अच्छा तरीका क्या है? उदाहरण कोड है? मुझे लगता है मैं सिर्फ 'जिराफ'
टोनी स्टार्क

4

लोगों को यह याद आ रहा है कि अगर हैकर के पास डेटाबेस तक पहुंच है, तो उसके पास शायद php फ़ाइल तक पहुंच है जो पासवर्ड को हैश करता है और संभवतः उसे संशोधित कर सकता है ताकि उसे सभी सफल उपयोगकर्ता नाम पासवर्ड कॉम्बो भेज सकें। यदि उसके पास वेब निर्देशिका तक पहुंच नहीं है, तो वह हमेशा केवल एक पासवर्ड हैश उठा सकता है, और डेटाबेस में लिख सकता है। दूसरे शब्दों में हैश एल्गोरिथ्म वास्तव में सिस्टम सुरक्षा के रूप में ज्यादा मायने नहीं रखता है, और लॉगिन प्रयासों को भी सीमित करता है यदि आप एसएसएल का उपयोग नहीं करते हैं तो हमलावर सिर्फ जानकारी प्राप्त करने के लिए कनेक्शन पर सुन सकता है। जब तक आपको गणना करने के लिए एल्गोरिथ्म की आवश्यकता न हो (अपने उद्देश्यों के लिए) तब उपयोगकर्ता विशिष्ट नमक के साथ SHA-256 या SHA-512 पर्याप्त होना चाहिए।

एक अतिरिक्त सुरक्षा उपाय के रूप में एक स्क्रिप्ट (बैश, बैच, पाइथन, आदि) या प्रोग्राम सेट करें और इसे एक अस्पष्ट नाम दें और इसे जांचें और देखें कि क्या login.php बदल गया है (चेक डेट / टाइम स्टैम्प) और आपको एक ईमेल भेजें अगर यह है इसके अलावा, संभवतः व्यवस्थापक अधिकारों के साथ लॉगिन में सभी प्रयासों को लॉग इन करना चाहिए और डेटाबेस में लॉग इन करने के लिए सभी विफल प्रयासों को लॉग करना चाहिए और लॉग को आपके पास ईमेल करना चाहिए।


"लोगों को जो चीज याद आ रही है वह यह है कि अगर हैकर के पास डेटाबेस तक पहुंच है, तो उसके पास शायद php फ़ाइल तक पहुंच भी है जो पासवर्ड हैश करता है ..." यह सच नहीं है। सबसे आम कमजोरियों में से एक एसक्यूएल इंजेक्शन है, जो डेटाबेस को पढ़ने / लिखने की क्षमता देगा लेकिन PHP कोड तक शून्य पहुंच देगा।
सिजयोज़

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

3

हर कोई इस बारे में बात कर रहा है जैसे कि उन्हें इंटरनेट पर हैक किया जा सकता है। जैसा कि पहले ही कहा गया है, प्रयासों को सीमित करने से इंटरनेट पर पासवर्ड क्रैक करना असंभव हो जाता है और इसका हैश से कोई लेना-देना नहीं है।

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

सुरक्षा वास्तव में खेल में आती है जब पूरे डेटाबेस से समझौता किया जाता है और एक हैकर md5h के खिलाफ प्रति सेकंड 100 मिलियन पासवर्ड प्रयास कर सकता है। SHA512 लगभग 10,000 गुना धीमा है। आज की शक्ति के साथ एक जटिल पासवर्ड को md5 के साथ bruteforce करने में 100 साल लग सकते हैं और SHA512 के साथ 10,000 गुना लंबा समय लगेगा। लवण हमेशा एक ब्रूटफोर्स को रोकते नहीं हैं क्योंकि उन्हें हमेशा जाना जाता है, जो अगर हमलावर ने आपके डेटाबेस को डाउनलोड किया है, तो वह संभवतः आपके सिस्टम में वैसे भी था।


1

टकराव की समस्याओं के कारण MD5 खराब है - दो अलग-अलग पासवर्ड संभवतः एक ही md-5 उत्पन्न कर रहे हैं।

Sha-1 इसके लिए काफी सुरक्षित होगा। पासवर्ड के नमकीन शा -1 संस्करण को संग्रहीत करने का कारण यह है कि आप swerver उपयोगकर्ता के एपैसवर्ड को फ़ाइल पर नहीं रखते हैं, जिसका उपयोग वे अन्य लोगों के सर्वर के साथ कर सकते हैं। नहीं तो क्या फर्क पड़ता है।

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

हमलावर के पास हैश वैल्यू रखने के लिए क्या अच्छा है, अगर आपका उपयोगकर्ता इनपुट एक सादा पासवर्ड है?

और भले ही भविष्य की तकनीक वाला हैकर एक क्रूर बल हमले के लिए एक लाख sha-1 कुंजी एक सेकंड उत्पन्न कर सकता है, क्या आपका सर्वर हैकर के लिए उसकी कुंजी का परीक्षण करने के लिए एक लाख लॉगऑन को संभाल सकता है? यदि आप हैकर को सामान्य लॉगऑन की तरह पासवर्ड के बजाय नमकीन शे -1 के साथ लॉगऑन करने की कोशिश कर रहे हैं।

सबसे अच्छा शर्त कुछ उचित संख्या के लिए खराब लॉगऑन प्रयासों को सीमित करना है - उदाहरण के लिए 25, और फिर एक या दो मिनट के लिए उपयोगकर्ता को समय देना। और अगर संचयी बुरा लॉगऑन प्रयास 24 घंटे के भीतर 250 हिट करता है, तो खाता एक्सेस बंद करें और मालिक को ईमेल करें।


यहां तक ​​कि अगर मैं एक कमजोर एन्क्रिप्शन का उपयोग कर रहा हूं, तो व्यावहारिक रूप से कोई भी सिस्टम प्रति सेकंड 1 मिलियन से अधिक प्रयासों के लिए एक क्रूर हमला नहीं कर सकता है।
मैगनेन्स

1
तीन विफल लॉगिन, और आप बाहर बंद कर रहे हैं। अवधि, कहानी का अंत। यहां तक ​​कि "1234" जैसे सुपर बेवकूफ पासवर्ड सुरक्षित हैं, अगर हैकर पहले "पासवर्ड", "पा $ $ शब्द" और "पासवार्ड" (लॉक आउट!) की कोशिश करता है। उपयोगकर्ता कैसे पहुंच प्राप्त करता है अब आपका सुरक्षा चिपके बिंदु बन जाता है, और आप जो भी करते हैं वह आपके उपयोगकर्ता आधार के आकार पर निर्भर करता है। 200 उपयोगकर्ता? मदद के लिए उन्हें टेलीफोन करें।
UncaAlby

क्या यह उत्तर किसी और के लिए समझ में नहीं आता है, या यह सिर्फ मैं है?
वाइल्डकार्ड


1

आर्गन 2 आई का प्रयोग करें । Argon2 पासवर्ड हैशिंग समारोह पासवर्ड हैशिंग प्रतियोगिता जीत लिया है।

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

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

MD5 से SHA1 या SHA512 पर स्विच करने से निर्माण की सुरक्षा में इतना सुधार नहीं होगा। SHA256 या SHA512 हैश की गणना करना बहुत तेज है। सामान्य हार्डवेयर वाला एक हमलावर अभी भी लाखों (एक सीपीयू के साथ) या अरबों (एक ही GPU के साथ) सेकेंड की कोशिश कर सकता है। अच्छे पासवर्ड हैशिंग कार्यों में शब्दकोश हमलों को धीमा करने के लिए एक कार्य कारक शामिल है।

यहाँ PHP प्रोग्रामर के लिए एक सुझाव दिया गया है: PHP FAQ पढ़ें और फिर password_hash () का उपयोग करें ।


0

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

एमडी 5 कमजोर है क्योंकि इसका छोटा और लोकप्रिय और व्यावहारिक रूप से पासवर्ड के बिना हर हैश जनरेशन डिक्शनरी के हमले से कमजोर है। परंतु..

तो, मान लीजिए कि हम अभी भी SALT के साथ MD5 का उपयोग कर रहे हैं। हैकर्स SALT को नहीं जानते हैं लेकिन वे एक विशिष्ट उपयोगकर्ता के पासवर्ड को जानते हैं। तो वे परीक्षण कर सकते हैं: ????? 12345 जहां 12345 पता पासवर्ड है और ????? नमक है। हैकर्स जल्द या बाद में SALT का अनुमान लगा सकते हैं।

हालांकि, यदि हमने MD5 + SALT का उपयोग किया है और हमने MD5 लागू किया है, तो जानकारी को पुनर्प्राप्त करने का कोई तरीका नहीं है। हालांकि, मैं दोहराता हूं, एमडी 5 अभी भी छोटा है।

उदाहरण के लिए, मान लें कि मेरा पासवर्ड है: 12345। SALT BILLCLINTON है

md5: 827ccb0eea8a706c4c34a16891f84e7b

md5 हैश के साथ: 56adb0f19ac0fb50194c312d49b15378

mD5 हैश ओवर के साथ md5: 28a03c0bc950decdd9ee362907d1798a मैंने उन ऑनलाइन सेवा का उपयोग करने की कोशिश की और मुझे ऐसा कोई नहीं मिला जो इसे क्रैक करने में सक्षम हो। और इसका एकमात्र MD5! (आज हो सकता है क्योंकि यह क्रैपीबल होगा क्योंकि मैंने md5 ऑनलाइन उत्पन्न किया है)

यदि आप ओवरकिल करना चाहते हैं तो SHA256 पर्याप्त से अधिक है अगर इसका नमक और दो बार लगाया जाए।

tldr MD5 (HASH + MD5 (पासवर्ड)) = ठीक है लेकिन संक्षेप में, SHA256 पर्याप्त से अधिक है।


नमक के साथ एमडी 5 का उपयोग करने में समस्या यह है कि कंप्यूटर सुपर फास्ट स्पीड वाले एक पासवर्ड पर एक क्रूर बल हमला कर सकते हैं। shylor.com/2015/09/14/php-5-5-secure-password-hashing
Shylor

0

एक md5 एन्क्रिप्शन सबसे खराब में से एक है, क्योंकि आपको कोड चालू करना होगा और यह पहले से ही डिक्रिप्ट हो गया है। मैं आपको SHA256 की सिफारिश करूंगा। मैं थोड़ा लंबा प्रोग्रामिंग कर रहा हूं और अच्छा अनुभव रहा है। नीचे एक एन्क्रिप्शन भी होगा।

password_hash() example using Argon2i

<?php
echo 'Argon2i hash: ' . password_hash('rasmuslerdorf', PASSWORD_ARGON2I);
?>
The above example will output something similar to:

Argon2i hash: $argon2i$v=19$m=1024,t=2,p=2$YzJBSzV4TUhkMzc3d3laeg$zqU/1IN0/AogfP4cmSJI1vc8lpXRW9/S0sYY2i2jHT0
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.