2008-12-21 9 views
16

इसके बारे में सोचने के बिना मैं बस इतना कहना चाहता हूं कि मुझे हर चरित्र की अनुमति देनी चाहिए। यह किसी भी मामले में धोया जाता है, और मैं उन लोगों को सीमित नहीं करना चाहता जो मजबूत पासवर्ड बनाना चाहते हैं।पासवर्ड में कौन से पात्रों को अनुमति देने के लिए अनुसरण करने के लिए सर्वोत्तम नियम क्या हैं?

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

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

वैसे भी, क्या लंबाई, अनुमत वर्णों और आगे के लिए कोई मानक सिफारिशें हैं?

मुझे यकीन है कि अगर यह मायने रखती है नहीं कर रहा हूँ, लेकिन मैं ASP.NET का उपयोग किया जाएगा डब्ल्यू/सी #

उत्तर

13

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

कुछ strong password generators एक हैश का उपयोग करें, इसलिए मैं एक लंबाई (512 या 1024) पर बहुत अधिक सीमा शामिल होना शामिल है। पासवर्ड जनरेटर आज 32-128 वर्णों के तार उत्पन्न करते हैं, लेकिन कौन जानता है कि अगले कुछ वर्षों में क्या हैश का उपयोग किया जाएगा।

+0

और मैं åäšÄÄÖ और अन्य गैर ASCII वर्णों का उपयोग करना चाहता हूं। यूनिकोड का उपयोग करने का समय। बस यूटीएफ -8 इसे एन्कोड करें और फिर इसे हैश करें। – some

+0

अच्छा बिंदु। मुझे किसी भी कारण से पता नहीं है कि यूनिकोड का उपयोग नहीं किया जाना चाहिए। –

+0

मैं यह भी तर्क दूंगा कि व्हाइटस्पेस को कम से कम यू +0020, पारंपरिक स्थान) की अनुमति दी जानी चाहिए, क्योंकि सुरक्षा के कारण - पासफ्रेज़ (पासवर्ड के विपरीत) का उपयोग करने के कारण बेहतर हो सकते हैं। –

3

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

8

गैर-ASCII वर्ण निश्चित रूप से सीमित डिवाइस (मोबाइल, कंसोल इत्यादि) पर पासवर्ड दर्ज करने की बात करते समय चीजों को कठिन बनाते हैं - लेकिन आमतौर पर असंभव नहीं होते हैं। तर्कसंगत रूप से यदि उपयोगकर्ता ऐसा करना चाहता है, तो आपको उन्हें देना चाहिए। उदाहरण के लिए, हैशिंग से पहले यूटीएफ -8 में एन्कोड उचित और सुसंगत चीज करने के लिए काफी आसान है। आपको केवल कठिनाइयों का सामना करना पड़ेगा यदि कुछ इनपुट डिवाइस ने पात्रों को एक रचना के रूप में भेजा (उदा। "ई तीव्र" के बजाय ई + तीव्र उच्चारण) - लेकिन मुझे संदेह है कि वास्तविक जीवन में ऐसा नहीं होगा। (आप अपने आप को सब कुछ विघटित कर सकते हैं, लेकिन किनारे के मामले में जाने में बहुत परेशानी होगी।)

मैं इसे प्रिंट करने योग्य वर्णों तक सीमित कर दूंगा। वास्तव में पासवर्ड में टैब्स, फॉर्म फ़ीड्स इत्यादि रखना परेशानी के लिए पूछ रहा है।

+0

जब तक यह इसे उसी तरह से रखता है, तो यह एक समस्या नहीं होनी चाहिए, है ना? – some

+0

समस्या यह है कि पात्रों को मानव आंखों द्वारा प्रतिष्ठित/पहचाना नहीं जा सकता है, यह पता लगाने/डीबग करना मुश्किल हो जाएगा। – PolyThinker

+0

टैब कैरेक्टर में अधिकांश ब्राउज़रों पर एक विशेष "स्वतः पूर्ण" कार्रवाई होती है। क्या होगा यदि उपयोगकर्ता इसे टाइप नहीं कर सके? उन्हें नोटपैड से कॉपी और पेस्ट करने के लिए कहें? – chakrit

1

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

गैर- ASCII वर्ण के लिए

, मुझे लगता है कि नहीं दिख रहा है एक और अधिक कठिन समस्या के रूप में यदि आपके इनपुट सही ढंग से एक द्विआधारी स्ट्रिंग के रूप में प्रतिनिधित्व किया जा सकता है (और पाठ नहीं रूप) है, जो फिर अपने हैश समारोह या करने के लिए पारित हो जाता है मुख्य जनरेटर, आदि

2

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

+1

दूसरी तरफ, वर्ण जो "प्रवेश करने में बहुत कठिन" हैं, वास्तव में एक सुरक्षा सुविधा हो सकती है। – devios1

2

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

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

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

+0

पासवर्ड स्पष्ट टेक्स्ट में कभी भी संग्रहीत नहीं किए जाने चाहिए। उन्हें अधिमानतः धोया जाना चाहिए, और फिर वे सभी एक ही लंबाई के हैं। – some

2

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

तो, जब तक आप एक चरित्र md5 या sha1 कर सकते हैं, इसे स्वीकार किया जाना चाहिए।

+0

असल में मैं SHA-512 –

1

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

(बेशक, अगर तुम सब कुछ, उपयोगकर्ताओं के 99% अभी भी अपने पालतू जानवर का नाम उनके पासवर्ड के रूप में इस्तेमाल करेगा ... की अनुमति देते हैं)

-2

अंततः आप एक confirmlation ईमेल में स्पष्ट पासवर्ड का प्रिंट आउट करना पड़ सकता है आपके उपयोगकर्ताओं को भेजा गया।

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

यह सब "प्रिंट करने योग्य" एएससीआई वर्णों में वजन का होता है।

+3

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

+1

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