क्या होगा यदि क्लाइंट को पासवर्ड पुनः प्राप्त करने की क्षमता की आवश्यकता है?

Question

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

इसलिए सभी को वास्तव में उपयोगकर्ता तालिका की प्रतिलिपि बनाने और एन्क्रिप्शन असेंबली (डेटाबेस उत्पादन पहुंच वाले किसी भी व्यक्ति) की प्रतिलिपि बनाने और फिर उनके लिए 100,000 ईमेल पते और उनके लिए संभावित पासवर्ड तक पहुंचने की आवश्यकता होगी।

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

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

मुझे क्या करना चाहिए? मैंने पहली बार में पासवर्ड सिस्टम का निर्माण नहीं किया, इसलिए ऐसा नहीं है कि मुझे दोषी ठहराया जा सकता है अगर कुछ भी गलत होता है। दूसरी ओर, मैं इसके बारे में अच्छा महसूस नहीं करता हूं और मैं 100,000 संभावित ईमेल लॉगनों तक पहुंच भी नहीं चाहता हूं।

Comments

"जो उन्होंने कहा है, उन्हें आवश्यकता है"। और वे झूठ भी बोलते हैं।

— 4

तुम जो भी करो, बस अपनी गांड को ढक लो।

— जॉब

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

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

नए PSN का निर्माण? ;-)

— वार्टेक

तो "सोनी" के साथ इस प्रश्न को पुनः प्राप्त करने के लिए लुभाना।

— जोएल एथरटन

Answer 1

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

पासवर्ड डेटाबेस को सुरक्षित रखना व्यावसायिक चिंता नहीं है, यह एक तकनीकी चिंता है। ऐसा नहीं करना एक बग है। यदि व्यवसाय सुरक्षा का एक कार्यक्षमता व्यापार के रूप में सोचता है, तो सुरक्षा खो जाएगी। आपको उन्हें इस तरह से सोचने का कोई कारण नहीं देना चाहिए।

Comments

दूसरे पैराग्राफ के लिए +1 और "ऐसा नहीं करना बग है"। काश हर डेवलपर ऐसा समझ पाता।

— आर्सेनी मौरज़ेंको

+1 के लिए "पासवर्ड डेटाबेस को सुरक्षित रखना एक व्यावसायिक चिंता नहीं है, यह एक तकनीकी चिंता है।" । / मुझे लगता है कि कुछ निर्णय, इस तरह, विशुद्ध रूप से तकनीकी होना चाहिए।

— मचाडो

मुझे अभी भी लगता है कि एक अन्य उपयोगकर्ता के रूप में लॉगिंग करने वाले प्रशासक एक सुरक्षित प्रणाली के गैर-प्रतिकारक पहलू का उल्लंघन करते हैं जो कि ज्यादातर सरकारी नीतियों का कहना है कि उन्हें कार्यकारी कार्यालयों से एक जनादेश के रूप में - की आवश्यकता है।

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

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

— corsiKa

Answer 2

आपको उन्हें यह समझाने की आवश्यकता है कि वास्तव में उन्हें इस घटना में नागरिक रूप से उत्तरदायी होने की आवश्यकता नहीं है कि उनका सर्वर टूट गया है। न ही उन्हें किसी सूचित यूजरबेस से बैकलैश की जरूरत होती है जो यह महसूस करता है कि वे लापरवाही कर रहे हैं।

कभी-कभी ऐसे स्पष्ट मामले होते हैं जहां एक पक्ष गलत होता है और दूसरा सही होता है। यह उस काल में से एक है।

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

Answer 3

तथ्य: लोग कई साइटों पर एक ही पासवर्ड का उपयोग करते हैं

आपके बॉस को शायद एहसास नहीं है कि लोग अक्सर सभी प्रकार की सेवाओं (बैंकिंग या फेसबुक और इसी तरह) के लिए एक एकल पासवर्ड (या उनमें से बहुत सीमित सेट) का उपयोग करते हैं। यदि उपयोगकर्ता आपके सिस्टम में अपना पासवर्ड बदल सकते हैं, तो वे अत्यधिक संभावना है कि वे उसी पासवर्ड का उपयोग कहीं और करते हैं।

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

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

खाता प्रतिनिधि को कैसे लागू किया जाए

आपके आवेदन में खाता प्रतिनिधि अलग से किया जाना चाहिए।

1. Admins को स्वयं के रूप में लॉग इन करना चाहिए और फिर
2. या तो (चूंकि वे विशेषाधिकार प्राप्त उपयोगकर्ता हैं)
   • केवल उपयोगकर्ता नाम दर्ज करें या
   • उनमें से लॉग इन करने के लिए एक सूची से एक निश्चित उपयोगकर्ता का चयन करें

यह निश्चित रूप से उपयोगकर्ता नाम + पासवर्ड संयोजन के साथ लॉग इन करके नहीं किया जाना चाहिए ।

यह सच है कि प्रत्यायोजित लॉगऑन की अनुमति देने के लिए नई स्क्रीन विकसित की जानी चाहिए, लेकिन फिर भी।

क्यों बेहतर है लॉगऑन प्रत्यायोजित?

आप अतिरिक्त कार्यक्षमता प्रदान कर सकते हैं जो यह स्पष्ट कर देगा कि कुछ उपयोगकर्ता की ओर से व्यवस्थापक द्वारा कुछ कार्रवाई की गई है (जो अब आप नहीं जान सकते क्योंकि Admins भगवान के रूप में कार्य करते हैं और जो कोई भी ऐसा कर सकता है और वह काम कर सकता है जो चोट पहुंचा सकता है वास्तविक कर्मचारी प्रतिष्ठा)।

आपको इस बात से सहमत होना होगा कि लोग गलतियाँ करते हैं। आदिम लोग भी हैं। और अगर वे किसी और की ओर से गलती करते हैं तो वे उन्हें दोष देने की कोशिश करेंगे। मैं इसके बारे में 100% निश्चित हूं। यह गैर-व्यवस्थापक उपयोगकर्ताओं के लिए सुरक्षित बना देगा ताकि उनकी वास्तविक-विश्व प्रतिष्ठा अन्य लोगों की गलतियों से ग्रस्त न हो।

Answer 4

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

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

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

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

Comments

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

— rjzii

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

— रोबोशॉप

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

— केट ग्रेगोरी

@Rob Z: या, एक अन्य उदाहरण, मुझे याद है कि गॉकर के डेटाबेस से छेड़छाड़ करने के बाद, बोट्स को ट्विटर पर उपयोगकर्ता नाम / पासवर्ड कॉम्बो की कोशिश करने के लिए लिखा गया था, और फिर उन सभी खातों से स्पैम ट्वीट पोस्ट किए गए थे जो टूट गए थे।

— कार्सन 63000

Answer 5

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

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

यहां तक ​​कि अगर आप मानते हैं कि सभी प्रवेश विश्वसनीय हैं, तो यह एक व्यवस्थापक पासवर्ड के विनाशकारी भी बनाता है।

इनके संचालन के लिए आपको उपयोगकर्ता के पासवर्ड की भी आवश्यकता नहीं है। आप एक sudoतरह की सुविधा लागू कर सकते हैं।

Answer 6

यह संभवतः संघीय सरकार की प्रणाली नहीं हो सकती क्योंकि FIPS और FISMA आवश्यकताएं पासवर्ड के लिए प्रतिवर्ती एन्क्रिप्शन को रोकेंगी, और मूल विभाग उन्हें चांद पर थप्पड़ मार देगा।

और एक मजबूत सुरक्षा नीति (हैशिंग पासवर्ड ताकि उन्हें आसानी से प्राप्त नहीं किया जा सके) को लागू करने के लिए, मुझे उनके लिए मौजूदा कार्यक्षमता को हटाना होगा।

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

इसके अलावा, वास्तव में व्यवस्थापक उपयोगकर्ताओं के लिए उपयोगकर्ता के पासवर्ड को पुनः प्राप्त करने और उन्हें करने के लिए (जो उन्होंने कहा है, उन्हें आवश्यकता होती है) करने के लिए एप्लिकेशन के भीतर मौजूदा कार्यक्षमता है।

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

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

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

सोनी नवीनतम सुरक्षा उल्लंघन वाली कंपनियों में से एक थी। यह सिर्फ PS3 नेटवर्क नहीं था, यह 25,000,000 से अधिक नामों, पते, क्रेडिट कार्ड नंबर, उपयोगकर्ता नाम और पासवर्ड के साथ कहीं भी कुल मिलाकर, MMORPG गेम का उनका नेटवर्क था। आप विश्वास कर सकते हैं कि मैं बिल्कुल भी खुश नहीं हूं (मैं अपना सदाबहार चाहता हूं!)।

Comments

प्लेस्टेशन नेटवर्क के लिए 75 मिलियन, सोनी ऑनलाइन एंटरटेनमेंट के लिए 25 मिलियन अकाउंट हैं। मुझे यकीन नहीं है कि मुझे विश्वास है कि इस लीक में केवल 12,000 क्रेडिट कार्ड सामने आए थे। wired.com/gamelife/2011/05/sony-online-entertain-hack सप्ताहांत तक कोई सदाबहार नहीं। शायद।

— तंगुरेना

Answer 7

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

बेशक जब आप एक सरकारी परियोजना का उल्लेख करते हैं, अगर इन प्रथाओं के कारण नागरिकों की निजी जानकारी जोखिम में है, तो यह सार्वजनिक हित को कम कर रहा है।

Comments

और अगर यह एक सरकारी परियोजना है, तो यह भी कानूनी नहीं हो सकता है कि यह असुरक्षित हो।

— मोनिका

Answer 8

आप ईमेल और डिक्रिप्ट किए गए पासवर्ड की सूची का प्रिंट आउट ले सकते हैं और इसे कवर पृष्ठ पर एक बड़ी चेतावनी के साथ अपने बॉस के डेस्क पर रख सकते हैं: "गोपनीय"

फ़ॉन्ट को छोटा करें ताकि कागज को बेकार न करें।

आप उन्हें यह भी दिखा सकते हैं कि बगज़िला कैसे लोगों को अपने पासवर्ड का उपयोग किए बिना प्रवेश करने की अनुमति देता है।

Comments

बॉस को एक उदाहरण देने के लिए +1। कोई यह तर्क दे सकता है कि डेस्क पर सिर्फ बॉस और उनके परिवार / परिचितों के पासवर्ड डालना बेहतर होगा।

— मचाडो

Answer 9

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

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

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

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

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

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

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

Answer 10

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

पासवर्ड के लिए प्रतिवर्ती एन्क्रिप्शन का उपयोग करने की वास्तव में कोई आवश्यकता नहीं है। यदि किसी उपयोगकर्ता आईडी को ख़राब करने का कोई वैध कारण है, तो यह किया जा सकता है:

• वर्तमान पासवर्ड हैश को स्टोर करें
• एक ज्ञात मूल्य के साथ प्रतिस्थापित करना
• (फेक-ऑडिट-ट्रेल-एक्टिविटी, उदाहरण के लिए ऑफशोर अकाउंट में फंड ट्रांसफर करें)
• मूल पासवर्ड हैश बदलें

मैं अंतिम चरण के साथ असहज हो जाऊंगा - जो भी सिस्टम पर प्रतिरूपण किया गया था उसे पता होना चाहिए कि ऐसा हुआ है। हो सकता है कि आप यह कहकर व्यवसाय को राजी कर सकें कि "यह आपके बैंक की तरह है जो मुझे आपके ज्ञान के बिना आपके खाते तक पहुंचने देता है, क्योंकि मैंने कहा कि मुझे इसकी आवश्यकता है"

Comments

ऑडिट ट्रेल के लिए +1, दिन-प्रतिदिन के काम के साथ-साथ आपदाओं के लिए बहुत महत्वपूर्ण है। लोग शायद ही कभी सुरक्षा या ऑडिटिंग को गंभीरता से लेते हैं।

— डेव

Answer 11

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

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

Comments

यह पूर्ण उत्तर नहीं है - आप ऐसा करने की लागत को कैसे उचित ठहराते हैं? यदि व्यवसाय यह नहीं मानता है कि यह इसके लायक है, तो कर्मचारी उच्च प्राथमिकता वाली वस्तुओं पर ध्यान न देकर अपनी नौकरी को जोखिम में डाल देगा।

— निकोल

@ रीनेसिस - सुरक्षा की लागत वापस अर्जित की जाती है जब आपके सिस्टम से समझौता नहीं किया जाता है या समझौता नहीं किया जाता है, लेकिन मूल्य का कुछ भी नहीं खोया जाता है। कंपनी को एक सुरक्षा उन्मुख मानसिकता रखने की आवश्यकता है या यह एक कठिन लड़ाई होगी।

— rjzii

@Rob Z - हाँ, और मुझे लगता है कि सवाल यह है कि उस मानसिकता को कैसे प्राप्त किया जाए। स्पष्ट रूप से, व्यवसाय यह नहीं मानता कि जोखिम (या लागत, या दोनों) है।

— निकोल

@RoboShop नहीं, यदि पासवर्ड पुनर्प्राप्ति योग्य है तो यह असुरक्षित है और आप (या आपकी कंपनी) उद्योग मानक सर्वोत्तम प्रथाओं का पालन नहीं करके लापरवाही बरत रहे हैं।

— रीन हेनरिक

यदि आप हैश के माध्यम से लॉग इन कर सकते हैं, तो पासवर्ड को हैशिंग के मुख्य उद्देश्य से तुरंत समझौता किया जाता है। मेरा जवाब खड़ा है। यह मत करो। यह गलत है।

— रीन हेनरिच

Answer 12

वर्तमान घटनाओं (एप्सिलॉन डेटा लीक और प्लेस्टेशन नेटवर्क डेटा लीक) को ध्यान में रखते हुए, किसी को उम्मीद होगी कि समस्याएं स्पष्ट रूप से स्पष्ट होंगी।

कभी-कभी, हालाँकि, एक डेवलपर के रूप में आप केवल नीति को प्रभावित नहीं कर सकते हैं।

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

Answer 13

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

Comments

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

— रॉबर्ट कोरिटनिक

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

— मोनिका को 4'11

Answer 14

आमतौर पर व्यवस्थापक का उपयोगकर्ता पासवर्ड देखने का कारण यह होता है कि वे इसे खो देते हैं, वे उपयोगकर्ता को दे सकते हैं। जहाँ तक मैं बता सकता हूँ, विंडोज़ प्रशासक को पासवर्ड देखने नहीं देता है - तो आपका आवेदन क्यों होना चाहिए? गृह एन्क्रिप्शन लाइब्रेरी में कोई भी टूटना निश्चित है क्योंकि मुझे यकीन है कि जिसने भी लिखा है वह एनएसए के लिए काम नहीं करता है।

Comments

बेशक, आप मानते हैं कि प्रश्न पूछने वाला एनएसए के लिए काम नहीं करता है।

— क्रिस्टोफर महान