पासवर्ड hashing और अपने उपयोगकर्ता के लिए समर्थन करते हैं


10

हमने हाल ही में एक बेहतर पासवर्ड स्टोरेज स्ट्रैटेजी की ओर रुख किया है, जिसमें सभी अच्छे सामान आए हैं:

  • पासवर्ड bCrypt के माध्यम से जाने के बाद संग्रहीत किए जाते हैं
  • पते के स्वामित्व की पुष्टि करने के लिए उपयोगकर्ता को खाता निर्माण पर एक सक्रियण लिंक भेजा जाता है
  • सुरक्षा प्रश्न के बिना पासवर्ड भूल गए, उनके ईमेल पर एक लिंक भेजा जाता है।
  • लिंक 24 घंटे के बाद समाप्त हो जाता है, जिस बिंदु पर उन्हें एक नया अनुरोध करने की आवश्यकता होगी।
  • यदि खाता हमारे कर्मचारियों से बनाया गया है, तो एक ईमेल इसमें एक यादृच्छिक मजबूत पासवर्ड के साथ भेजा जाता है। उपयोगकर्ता में लॉगिन करने पर उसे कुछ ऐसी चीज़ों के लिए रीसेट करना होगा जिन्हें हम नहीं जानते हैं और जो कि bCrypt'd है।

अब यह "बेस्ट-प्रैक्टिस" के अनुसार है, लेकिन इससे नियमित उपयोगकर्ताओं से हमारे समर्थन के अनुरोध में बहुत वृद्धि हुई है, जो यह सब नहीं समझते हैं, वे बस लॉगिन करना चाहते हैं।

हमें अक्सर उन उपयोगकर्ताओं से अनुरोध मिलता है जिनके बारे में शिकायत करते हैं:

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

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

मैं उत्सुक हूं कि अधिकांश लोग इन जैसे मुद्दों से कैसे निपटते हैं?


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

1
लोग बेवकूफ हैं, आपके उपयोगकर्ता, अधिकांश अन्य लोगों की तुलना में अधिक, मैं यहां सवाल नहीं देखता हूं?

8
Jarrod आप अपने उपयोगकर्ताओं का अपमान कर रहे हैं। यहाँ एक बेवकूफ तुम हो। आप अपने उपयोगकर्ताओं की कंप्यूटर साक्षरता के स्तर को समझने में विफल हैं। कोई अपराध नहीं है, लेकिन आप कंप्यूटर गीक्स के लिए नहीं लोगों के लिए सॉफ्टवेयर लिख रहे हैं। यदि आप कोई प्रश्न नहीं देखते हैं, तो इसका मतलब है कि उन सभी प्रयोज्य विशेषज्ञों को बाहर निकाल दिया जाना चाहिए, क्योंकि उन्हें वास्तव में जरूरत नहीं है। यह सिर्फ "बेवकूफ लोगों" के साथ समस्या है, इसलिए हम - चतुर डेवलपर्स सिर्फ वेब से उन पर प्रतिबंध लगाते हैं और समस्या दूर हो जाएगी :) अगर किसी ने एक प्रणाली लिखी है जो केवल लेखक का उपयोग कर सकता है तो आपको कोई समस्या नहीं दिखती है?
स्लावेक

2
@ स्लावेक: नहीं, वास्तव में, लोग मूर्ख हैं।
ब्रायन बोएचर

@JarrodRoberson, शायद ही अपने उपयोगकर्ताओं को - जब सार्वजनिक रूप से वेब अनुप्रयोगों का सामना कर रहे हों, तो आम तौर पर आपको जो मिलता है। उस ने कहा, यह पसंद है या नहीं , यह अभी भी समर्थन संसाधनों को लेता है, और बहुत वैध सवाल है।
ग्रैंडमास्टरबी

जवाबों:


7

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

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

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

सुनिश्चित करें कि आपका आउटगोइंग ई-मेल डी-स्पैम किया हुआ है (शायद कुछ सामान्य मेल सेवाओं पर सेटअप परीक्षण खाते), जो कुछ भी होता है उसे लॉग इन करें और शायद रिपोर्ट करें कि यदि वे नए रीसेट का अनुरोध करने की कोशिश करते हैं, तो उपयोगकर्ता (यानी, मेल को johndoee @ gmail) .com विफल रहा, उपयोगकर्ता नहीं मिला, क्या आपने इसे सही तरीके से लिखा है?)। इसके अलावा, उपयोगकर्ताओं को वर्तनी और स्पैम के मुद्दों के बारे में स्पष्ट रहें।

साथ ही, OpenID और अन्य तीसरे पक्ष के ऑर्टर्स भी एक विकल्प हैं, जैसा कि अन्य ने कहा है।


कुछ लोग अपने पासवर्ड में स्थान रखते हैं?
soandos

कुछ लोग ऑटो-जनरेट किए गए पासवर्ड को काटते हैं और गलती से शुरुआत और / या अंत में रिक्त स्थान शामिल करते हैं। (प्रश्न पढ़ें।)
मैके

3

मैं कहूंगा कि फेसबुक, ओपेनआईडी, गूगल जैसे थर्ड पार्टी ऑथेंटिकेशन मेथड का उपयोग करें ... जो भी आपके उपयोगकर्ताओं के लिए उपयुक्त है। हालाँकि, यदि आपके उपयोगकर्ता आपके पासवर्ड को याद नहीं रख सकते हैं, तो शायद वे तृतीय पक्ष प्रमाणीकरण प्रणाली का उपयोग नहीं कर पाएंगे ...

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


ग्राहक प्रमाण पत्र एक विचार है। वे असुरक्षित हैं और कुछ बुरा होने पर दूर से ठीक करने के लिए दुःस्वप्न। Openid एक अच्छा विचार है, हालांकि
टॉम स्क्वायर्स

प्रमाणपत्र कैसे असुरक्षित हैं?
बर्नार्ड

@ कोई भी व्यक्ति जो उस पीसी पर है उसके पास प्रमाणपत्र है। यह भी एक वायरस के साथ बाहर निकलना काफी आसान है
टॉम स्क्वायर्स

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

3

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

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

Buce Scheiners वर्क्स (राज और झूठ) को सुरक्षा समझने की एक अच्छी शुरुआत के रूप में पढ़ें।


3

पहली बात यह है कि आपके ईमेल जंक मेल में जा रहे हैं। ईमेल को सेट करना ताकि यह पहचाना जाए कि असली तुच्छ नहीं है। मेरा सुझाव है कि आप यह देखें कि गलत तरीके से फ़हराए जा रहे आपके ईमेल को कैसे रोका जाए (SO पर अलग प्रश्न?)

दूसरी बात जो मैं सुझाऊँगा वह आपके उपयोगकर्ताओं को एक क्लिक वेबसाइट / ऐप देने की है जो पासवर्ड पुनर्प्राप्त करने वाले ईमेल को आरंभ करती है। इसे ईमेल के अलावा किसी अन्य तरीके से करने से मना करें, यह असुरक्षित है और एक बुरी मिसाल कायम करता है।


ऐसा नहीं है कि ई-मेल संवेदनशील सूचना प्रसारित करने का एक विशेष रूप से सुरक्षित तरीका है। अगर केवल नियमित उपयोगकर्ताओं को ही GPG और ssh कीज़ से परेशान किया जा सकता है ...
tdammers

@ मैं यह मानता हूँ कि यह इतना सुरक्षित नहीं है। हालांकि यह आपकी ऑनलाइन पहचान (बेहतर या बदतर के लिए) का कीस्टोन बन गया है। वर्तमान में एक बेहतर व्यवहार्य विकल्प नहीं है।
टॉम स्क्वायर्स

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

@ मैं इसके बारे में पर्याप्त नहीं जानता कि यह खुद इसे सुझाएगा। इसकी रक्षा ओपी में देखने लायक है
टॉम स्क्वायर्स

2

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

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


2
प्रत्यक्ष डेटाबेस संशोधन अपने आप में एक सुरक्षा उल्लंघन है। इसका मतलब है कि आप अपने सिस्टम का उपयोग करके किसी भी उपयोगकर्ता को लगा सकते हैं।
बर्नार्ड

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

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

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

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

2

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

यह बुलेटप्रूफ नहीं है क्योंकि एक समर्थन व्यक्ति एक स्थान से दोनों सिरों को चलाने के लिए एक वीपीएन का उपयोग कर सकता है, लेकिन यह ऑडिट के लिए पर्याप्त था क्योंकि समर्थन खाता गतिविधि के लिए जिम्मेदार था।


-5

शायद सुरक्षा नियमों को लागू करने से जो INSANE नहीं हैं। ऐसा करने से, आप वास्तव में कम सुरक्षा प्राप्त कर रहे हैं, क्योंकि सिस्टम का उपयोग करना इतना कठिन है कि आपके ग्राहक आपके और उनके दोस्तों के पासवर्ड को फिर से काम में लेने के लिए फिर से तैयार करेंगे!

क्या आप उन्हें केवल NORMAL लिंक नहीं भेज सकते, फिर नीचे पासवर्ड। अगर ईमेल क्लाइंट से लिंक टूट जाता है, तो फॉर्म को एक फ़ील्ड "सक्रियण कोड" के साथ प्रदर्शित करें ... "ईमेल में आपके पास सक्रियण कोड टाइप करें" ... 5 अंक इसलिए वे 0 के साथ 0, O आदि में गलती नहीं करेंगे। क्रेडिट कार्ड के लिए अंक ठीक हैं और आपको सरल लॉगिन के लिए इतनी जटिल नीति की आवश्यकता है? यदि कोड TRIMmed स्ट्रिंग के साथ चेक को दोहराने का काम नहीं करेगा? मुझे लगता है कि यह कम सुरक्षित नहीं होगा, है ना? :)

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

आपने इसे इतनी बुरी तरह से उलट दिया है। यह "रीसेट पासवर्ड" और "प्रारंभिक पासवर्ड" नहीं है ... लेकिन "पुष्टिकरण कोड" और "पुष्टिकरण नंबर दर्ज करें जो हम आपको ईमेल पर भेजते हैं", "ईमेल नहीं है? इसे xxx@yyy.com पर भेजा गया था, जांचें आपका स्पैम फिर से, अभी भी नहीं है? अपने पुष्टिकरण ईमेल को रीसेट करें "। HTML बॉडी में एक लिंक। http://xxx.com/conf-12345-mymail-gmail-com.html । कोई भी मेल क्लाइंट इसे नहीं तोड़ेगा।


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

7
-1। यह ऐसा करने का एक तरीका है, जो कि अधिकांश साइटें उपयोग करती हैं। यदि मैं एक साइट पर "पासवर्ड भूल गया" जारी करता हूं, और सादे पाठ में अपने पासवर्ड के साथ एक ईमेल प्राप्त करता हूं, तो मैं अपना खाता बंद कर देता हूं।
मैट ग्रांडे
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.