20

अगर मैं एक ऐसे ऐप के लिए लॉगिन बनाता हूं, जिसमें कम से कम सुरक्षा जोखिम है (दूसरे शब्दों में, इसकी बैंकिंग ऐप या कुछ भी नहीं), तो क्या मेरे लिए उपयोगकर्ता द्वारा दर्ज पासवर्ड को सत्यापित करने के लिए केवल कुछ ऐसा कहना स्वीकार्य है:

if(enteredPassword == verifiedPassword)
     SendToRestrictedArea();
else
     DisplayPasswordUnknownMessage();

यह प्रभावी होना आसान लगता है, लेकिन मुझे निश्चित रूप से बुरा नहीं लगेगा अगर यह सब आवश्यक था। क्या यूज़रनेम / पासवर्ड कॉम्बो पर एक साधारण जाँच पर्याप्त है?

अपडेट: विशेष परियोजना एक वेब सेवा होती है, सत्यापन पूरी तरह से सर्वर साइड है, और यह ओपन-सोर्स नहीं है। क्या डोमेन बदलता है कि आप इससे कैसे निपटेंगे?

security passwords validation

— मॉर्गन हेरलॉकर
स्रोत

3

यह निर्भर करता है कि वैधपद कहाँ से आता है? यदि यह हार्डकोड है तो आप कोड को बदले बिना पासवर्ड को कॉन्फ़िगर / बदल नहीं पाएंगे। यदि यह एक कॉन्फ़िगरेशन फ़ाइल से आता है, तो यह किसी को भी दिखाई देगा जो इसे एक्सेस करता है।

— Alb

1

"उपयोगकर्ता नाम / पासवर्ड कॉम्बो पर एक जांच पर्याप्त है" क्या करना है?

— क्रिस

3

@opinion: ऐसा लगता है कि यह लॉगिन नहीं होने की तुलना में काम करता है। कृपया इस तरह के मजबूत दावे के लिए कुछ तर्क दें।

— मॉर्गन हेरलॉकर

1

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

— billy.bob

1

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

— रीन हेनरिच

26

एसएसएल के बिना नहीं

यह सुरक्षित नहीं है अगर पासवर्ड सादे पाठ में नेटवर्क पर भेजा जाता है। यदि पासवर्ड को सादे पाठ में नेटवर्क पर भेजा जाता है, तो सर्वर साइड पर पासवर्ड को सुरक्षित करना भी सुरक्षित नहीं है।

चूंकि HTML <input type="password"/>टैग सादे पाठ में अपनी सामग्री भेजता है, इसलिए यह एक समस्या होगी कि आप सर्वर पर पासवर्ड कैसे संग्रहीत करते हैं, जब तक कि आपकी वेबसाइट SSL का उपयोग पासवर्ड संचारित करने के लिए नहीं करती है।

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

यदि साइट व्यवस्थापक संदिग्ध हैं तो नहीं

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

एक ऐसा तरीका जो प्रशासक से पासवर्ड सुरक्षित रखता है

पासवर्ड को स्टोर और चेक करने का एक सुरक्षित तरीका इस प्रकार है:

def change_password user, new_password
  salt = random(65536).to_s(16) #will be 4 characters long
  password_hash = salt + hash(salt + new_password)
  store(user,password_hash)
end

def does_password_match? user, entered_password
  correct_password_hash = retrieve(user)
  salt = correct_password_hash[0...4]
  entered_password_hash = salt + hash(salt + entered_password)
  return correct_password_hash == entered_password_hash
end

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

आप जिस वातावरण में हैं, उसके आधार पर आपके नेटवर्क विलंबता में परिवर्तनशीलता, और क्या उपयोगकर्ता नाम पारंपरिक रूप से ज्ञात हैं, तो आप hash('0000'+entered_password)हमलावरों को रोकने के लिए उपयोगकर्ता के मौजूद न होने पर एक अन्य कोड पथ गणना करना चाह सकते हैं यह निर्धारित करना कि उपयोगकर्ता का नाम उस समय के आधार पर मान्य है जो यह निर्धारित करता है कि पासवर्ड गलत है।

— केन ब्लूम
स्रोत

1

अच्छी सलाह :) SSL के बारे में, हमें कुछ ऐसा डिज़ाइन करने की आवश्यकता थी , जो जंगली में काम करे , और बस पासवर्ड को एनकोड करने के लिए असममित क्रिप्टोग्राफ़ी का उपयोग किया जाए (जावास्क्रिप्ट की आवश्यकता होती है) और फिर इसे सर्वर पर डिकोड करें। नमक + हैश तब सामान्य रूप से होता है। इसके अलावा, चूंकि सार्वजनिक कुंजी को वेब-पेज के साथ भेजा जाता है, इसलिए यह अक्सर मनमाने ढंग से बदल सकता है।

— मथिउ एम।

1

@ मैथ्यू एम।: जब कोई आपके वेबपेज को नकली कर सकता है, तो वह सार्वजनिक कुंजी को वहां बदल सकता है, जहां वह खुद को संबंधित निजी कुंजी जानता है। इसलिए आपका विचार केवल निष्क्रिय रीड-हमलों के खिलाफ मदद करता है, न कि बीच-बीच में।

— पाओलो एबरमन

@ पाओलो: हाँ, मैं मानता हूँ कि एसएसएल न केवल एन्क्रिप्शन के बारे में है, बल्कि प्रमाण पत्र के बारे में भी है, दुर्भाग्य से मैं यहाँ शॉट्स नहीं बुलाता, और जब लोग कहते हैं कि वे एक नियमित http://कनेक्शन के साथ वेबपेज का उपयोग करना चाहते हैं ... यह निराशाजनक है: /

— मैथ्यू एम।

@ मैथ्यू: इसका मतलब है कि आप public_key को सार्वजनिक वेब पेज के हिस्से के रूप में भेज रहे हैं, encrypt(entered_password, public_key)क्लाइंट पर कंप्यूटिंग कर रहे हैं और उस परिणाम को सर्वर पर भेज रहे हैं, जो प्रदर्शन करता है does_password_match?(user, decrypt(encrypted_password, private_key))?

— केन ब्लूम

@ कम: कम या ज्यादा, आपको एन्क्रिप्शन सही मिला। does_password_match(user, salt, decrypt(encrypted, key))उपयोगकर्ता के आधार पर नमक के साथ पासवर्ड के मिलान के लिए यह अधिक है । जैसा कि मैंने कहा, स्पष्ट मुद्दा मानव-मध्य सुरक्षा का अभाव है।

— मैथ्यू एम।

52

यह सुझाव देगा, कि आप खुले पाठ में पासवर्ड रख रहे हैं, जो कम सुरक्षा परिदृश्यों में भी, नहीं-नहीं है।

बल्कि आपके पास होना चाहिए:

if(hash(enteredPassword) == storedHash)

आप उदाहरण के लिए MD5 के रूप में सरल हैश का उपयोग कर सकते हैं

— vartec
स्रोत

22

पासवर्ड के लिए +1 हैशिंग। लेकिन मैं कम से कम कुछ नमक भी मिलाऊंगा। अन्यथा, चूंकि उपयोगकर्ता सिस्टम के बीच उपयोगकर्ता नाम और पासवर्ड का पुन: उपयोग करने जा रहे हैं, इसलिए आपके कम सुरक्षा ऐप का उपयोग करने से हमलावर बहुत अधिक सुरक्षा ऐप को भंग करने में सक्षम हो सकता है। उदाहरण के लिए, हाल ही में HBGary हैक, अपनी वेबसाइट पर चलने वाले CMS सिस्टम से समझौता करने में कामयाब रहा और उस हिस्से में अपने सर्वर तक रूट एक्सेस किया क्योंकि कम-सुरक्षा CMS सिस्टम में हैश arstechnica.com/tech-policy/ में

— जस्टिन गुफा

1

सहमत ... निम्नलिखित पर विचार करें .. "स्ट्रिंग JavaFile.class | grep -i पासवर्ड"

— बिल

यदि उन्हें केवल एक बार उपयोग किया जाता है, तो सादा पाठ में पासवर्ड रखने में क्या समस्या है?

10

@ क्योंकि उपयोगकर्ता केवल एक बार पासवर्ड का उपयोग नहीं करेगा । अध्ययनों से लगातार पता चलता है कि उपयोगकर्ता कई बार पासवर्ड का उपयोग करते हैं (जैसे theregister.co.uk/2011/02/10/password_re_use_study ) चाहे वे कितनी बार क्यों न कहें ।

— स्कॉट

3

@ समय: इसके अलावा, बस अपने exe, dll, आदि को टेक्स्ट एडिटर में खोलें, और आपको अपना पासवर्ड वहीं दिखाई देगा।

— गुस कैवलन्ती

14

मैं उन लोगों के साथ सहमत हूं जो हैशिंग का सुझाव देते हैं, लेकिन एक पहिया भी है जिसे आप यहां पुनर्निवेश कर रहे हैं। प्लेटफ़ॉर्म के आधार पर आप संभवतः एक भूमिका / उपयोगकर्ता प्रबंधन टूल पा सकते हैं जो उपयोगकर्ता प्रबंधन के सभी सामानों को आपके हिस्से पर बहुत अधिक हस्तक्षेप की आवश्यकता के बिना सुरक्षित रूप से और सुरक्षित रूप से कवर करता है।

— glenatron
स्रोत

मैंने केवल ASP.Net सदस्यता प्रदाता की खोज की, लेकिन मैं उन्हें यह सोचता हुआ देख रहा था कि "कुछ ऐसा लागू करने में मैंने अपना समय कितनी बार बर्बाद किया है?"

— ग्लेनट्रॉन

8

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

isSecuritySufficient = effortToBreak > rewardForBreaking

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

उपलब्ध कम लागत (उपयोगकर्ता को लागू करने और प्रभावित करने के लिए) के कई विकल्प हैं। उनमें से एक पासवर्ड नंगे न्यूनतम पर हैशिंग है। सादे पाठ में पासवर्ड के रूप में संवेदनशील के रूप में कुछ भी संग्रहीत करने वाली कोई भी सेवा हैक होने की शर्मिंदगी के हकदार हैं।

पासवर्ड सुरक्षा के लिए सामान्य सिद्धांत

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

चूंकि आप प्रमाणीकरण के लिए एसएसएल का उपयोग कर रहे हैं, कम से कम आप उन सभी पृष्ठों को एन्क्रिप्ट करना चाहते हैं जो उपयोगकर्ता के खाते के साथ भी व्यवहार करते हैं। इससे उपयोगकर्ता की अधिक से अधिक पहचान संभव हो सकेगी।

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

— बेरिन लोरिट्श
स्रोत

1

सबसे पहले मैं वास्तव में एप्लिकेशन नमक + उपयोगकर्ता नमक के विचार से मारा गया था, लेकिन जितना अधिक मैं इसके बारे में सोचता हूं, उतना कम आश्वस्त हूं। यदि आप कहते हैं, अनुप्रयोग नमक के 4 वर्ण और उपयोगकर्ता नमक के 4, तो उपयोगकर्ता नमक के 8 और उसके बीच का अंतर सिर्फ इतना है कि आधा नमक प्रत्येक उपयोगकर्ता के लिए समान होगा। ऐसा लगता है कि यह केवल उपयोगकर्ता नमक के आकार को बढ़ाने के लिए अधिक सुरक्षित होगा, बजाय आवेदन नमक के। इसके अलावा, यदि एप्लिकेशन नमक हार्डवेयर पर आधारित है, तो आप सभी पासवर्ड को अमान्य किए बिना हार्डवेयर को अपग्रेड या बदल नहीं सकते हैं।

— डेविड कॉनराड

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

— बेरिन लोरिट्श

आह, मैं देख रहा हूं, नमक का हिस्सा डेटाबेस से बाहर रखें। यह समझ में आता है। धन्यवाद।

— डेविड कॉनराड

मुझे नमक-पंक्ति को संग्रहीत करने में कोई समस्या नहीं दिख रही है, जब तक कि इसकी अद्वितीय प्रति पंक्ति नहीं है। यहाँ एक हैश है: "fd84235a55bbfeb1585a3dd069d48127989c9753058b51b6ba2056fd6c5a0a91" (SHA256), यहां का नमक: "671254bdf7944f8fa88e6c9913b9b948"। लगता है कि आप पासवर्ड प्राप्त कर सकते हैं? उस नमक के लिए कोई इंद्रधनुष तालिका नहीं है (भले ही आपको नमक दिया गया हो), आप इसे जानवर के लिए मजबूर कर रहे हैं।

— ब्रायन बोएचर

3

यह तब तक ठीक है जब तक पासवर्ड का इस्तेमाल किसी और चीज के लिए न किया जाए। अभी भी एक जोखिम है जो उपयोगकर्ता तय करता है कि वह पासवर्ड का फिर से उपयोग कर सकता है, इसलिए यह इसके साथ बेहतर होगा:

if(hash(enteredPassword) == hashOfValidPassword)

यदि यह स्वयं या किसी ऐसे व्यक्ति के लिए है जो पासवर्ड सादे पाठ में संग्रहीत है, तो यह ठीक है।

1

जैसा कि जस्टिन केव ने वार्टेक के जवाब में टिप्पणी की थी, नमक का उपयोग करें, इसलिए if (hash (enteredPassword + salt) == hashOfValidSaltedPassword)- और ध्यान दें कि +यह संभवतः संघनन है, इसके अलावा नहीं। यह वास्तव में इंद्रधनुष तालिकाओं के उपयोग में बाधा उत्पन्न करता है, जो संभावित पासवर्ड के हैश के टेबल हैं।

— डेविड थॉर्नले

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

— Morgan Herlocker

@Prof प्लम: हैशिंग एल्गोरिथ्म अच्छा है तो टकराव का पता लगाना बहुत मुश्किल है। यह आधुनिक क्रिप्टोग्राफी का आधार है: वे अनिवार्य रूप से एक तरफा कार्य करते हैं।

3

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

यदि आपकी राय में यह बहुत महत्वपूर्ण नहीं है, तो भी सुरक्षा की अनदेखी कभी न करें।

— Anto
स्रोत

2

हाँ, बुरा विचार अगर यह एक ओपन सोर्स प्रोजेक्ट है :)

-1 - अगर आपको लगता है कि स्रोत होने से फर्क पड़ता है, तो आप सुरक्षा के बारे में कुछ नहीं जानते हैं।

— मट्टनज

1

बिलकुल नहीं। की एक पढ़ा है यह , यह बताता है कि कैसे हैकर्स एक सुरक्षा वेब साइट हैक कर लिया। आप योजना बनाते हैं कि आपके पास श्रृंखला की सबसे कमजोर कड़ी होगी।

— डेव
स्रोत

0

यह जवाब के एक जोड़े में नोट किया गया है कि आपको पासवर्ड को स्टोर नहीं करना चाहिए, लेकिन एक हैश - और आपको एसएसएल का उपयोग करना चाहिए।

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

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

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

— पीट
स्रोत

-2

जब तक यह सर्वर साइड है .. तब हाँ।

यदि आप https में थोड़ा और सुरक्षा चाहते हैं, तो DB में पासवर्ड एन्क्रिप्ट करें।

— बेवकूफों
स्रोत

3

क्यों मान लें कि यह एक वेब ऐप है?

— क्रिस

अच्छी बात! मैंने अभी किया।

— मोरों

4

-1 भले ही यह सर्वर साइड हो फिर भी यह ठीक नहीं है।

— GSto

क्या न्यूनतम सुरक्षा के लिए 'if password == XXXXXXX' पर्याप्त है?

एसएसएल के बिना नहीं

यदि साइट व्यवस्थापक संदिग्ध हैं तो नहीं

एक ऐसा तरीका जो प्रशासक से पासवर्ड सुरक्षित रखता है