security - बाद में सादे पाठ पुनर्प्राप्ति के लिए मैं नैतिक रूप से उपयोगकर्ता पासवर्ड संग्रहण कैसे पहुंचूं?




password-encryption password-storage (18)

आधे रास्ते के बारे में कैसे?

पासवर्ड को एक मजबूत एन्क्रिप्शन के साथ स्टोर करें, और रीसेट सक्षम न करें।

पासवर्ड रीसेट करने के बजाय, एक बार पासवर्ड भेजने की अनुमति दें (जैसे ही पहला लॉगऑन होता है)। उपयोगकर्ता को तब भी जो भी पासवर्ड चाहिए वो बदल दें (पिछला एक, अगर वे चुनते हैं)।

आप इसे पासवर्ड रीसेट करने के लिए एक सुरक्षित तंत्र के रूप में "बेचना" कर सकते हैं।

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

जब मैं इसे लड़ नहीं सकता (या जीत नहीं सकता) तो मैं हमेशा पासवर्ड को एन्कोड करता हूं ताकि कम से कम, डेटाबेस में सादे टेक्स्ट के रूप में संग्रहीत न हो - हालांकि मुझे पता है कि अगर मेरा डीबी हैक हो जाता है अपराधी के लिए पासवर्ड को क्रैक करने में ज्यादा कुछ नहीं लगेगा, जिससे मुझे असहज हो जाता है।

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

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

बाउंटी के लिए अतिरिक्त जानकारी

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

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

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

सभी को धन्यवाद

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

हमेशा के रूप में लगभग 5 उत्तरों थे कि मैं अलग-अलग कारणों से सही के रूप में चिह्नित करना चाहता हूं, लेकिन मुझे सबसे अच्छा चुनना पड़ा - बाकी सभी को +1 मिला। सबको धन्यवाद!

इसके अलावा, स्टैक समुदाय में हर किसी के लिए धन्यवाद जिन्होंने इस प्रश्न के लिए मतदान किया और / या इसे पसंदीदा के रूप में चिह्नित किया। मैं तारीफ के रूप में 100 वोट वोट मारता हूं और उम्मीद करता हूं कि इस चर्चा ने किसी और की चिंता के साथ किसी और की मदद की है।


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

मुझे लगता है कि यह वास्तव में विंडोज रिकवरी एजेंट के काम के समान ही है।

  • पासवर्ड एन्क्रिप्टेड संग्रहित हैं
  • लोग सादे टेक्स्ट में डिक्रिप्ट किए बिना लॉगिन कर सकते हैं
  • पासवर्ड को सादे टेक्स्ट में पुनर्प्राप्त किया जा सकता है, लेकिन केवल एक निजी कुंजी के साथ, जिसे सिस्टम के बाहर संग्रहीत किया जा सकता है (बैंक में सुरक्षित, यदि आप चाहते हैं)।

इस भाग को पढ़ने के बाद:

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

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

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

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

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

टिप्पणी करें कि मेरे सुझाव पर क्या बुरा है और मैं एक समाधान का सुझाव दूंगा जो वास्तव में वही करता है जो आप शुरू में चाहते थे।


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

यदि आप सादे टेक्स्ट पासवर्ड कभी नहीं देखते हैं, तो पुनर्प्राप्ति का सवाल उठता नहीं है।

साथ ही, मैं (वेब ​​से) इकट्ठा करता हूं कि (कथित तौर पर) कुछ एल्गोरिदम जैसे कि एमडी 5 को सुरक्षित नहीं माना जाता है। मेरे पास खुद का न्याय करने का कोई तरीका नहीं है, लेकिन यह विचार करने के लिए कुछ है।


उपयोगकर्ता के सुरक्षा प्रश्न का उत्तर एन्क्रिप्शन कुंजी का एक हिस्सा बनाएं, और सुरक्षा प्रश्न के उत्तर को सादा पाठ के रूप में संग्रहीत न करें (इसके बजाय हैश)


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

तो कदम होंगे:

  1. पासवर्ड को सेट किए बिना उपयोगकर्ता आपकी साइट पर (निश्चित रूप से एसएसएल पर) पंजीकरण करता है। उन्हें स्वचालित रूप से लॉग इन करें या अस्थायी पासवर्ड प्रदान करें।
  2. आप भावी पासवर्ड पुनर्प्राप्ति के लिए अपनी सार्वजनिक पीजीपी कुंजी स्टोर करने की पेशकश करते हैं।
  3. वे अपनी सार्वजनिक पीजीपी कुंजी अपलोड करते हैं।
  4. आप उन्हें एक नया पासवर्ड सेट करने के लिए कहते हैं।
  5. वे अपना पासवर्ड जमा करते हैं।
  6. आपके पास सबसे अच्छा पासवर्ड हैशिंग एल्गोरिदम उपलब्ध है (उदाहरण के लिए bcrypt) का उपयोग कर पासवर्ड हैश। अगली लॉग-इन को सत्यापित करते समय इसका उपयोग करें।
  7. आप पासवर्ड को सार्वजनिक कुंजी से एन्क्रिप्ट करते हैं, और अलग से स्टोर करते हैं।

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


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

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

अब किसी को पासवर्ड और इसके संदर्भ (साइट आईडी + उपयोगकर्ता आईडी + "पास-ए") प्राप्त करने के लिए, उसे यह करना है:

  1. एक ("पास-ए", उपयोगकर्ता आईडी) जोड़ी या जोड़े प्राप्त करने के लिए वेबसाइट के डीबी को हैक करें।
  2. कुछ कॉन्फ़िगरेशन फ़ाइल से वेबसाइट की आईडी प्राप्त करें
  3. रिमोट पासवर्ड डीबी में ढूंढें और हैक करें।

आप पासवर्ड पुनर्प्राप्ति सेवा की पहुंच को नियंत्रित कर सकते हैं (केवल एक सुरक्षित वेब सेवा के रूप में इसे बेनकाब करें, प्रति दिन केवल कुछ निश्चित पासवर्ड पुनर्प्राप्ति की अनुमति दें, इसे मैन्युअल रूप से करें, आदि), और यहां तक ​​कि इस "विशेष सुरक्षा व्यवस्था" के लिए अतिरिक्त शुल्क भी लें।
पासवर्ड पुनर्प्राप्ति डीबी सर्वर बहुत छिपा हुआ है क्योंकि यह कई कार्यों की सेवा नहीं करता है और बेहतर सुरक्षित हो सकता है (आप अनुमतियों, प्रक्रियाओं और सेवाओं को कसकर तैयार कर सकते हैं)।

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


कल्पना कीजिए कि किसी ने निर्माण के लिए एक बड़ी इमारत शुरू की है - एक बार, मान लें - और निम्नलिखित बातचीत होती है:

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

क्या आर्किटेक्ट तब पूछता है कि बिना किसी आग के बाहर इस भवन को नैतिक रूप से कैसे बनाया जाए?

इमारत और इंजीनियरिंग उद्योग में, वार्तालाप इस तरह खत्म होने की संभावना है:

वास्तुकार: यह इमारत अग्नि निकास के बिना नहीं बनाई जा सकती है। आप किसी भी अन्य लाइसेंस प्राप्त पेशेवर के पास जा सकते हैं और वह आपको वही बात बताएगा। मैं अब जा रहा हूँ; जब आप सहयोग करने के लिए तैयार हों तो मुझे वापस कॉल करें।

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

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

पुनर्प्राप्ति योग्य रूप में पासवर्ड स्टोर करने के लिए कोई नैतिक या जिम्मेदार तरीका नहीं है। अवधि।


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

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

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

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

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


क्षमा करें, लेकिन जब तक आपके पास अपना पासवर्ड डीकोड करने का कोई तरीका है, तब तक यह सुरक्षित होने वाला कोई तरीका नहीं है। इसे कड़वाहट से लड़ो, और यदि आप हार जाते हैं, सीवाईए।


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


प्रश्न पर मैंने टिप्पणी की टिप्पणी के अनुसार:
लगभग हर किसी के द्वारा एक महत्वपूर्ण बिंदु बहुत चमक गया है ... मेरी प्रारंभिक प्रतिक्रिया @ माइकल ब्रूक्स के समान ही थी, जब तक मुझे एहसास नहीं हुआ, जैसे कि @stefanw, कि यहां मुद्दा तोड़ दिया गया है, लेकिन ये वे हैं जो वे हैं।
लेकिन फिर, यह मेरे लिए हुआ कि शायद यह मामला भी न हो! यहां लापता बिंदु, एप्लिकेशन की संपत्ति का अस्पष्ट मूल्य है। बस, एक कम मूल्य प्रणाली के लिए, एक पूरी तरह से सुरक्षित प्रमाणीकरण तंत्र, शामिल सभी प्रक्रियाओं के साथ, अधिक सुरक्षा होगी, और गलत सुरक्षा विकल्प।
जाहिर है, एक बैंक के लिए, "सर्वोत्तम प्रथाओं" जरूरी हैं, और नैतिक रूप से सीडब्ल्यूई -257 का उल्लंघन करने का कोई तरीका नहीं है। लेकिन कम मूल्य प्रणालियों के बारे में सोचना आसान है जहां यह सिर्फ इसके लायक नहीं है (लेकिन एक सरल पासवर्ड अभी भी आवश्यक है)।

यह याद रखना महत्वपूर्ण है कि सच्ची सुरक्षा विशेषज्ञता उचित ट्रेडऑफ ढूंढने में है, न कि "सर्वोत्तम व्यवहार" को कुचलने में, जो कोई भी ऑनलाइन पढ़ सकता है।

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

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

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

हालांकि, प्रश्न का क्रूक्स सिद्धांत के चारों ओर है , क्या ऐसी कोई स्थिति है जहां इसे रोकने के लिए आवश्यक नहीं हो सकता है , और यदि हां, तो स्थिति के लिए उचित तरीके से सही तरीके से ऐसा कैसे करें।

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

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

दरअसल, इस तरह हम हवाईअड्डा सुरक्षा की हास्यास्पदता प्राप्त करते हैं।

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

वैसे भी।
तो यहां हमारे मुख्य जोखिम क्या हैं, अगर हम एक-तरफा हैश का उपयोग करने के बजाय पासवर्ड को एन्क्रिप्ट करते हैं?

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

हममम।

क्या यहां कुछ भी आपको लगता है?

यह होना चाहिए।

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

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

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

तो, मेरे प्यारे सुरक्षा विशेषज्ञ, एक बूढ़े औरत के रूप में वेंडी के लिए पूछते थे, "जोखिम कहाँ है?"

ऊपर उठाए गए कुछ मुद्दों के जवाब में कुछ और मुद्दे:

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

वाह। कितनी लंबी पोस्ट ...
लेकिन अपने मूल प्रश्न का उत्तर देने के लिए, @ शेन:

  • ग्राहकों को चीजों को करने का उचित तरीका बताएं।
  • अगर वह अभी भी जोर देता है, तो कुछ और बताएं, जोर देकर बहस करें। यदि आवश्यक हो तो एक टैंट्रम फेंको।
  • उसे व्यापार जोखिम की व्याख्या करें। विवरण अच्छे हैं, आंकड़े बेहतर हैं, एक लाइव डेमो आमतौर पर सबसे अच्छा होता है।
  • अगर वह अभी भी जोर देकर कहते हैं, और वैध व्यावसायिक कारण प्रस्तुत करता है - यह आपके लिए एक निर्णय कॉल करने का समय है:
    क्या यह साइट कम-से-कम मूल्य है? क्या यह वास्तव में एक वैध व्यापार मामला है? क्या यह आपके लिए पर्याप्त है? क्या कोई अन्य जोखिम नहीं है जिसे आप विचार कर सकते हैं, जो वैध व्यावसायिक कारणों से अधिक होगा? (और निश्चित रूप से, ग्राहक एक दुर्भावनापूर्ण साइट नहीं है, लेकिन वह duh है)।
    यदि ऐसा है, तो बस आगे बढ़ें। आवश्यक प्रक्रिया को रखने के लिए प्रयास, घर्षण, और खोए गए उपयोग (इस अनुमानित स्थिति में) के लायक नहीं है। कोई अन्य निर्णय (फिर से, इस स्थिति में) एक बुरा व्यापार है।

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


बाद में सादा पाठ पुनर्प्राप्ति के लिए आप नैतिक रूप से पासवर्ड संग्रहीत नहीं कर सकते हैं। यह इतना सरल है। यहां तक ​​कि जॉन स्कीट बाद में सादा पाठ पुनर्प्राप्ति के लिए पासवर्ड को नैतिक रूप से संग्रहीत नहीं कर सकता है। यदि आपके उपयोगकर्ता किसी भी तरह या अन्य सादे पाठ में पासवर्ड पुनर्प्राप्त कर सकते हैं, तो संभावित रूप से भी एक हैकर जो आपके कोड में सुरक्षा भेद्यता पाता है। और यह सिर्फ एक उपयोगकर्ता का पासवर्ड समझौता नहीं किया जा रहा है, लेकिन उनमें से सभी।

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

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

इस विषय पर मैंने लिखा कुछ ब्लॉग पोस्ट यहां दिए गए हैं:

अपडेट करें: अब हम उन कंपनियों के खिलाफ मुकदमे और मुकदमेबाजी शुरू कर रहे हैं जो अपने उपयोगकर्ताओं के पासवर्ड को सही तरीके से सुरक्षित करने में विफल रहते हैं। उदाहरण: लिंक्डइन $ 5 मिलियन क्लास एक्शन मुकदमा के साथ थप्पड़ मारा ; सोनी ने प्लेस्टेशन डेटा हैक पर £ 250,000 जुर्माना लगाया । अगर मुझे सही ढंग से याद किया जाता है, तो लिंक्डइन वास्तव में अपने उपयोगकर्ताओं के पासवर्ड एन्क्रिप्ट कर रहा था, लेकिन जिस एन्क्रिप्शन का उपयोग कर रहा था वह प्रभावी होने के लिए बहुत कमजोर था।


माइकल ब्रूक्स सीडब्ल्यूई -257 के बारे में बल्कि मुखर हैं - तथ्य यह है कि आप जिस भी विधि का उपयोग करते हैं, आप (प्रशासक) अभी भी पासवर्ड पुनर्प्राप्त कर सकते हैं। तो इन विकल्पों के बारे में कैसे:

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

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


मेरे साथ भी वही दिक्कत है। और इसी तरह मैं हमेशा सोचता हूं कि कोई मेरी प्रणाली को हैक करता है, यह "अगर" का मामला नहीं है बल्कि "कब" है।

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

  • इसके साथ एन्क्रिप्ट करें: openssl_encrypt (स्ट्रिंग $ डेटा, स्ट्रिंग $ विधि, स्ट्रिंग $ पासवर्ड)
  • डेटा तर्क :
    • संवेदनशील जानकारी (जैसे उपयोगकर्ता पासवर्ड)
    • यदि आवश्यक हो तो serialize, उदाहरण के लिए यदि जानकारी एकाधिक संवेदनशील जानकारी जैसे डेटा की एक सरणी है
  • पासवर्ड तर्क : ऐसी जानकारी का उपयोग करें जो केवल उपयोगकर्ता को ही पता है:
    • उपयोगकर्ता लाइसेंस प्लेट
    • सामाजिक सुरक्षा संख्या
    • उपयोगकर्ता फोन नंबर
    • उपयोगकर्ता मां का नाम
    • एक यादृच्छिक स्ट्रिंग ईमेल और / या पंजीकरण समय पर एसएमएस द्वारा भेज दी जाती है
  • विधि तर्क :
    • एक सिफर विधि चुनें, जैसे "एईएस -256-सीबीसी"
  • डेटाबेस पर "पासवर्ड" तर्क में उपयोग की गई जानकारी को कभी भी स्टोर न करें (या सिस्टम में जो भी जगह हो)

इस डेटा को पुनः प्राप्त करने के लिए आवश्यक होने पर बस "openssl_decrypt ()" फ़ंक्शन का उपयोग करें और उपयोगकर्ता को उत्तर के लिए पूछें। उदाहरण: "अपना पासवर्ड प्राप्त करने के लिए प्रश्न का उत्तर दें: आपका सेलफोन नंबर क्या है?"

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

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


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

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

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


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


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





password-storage