गैर-

Question

ईमेल के साथ ईमेल में सक्रियण/पंजीकरण/पासवर्ड-रीसेट लिंक के लिए सर्वोत्तम प्रथाएं क्या हैं उपयोगकर्ता उपयोगकर्ता खातों को सत्यापित करने या पासवर्ड रीसेट करने के लिए ईमेल भेजते हैं। मेरा मानना ​​है कि यह वही तरीका होना चाहिए और मैं संदर्भ और कार्यान्वयन के लिए पूछ रहा हूं।

एक आवेदन एक ईमेल में एक लिंक भेजने के लिए, उपयोगकर्ता के पते को सत्यापित करने के लिए मेरे विचार के अनुसार है, लिंक और लिंक के आवेदन के प्रसंस्करण निम्नलिखित विशेषताएं होनी चाहिए:

1. लिंक यूआरआई (http://host/path?nonce) अनुरोध में nonce शामिल है।
2. लिंक (GET) के बाद, उपयोगकर्ता को एक रूप प्रस्तुत किया गया है, वैकल्पिक रूप से nonce के साथ।
3. उपयोगकर्ता इनपुट (POST) की पुष्टि करता है।
4. सर्वर, अनुरोध और
   • चेकों इनपुट पैरामीटर प्राप्त करता
   • परिवर्तन करता है,
   • और अस्थायी रूप से अमान्य हो जाएगा।

यह HTTP RFC on Safe and Idempotent Methods प्रति सही होना चाहिए।

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

• क्या इस विषय पर संदर्भ हैं जो विचार को बेहतर तरीके से समझा सकते हैं और एक गैर-तकनीकी व्यक्ति (पत्रिकाओं, ब्लॉग, ... से सर्वोत्तम प्रथाओं) को भी समझ सकते हैं?
• क्या इस साइट को लागू करने वाले संदर्भ साइट (अधिमानतः लोकप्रिय और कई उपयोगकर्ताओं के साथ) हैं?
  • यदि नहीं, तो क्या दस्तावेज कारण या समकक्ष विकल्प हैं?

धन्यवाद,
Kariem

---

विवरण बख्शा

मैं मुख्य हिस्सा कम रखा है, लेकिन विवरण जो मैं था चारों ओर बहुत ज्यादा चर्चा कम करने के लिए जानबूझकर छोड़ दिया, मैं कुछ मान्यताओं को जोड़ूंगा:

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

---

नोट्स

OpenID और की तरह, सामान्य वेब अनुप्रयोगों के साथ

मानक उपयोगकर्ता खाता प्रबंधन (पासवर्ड, ईमेल ...) को लागू करने से राहत मिली हैं, लेकिन अभी भी कुछ ग्राहकों को चाहते हैं 'उनके अपने उपयोगकर्ता '

आश्चर्यजनक रूप से पर्याप्त मुझे एक संतोषजनक प्रश्न नहीं मिला है और न ही यहां जवाब दिया गया है। मैं अब तक क्या पाया है:

• Answer by Don in HTTP POST with URL query parameters — good idea or not?
• Question from Thomas -- When do you use POST and when do you use GET?

Answer 1

यह प्रश्न Implementing secure, unique “single-use” activation URLs in ASP.NET (C#) के समान है।

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

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

मैं मानना ​​है कि यह वास्तव में प्राप्त की idempotentness का उल्लंघन नहीं करता पसंद आया होगा, लेकिन दुर्भाग्य से यह करता है ... दूसरी ओर, आरएफसी प्राप्त idempotent होना चाहिए, इसकी एक नहीं करना चाहिए कहते हैं।इसलिए मैं इसे इस मामले में छोड़ दूंगा, और एक बार ऑटो-अमान्य लिंक से चिपके रहूंगा। (?)

तुम सच में गैर idempotent में मिल सख्त आरएफसी अनुपालन के लिए लक्ष्य करना चाहते हैं हैं, और नहीं हो जाता है, तो आप प्राप्त पेज पोस्ट ऑटो प्रस्तुत कर सकते हैं - उपाय बता की तरह का है कि बिट के आसपास आरएफसी, लेकिन कानूनी, और आपको उपयोगकर्ता को डबल-ऑप्टिन की आवश्यकता नहीं है, और आप उसे bugging नहीं कर रहे हैं ...

आपको वास्तव में प्रीलोडिंग के बारे में चिंता करने की ज़रूरत नहीं है (क्या आप सीएसआरएफ, या ब्राउज़र-अनुकूलक के बारे में बात कर रहे हैं?) ... सीएसआरएफ nonce की वजह से बेकार है, और अनुकूलक आमतौर पर प्रीलोड किए गए पृष्ठ पर जावास्क्रिप्ट (ऑटो-सबमिट करने के लिए प्रयुक्त) को संसाधित नहीं करते हैं।

Answer 2

मैं आम तौर पर आपसे सहमत हूँ कुछ संशोधन के साथ नीचे का सुझाव दिया।

1. उपयोगकर्ता आपकी साइट पर एक ईमेल प्रदान करता है।
2. सत्यापन ईमेल उपयोगकर्ताओं के लिए भेज दिया जाता है दो लिंक के साथ खाता: क) GUID के साथ पंजीकरण ख सत्यापित करने के लिए GUID के साथ एक लिंक) एक लिंक सत्यापन
3. अस्वीकार करने के लिए जब वे अपने ईमेल से पुष्टि यूआरऍल वे स्वचालित रूप से सत्यापित होते हैं और सत्यापन मार्गदर्शिका आपके सिस्टम में इस तरह चिह्नित होती है।
4. जब वे अपने ईमेल से अस्वीकृति यूआरएल पर जाते हैं तो उन्हें स्वचालित सत्यापन की कतार से स्वचालित रूप से हटा दिया जाता है, लेकिन अधिक महत्वपूर्ण बात यह है कि आप उपयोगकर्ता को यह बता सकते हैं कि आपको ईमेल पंजीकरण के लिए खेद है और उन्हें अपने ईमेल को हटाने जैसे अन्य विकल्प दें प्रणाली। यह आपके सिस्टम में मेरे ईमेल में प्रवेश करने वाले किसी भी कस्टम सेवा प्रकार की शिकायतों को रोक देगा ... blah blah blah।

हां, आपको यह मानना ​​चाहिए कि जब वे सत्यापन लिंक पर क्लिक करते हैं तो वे सत्यापित होते हैं। उन्हें पृष्ठ में दूसरे बटन पर क्लिक करना थोड़ा अधिक है और केवल स्टाइल पंजीकरण में डबल ऑप्टिमाइज़ के लिए आवश्यक है जहां आप पंजीकृत व्यक्ति को स्पैम करने की योजना बनाते हैं। मानक पंजीकरण/सत्यापन योजनाओं को आमतौर पर इसकी आवश्यकता नहीं होती है।

Answer 3

पासवर्ड रीसेट के बारे में:

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

प्रश्न में साइट की सुरक्षा आवश्यकताओं के आधार पर यह महत्वपूर्ण हो सकता है या नहीं भी हो सकता है, लेकिन साइट के उपयोगकर्ता के रूप में, मैं कम से कम ऐसे पासवर्ड रीसेट फ़ंक्शन को अक्षम करने में सक्षम होना चाहता हूं क्योंकि मैं इसे मानता हूं असुरक्षित।

मुझे this white paper मिला जो इस विषय पर चर्चा करता है।

कैसे एक सुरक्षित तरीके से ऐसा करने का लघु संस्करण:

1. खाता

   1. उपयोगकर्ता नाम के बारे में मुश्किल तथ्यों की आवश्यकता होती है।
   2. ईमेल पता।
   3. 10 अंकों का खाता नंबर या अन्य जानकारी जैसे सामाजिक सुरक्षा संख्या।

2. आवश्यकता उपयोगकर्ता जवाब कम से कम तीन पूर्वनिर्धारित सवाल (आपके द्वारा पूर्वनिर्धारित, उपयोगकर्ता अपने ही सवाल बना सकते हैं नहीं है) कि कि तुच्छ नहीं हो सकता। जैसा कि " आपकी पसंदीदा अवकाश स्थान" है, न कि "आपका पसंदीदा रंग क्या है"।

3. वैकल्पिक रूप से: एक पूर्वनिर्धारित ईमेल पता या सेल नंबर (एसएमएस) पर एक पुष्टिकरण कोड भेजें जिसे उपयोगकर्ता को इनपुट करना है।

4. उपयोगकर्ता को एक नया पासवर्ड इनपुट करने की अनुमति दें।