'पासवर्ड भूल गए' कार्यान्वयन के लिए सबसे अच्छा तरीका है? [बन्द है]

Question

मैं "पासवर्ड भूल गया" सुविधा को लागू करने के लिए सर्वोत्तम विधि की तलाश कर रहा हूं।

मैं 2 विचारों के साथ बाहर आया:

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

2. इसी तरह, लेकिन ईमेल में उपयोगकर्ता को अपना पासवर्ड रीसेट करने के लिए एक लिंक होगा।

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

Comments

मैंने पोस्ट को फिर से टैग किया क्योंकि यह JSF से आगे जाता है - आपको शायद इस तरह से अधिक प्रतिक्रियाएँ मिलेंगी।

— मैकडॉवेल

इन महीनों में मेटा पर "XYZ क्योंकि" इस बंद प्रश्न को हटा दें। मैं सिर्फ यह कहना चाहता हूं कि इस विशेष प्रश्न को हटाया नहीं जाना चाहिए, जब तक कि यह साबित न हो जाए कि समाधान त्रुटिपूर्ण हैं और यह अस्तित्व में है कि यह सुरक्षा के मामले में मदद करता है।

— फेलिक्स गगनोन-ग्रेनियर

एक भूल पासवर्ड वसूली की रणनीति के लिए OWASP "चीट शीट": Owasp.org/index.php/…

— daiscog

@Megaflop द्वारा सुझाया गया लिंक अब दुखद रूप से टूट गया है, यहाँ नया लिंक है: cheatsheetseries.owasp.org/cheatsheets/…

— Marco Bolis

Answer 1

अपडेट: बेहतर दृष्टिकोण के लिए मई 2013 में संशोधित किया गया

1. उपयोगकर्ता अपने उपयोगकर्ता नाम में प्रवेश करता है और "पासवर्ड भूल गया" हिट करता है। मैं उपयोगकर्ता नाम के बजाय ईमेल पते में प्रवेश करने के विकल्प की भी सिफारिश करता हूं, क्योंकि उपयोगकर्ता नाम कभी-कभी भूल भी जाते हैं।
2. सिस्टम में password_change_requestsकॉलम के साथ एक टेबल है ID, Timeऔर UserID। जब नया उपयोगकर्ता बटन दबाता है, तो तालिका में एक रिकॉर्ड बनाया जाता है। Timeस्तंभ समय उपयोगकर्ता "पासवर्ड भूल गए" बटन दबाया जब होता है। IDएक श्रृंखला है। एक लंबा रैंडम स्ट्रिंग बनाया जाता है (कहते हैं, एक GUID) और फिर एक पासवर्ड की तरह हैशेड (जो अपने आप में एक अलग विषय है)। यह हैश तब तालिका में 'आईडी' के रूप में उपयोग किया जाता है।
3. सिस्टम उस उपयोगकर्ता को एक ईमेल भेजता है जिसमें एक लिंक होता है। लिंक में मूल आईडी स्ट्रिंग (हैशिंग से पहले) भी शामिल है। लिंक कुछ इस तरह होगा: http://www.mysite.com/forgotpassword.jsp?ID=01234567890ABCDEF। Forgotpassword.jsp पृष्ठ आईडी पैरामीटर को पुनः प्राप्त करने में सक्षम होना चाहिए। क्षमा करें, मैं जावा को नहीं जानता, इसलिए मैं अधिक विशिष्ट नहीं हो सकता।
4. जब उपयोगकर्ता ईमेल में लिंक पर क्लिक करता है, तो वह आपके पृष्ठ पर चला जाता है। पृष्ठ IDURL से पुनर्प्राप्त करता है, इसे फिर से प्रकाशित करता है, और तालिका के खिलाफ जांच करता है। यदि ऐसा कोई रिकॉर्ड है और 24 घंटे से अधिक पुराना नहीं है, तो उपयोगकर्ता को एक नया पासवर्ड दर्ज करने के लिए संकेत दिया जाता है ।
5. उपयोगकर्ता एक नया पासवर्ड दर्ज करता है, ठीक-ठाक हिट करता है और अगली बार तक हर कोई खुशी से रहता है ...!

Comments

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

— कौशिक गोपाल

क्यों एक यादृच्छिक स्ट्रिंग / गाइड उत्पन्न करते हैं, हैश करते हैं और हैश का उपयोग करते हैं? क्या गाइड पर्याप्त नहीं है?

— जीरो के।

@jeroenk - ताकि अगर कोई आपका DB चुराता है, तो वह "रीसेट पासवर्ड" लिंक को फोर्ज नहीं कर सकता और किसी का पासवर्ड नहीं बदल सकता है।

— विल्क्स-

यह अनिवार्य रूप से पासवर्ड क्रैकस्टेशन.net

— hashing

@ डेविड - अच, मैं पोस्ट को संपादित करना चाहता था, लेकिन विषय बंद है। :( ठीक है, फिर से कोशिश करते हैं: अपनी मेज कॉलम होंगे: ID, UserID, Time, TokenHash।। आप दो लंबे, यादृच्छिक तार उत्पन्न होगा में पहली स्ट्रिंग ( "आईडी") रखो IDस्तंभ; हैश दूसरा ( "टोकन" ) और हैश को TokenHashकॉलम में रखें। लिंक की तरह जेनरेट करें। लिंक forogotPassword.jsp?id=asdasd&token=asdasdमें टोकन हैशेड नहीं है। क्या अब इसका कोई मतलब है?

— Vilx-

Answer 2

यह सब आपकी साइट और सुरक्षा के स्तर पर निर्भर करता है जिसे आप प्राप्त करने की कोशिश कर रहे हैं, लेकिन वेब ऐप के लिए मूल प्रक्रिया कुछ इस प्रकार है:

1. उपयोगकर्ता 'पासवर्ड भूल गए' पेज पर नेविगेट करता है और पासवर्ड रीसेट करने का अनुरोध करने के लिए अपना उपयोगकर्ता नाम या ईमेल (जो भी अनूठा हो) दर्ज करता है।

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

3. उपयोगकर्ता का खाता देखें। एक अस्थायी पासवर्ड (आमतौर पर एक GUID) और खाता रिकॉर्ड के खिलाफ टाइमस्टैम्प सहेजें। अस्थायी पासवर्ड वाले उपयोगकर्ता को एक ईमेल भेजें।

4. उपयोगकर्ता या तो अस्थायी पासवर्ड वाले लिंक पर क्लिक करता है और ईमेल में उपयोगकर्ता का पहचानकर्ता या 'मेरा पासवर्ड भूल गए' पेज पर नेविगेट करता है और अस्थायी पासवर्ड और उनके पहचानकर्ता को कॉपी और पेस्ट करता है। उपयोगकर्ता अपना नया पासवर्ड दर्ज करता है और इसकी पुष्टि करता है।

5. उपयोगकर्ता का रिकॉर्ड देखें और यदि वर्तमान समय चरण 2 में सहेजे गए टाइमस्टैम्प के निर्दिष्ट समय सीमा (जैसे 1 घंटे) के भीतर है तो नया पासवर्ड सेव करें। (जाहिर है कि केवल अस्थायी पासवर्ड मेल खाते हैं!)। अस्थायी GUID और टाइमस्टैम्प हटाएं।

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

मूल पासवर्ड उपयोगकर्ता को कभी भी प्रदर्शित नहीं किया जाएगा क्योंकि यह हैशेड और अज्ञात होना चाहिए।

ध्यान दें कि यह प्रक्रिया पूरी तरह से उपयोगकर्ता के ईमेल खाते की सुरक्षा पर निर्भर करती है। तो यह सुरक्षा के स्तर पर निर्भर करता है कि आपकी इच्छा क्या है। यह आमतौर पर अधिकांश साइटों / ऐप्स के लिए पर्याप्त होता है।

Answer 3

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

[टी] यहाँ दो सामान्य दृष्टिकोण हैं:

1. सर्वर पर एक नया पासवर्ड बनाएं और इसे ईमेल करें
2. एक अद्वितीय URL ईमेल करें जो रीसेट प्रक्रिया को सुविधाजनक बनाएगा

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

...

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

जब हम रीसेट URL के बारे में बात करते हैं, तो हम एक वेबसाइट पते के बारे में बात कर रहे हैं जो रीसेट प्रक्रिया के इस विशिष्ट उदाहरण के लिए अद्वितीय है।

...

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

...

दूसरी चीज़ जो हम रीसेट URL के साथ करना चाहते हैं, वह समय सीमा टोकन को सीमित करना है ताकि रीसेट प्रक्रिया को एक निश्चित अवधि के भीतर पूरा किया जाना चाहिए, एक घंटे के भीतर।

...

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

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

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

Comments

उस लिंक में स्पष्ट NSFW चित्र हैं, इसे बदलने के लिए एक लिंक है लेकिन बहुत सारे लोग पहले एक पृष्ठ को स्कैन करते हैं। मूर्ख विचार!

— nik0lai

ट्रॉय हंट के लेख का लिंक बदल गया है। गोटो troyhunt.com/everything-you-ever-wanted-to-know

— knarfancho

@knarfancho फिक्स्ड, धन्यवाद!

— डेव लीपमैन

Answer 4

मैं साथ जाऊंगा:

1. ईमेल के लिए उपयोगकर्ता से पूछें, ईमेल पंजीकृत है
2. GUID उत्पन्न करें, और उसे उस ईमेल पर भेजें
3. पासवर्ड अभी तक रीसेट न करें
4. उपयोगकर्ता क्लिक लिंक, और फिर नया पास दर्ज करना होगा
5. उपयोगकर्ता आपकी साइट पर होने के बाद ही पासवर्ड रीसेट करें, और नया पास टाइप करने के बाद रीसेट बटन पर क्लिक करें।
6. उस GUID को सुरक्षित बनाने के लिए थोड़े समय की अवधि के भीतर अपेक्षित करें।

Comments

मैं मुसीबत में नहीं पूछना चाहता हूँ? लेकिन यह आपके उत्तर से संबंधित है। आप GUID कैसे बना रहे हैं?

— KingAndrew

-1 आप जिस व्यक्ति को भेज रहे हैं उस पर किसी तरह के हैश को लागू नहीं करने के लिए

— TruthOf42

Answer 5

जब आप ईमेल के माध्यम से कोई जानकारी भेज रहे हैं, तो यह सुरक्षित नहीं होगा। ऐसे कई तरीके हैं जिनसे कोई भी इसे प्राप्त कर सकता है। यह आपकी जानकारी चुराने के लिए एक कुशल हैकर के लिए बच्चे का खेल होगा।

ईमेल के माध्यम से पासवर्ड और आय की जानकारी जैसी किसी भी व्यक्तिगत जानकारी को भेजने से बचना चाहिए क्योंकि यह आपके और आपके संगठन के लिए बहुत ही महत्वपूर्ण हो सकता है यदि ऐसी जानकारी लीक या चोरी हो गई थी। सुरक्षा के बारे में गंभीरता से सोचें। बस सभी ईंटों के गिरने की एक घटना होती है।

पासवर्ड पुनर्प्राप्ति के लिए, पूरी तरह से पासवर्ड भूल गए सर्वोत्तम व्यवहार पढ़ें ।

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

संपादित करें: अद्यतन लिंक

Comments

stackoverflow.com/questions/1069722/…

— jinsungy

मैंने पासवर्ड भूल गए सर्वोत्तम व्यवहार के लिए लिंक की कोशिश की और 500 सर्वर त्रुटि मिली। क्या आपको लगता है कि सर्वर अभी-अभी डाउन हुआ है या कोई अन्य लिंक फॉलो करना है?

— KingAndrew

यहाँ आप जाते हैं .. fishnetsecurity.com/Resource_/PageResource/White_Papers/…

— jinsungy

लिंक फिर से मर चुका है।

— एरिक कोप

यहाँ फिर से: fishnetsecurity.com/6labs/resource-library/white-paper/…

— Mustafa

Answer 6

जैसा कि कहा गया है, यह आवश्यक सुरक्षा के स्तर पर निर्भर करता है, हालांकि, यदि आपको उच्च स्तर की आवश्यकता है, तो कुछ उपन्यास समाधान जो मैंने देखे हैं, उनमें शामिल हैं;

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

• ईमेल और एक अन्य माध्यम से पहचान की पुष्टि करना - उदाहरण के लिए एक पंजीकृत मोबाइल पर पाठ के माध्यम से भेजा गया कोड। (ईबे / पेपल पर देखा गया)

कहीं न कहीं इन दो चरम सीमाओं के बीच सुरक्षा के सवालों को लागू करने का तरीका डेवग द्वारा बताए गए तरीके से हो सकता है।

Answer 7

यदि आप पंजीकरण के साथ एक ईमेल पता शामिल करते हैं। "पासवर्ड भूल जाओ" बटन उस ईमेल पते पर एक ईमेल भेजता है। यह सुनिश्चित करता है कि जानकारी किसी विश्वसनीय ईमेल को भेजी जाए।

(जब तक डेटाबेस हैक न हो जाए, लेकिन तब कुछ भी सुरक्षित नहीं है)।

Answer 8

यहाँ तीन बहुत अच्छे लिंक दिए गए हैं जो पासवर्ड रीसेट की जानकारी देते हैं:

1. http://jtauber.com/blog/2006/03/20/account_management_patterns/

2. (उपयोगकर्ताओं को GET का उपयोग करने की पुष्टि न करें): http://www.artima.com/forums/flat.jsp?forum=106&thread=152805&start=15&msRange=15

3. http://fishbowl.pastiche.org/archives/docs/PasswordRecovery.pdf

उम्मीद है की वो मदद करदे। उन्होंने मुझे इस मुद्दे को समझने में मदद की।

Answer 9

मैं पूरे खातों में अद्वितीय ईमेल पते लागू करूंगा।

फिर एक अस्थायी पृष्ठ पर लिंक भेजने का एक साधारण मामला है जो व्यक्ति को अपना पासवर्ड बदलने की अनुमति देता है। (24 घंटे या उससे कम की अनुमति दें)

उपयोगकर्ता का ईमेल खाता इस परिदृश्य में सबसे कमजोर कड़ी है।

Answer 10

कभी भी उपयोगकर्ता को पासवर्ड न भेजें। भले ही वह ऑटो जेनरेटेड हो। सर्वोत्तम दृष्टिकोण (SANS और अन्य द्वारा अनुशंसित और उपयोग किया जाता है):

1. पासवर्ड पृष्ठ भूल जाने पर, उपयोगकर्ता से ईमेल / उपयोगकर्ता आईडी और नया पासवर्ड पूछें।
2. सक्रियण लिंक के साथ उस खाते के लिए संग्रहीत ईमेल का लिंक ईमेल करें।
3. जब उपयोगकर्ता उस लिंक पर क्लिक करता है, तो नया पासवर्ड सक्षम करें।

यदि वह 24 घंटे या इसके भीतर लिंक पर क्लिक नहीं करता है, तो लिंक को अक्षम करें (ताकि यह पासवर्ड को अब और न बदले)।

उपयोगकर्ता की सहमति के बिना पासवर्ड कभी न बदलें। इसका मतलब यह नहीं है कि एक नया पासवर्ड ईमेल न करें क्योंकि कोई व्यक्ति पासवर्ड भूल गए लिंक पर क्लिक करता है और खाता नाम का पता लगाता है।

Comments

मैं इस तकनीक से चिंतित हूं। हमलावर आपके ईमेल और एक नए पासवर्ड में प्रवेश करता है। खाता स्वामी ईमेल प्राप्त करता है, कुछ गलत करता है, और लिंक पर क्लिक करता है। हमलावर खड़े होकर, हर मिनट नए पासवर्ड की कोशिश करते हुए, खाते तक पहुंच प्राप्त करता है जब तक कि खाते के मालिक को पता नहीं चलता कि क्या हुआ और आखिरकार "पासवर्ड भूल गया" पृष्ठ।

— ओडी - जुले

एक और मुद्दा! पासवर्ड रीसेट समय पर एक नया पासवर्ड प्रदान करना एक अच्छा विकल्प नहीं है। अगर घंटे के बाद मेरे ईमेल की जाँच की गई तो मैं फिर से नया पासवर्ड भूल सकता हूँ!

— यजीद एरमान