क्या मुझे पासवर्ड पर अधिकतम लंबाई लागू करनी चाहिए?

162

मैं समझ सकता हूं कि पासवर्ड पर एक न्यूनतम लंबाई लगाने से बहुत कुछ समझ में आता है (उपयोगकर्ताओं को खुद से बचाने के लिए), लेकिन मेरे बैंक की एक आवश्यकता है कि पासवर्ड 6 और 8 वर्णों के बीच लंबे हों, और मुझे आश्चर्य हुआ ...

यह सिर्फ जानवर बल के हमलों के लिए आसान नहीं होगा? (खराब)
क्या इसका मतलब यह है कि मेरे पासवर्ड को अनएन्क्रिप्टेड स्टोर किया जा रहा है? (खराब)

अगर कोई (उम्मीद के साथ) उनके लिए काम करने वाले कुछ अच्छे आईटी सुरक्षा पेशेवर अधिकतम पासवर्ड लंबाई लगा रहे हैं, तो क्या मुझे भी ऐसा करने के बारे में सोचना चाहिए? इसके पक्ष / विपक्ष क्या हैं?

security encryption passwords

— nickf
स्रोत

16

लगभग निश्चित रूप से एक "तीन हमले और आप बाहर हैं" नीति है, जो एक क्रूर बल के हमले के खतरे को समाप्त करती है।

— स्टु थॉम्पसन

23

गैर-विरासत प्रणालियों के लिए इसके लिए कोई बहाना नहीं है, जैसे कि आधुनिक समय की वेबसाइटें।

— मपराज

7

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

— मुझे फोन करें स्टीव

17

विश्वविद्यालय में दाखिला लेने वाले को मूर्खतापूर्ण पासवर्ड नियमों में नामांकित किया गया है: केवल 8 चार्ट, कम से कम 1 नंबर, लेकिन पासवर्ड की शुरुआत या अंत में नहीं, कीबोर्ड की 2 ऊपरी पंक्तियों आदि से चार्ट की आवश्यकता होती है आदि। अंत में वे इन नियमों को लागू करके आसान बनाते हैं। मुझे पता है कि तुम मूर्ख हो, लेकिन कृपया इस तरह मूर्खतापूर्ण नियम मत करो! (बस इसे अपने सिस्टम :) से बाहर निकलना था)

— cwap

17

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

— रोमन स्टार्कोव

193

पासवर्ड 32, 40, 128, जो भी लम्बाई हैशेड हैं। न्यूनतम लंबाई के लिए एकमात्र कारण पासवर्ड का अनुमान लगाना आसान है। अधिकतम लंबाई का कोई उद्देश्य नहीं है।

यदि आप अधिकतम लंबाई लगाते हैं तो अनिवार्य XKCD यह समझाता है कि आप अपने उपयोगकर्ता को असंतुष्ट क्यों कर रहे हैं:

— epochwolf
स्रोत

6

शायद एक बैंक पासवर्ड को सीमित करने का विकल्प चुन सकता है क्योंकि एटीएम पर आप 8 वर्णों से अधिक नहीं कह सकते हैं।

— एंड्रे चलेला

11

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

— निक सिप

39

अफसोस की बात है कि पासवर्ड हमेशा हैशेड होते हैं। अधिकतम लंबाई पासवर्ड, सादा में संग्रहीत पासवर्ड का एक लक्षण है।

— jevon

14

पे, यहां तक कि पेपल पर, "सही घोड़े की बैटरी स्टेपल" उनके <सेंसर> अधिकतम लंबाई से 8 वर्ण ऊपर है ... हेडडेस्क

— रोमन

3

@kleinfreund क्योंकि अगर यह हैशेड था, तो पासवर्ड की लंबाई उनके लिए कोई मायने नहीं रखती थी (हैश फ़ंक्शंस किसी भी लम्बाई के स्ट्रिंग को एक निश्चित लंबाई में परिवर्तित करते हैं )।

— विक्की चिजवानी

75

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

इस मामले में यह है:

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

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

[आंतरिक रूप से, निश्चित रूप से आपका कोड केवल पहले 256/1024 / 2k / 4k / (जो भी) बाइट्स "महत्वपूर्ण" के रूप में व्यवहार कर सकता है, ताकि मैमथ पासवर्ड पर क्रंचिंग से बचा जा सके।]

— tardate
स्रोत

17

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

— रोमन स्टार्कोव

3

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

— बेन २

5

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

— छोड़े

1

कृपया विस्तार से बताएं। यह उत्तर एक मात्र कथन है।

— kleinfreund

1

एक अधिकतम पासवर्ड का मतलब यह नहीं है कि इसे सादे पाठ के रूप में संग्रहीत किया जा रहा है; यह तकनीकी कारणों से हो सकता है, उदाहरण के लिए bcrypt केवल 72 अक्षरों तक के पासवर्ड की अनुमति देता है।

— इमोरिस

58

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

प्रेषक आपको इतना लंबा पासवर्ड देने की कोशिश कर सकता है कि इसका परिणाम अन्य लोगों के लिए सेवा से वंचित होना है। उदाहरण के लिए, यदि पासवर्ड 1GB डेटा है और आप अपना सारा समय तब तक स्वीकार करते हैं, जब तक आप मेमोरी से बाहर नहीं निकल जाते। अब मान लीजिए कि यह व्यक्ति आपको यह पासवर्ड भेजता है जितनी बार आप स्वीकार करने के लिए तैयार हैं। यदि आप इसमें शामिल अन्य मापदंडों के बारे में सावधान नहीं हैं तो यह DoS हमले का कारण बन सकता है।

256 वर्णों की तरह ऊपरी सीमा को निर्धारित करना आज के मानकों से अत्यधिक उदार लगता है।

— जेसन डगिट
स्रोत

35

आप अभी भी अधिकतम सीमा के साथ 1 जीबी डेटा भेज सकते हैं। सीमित करने वाला सॉफ्टवेयर लगभग हमेशा वेबसर्वर के पीछे होता है।

— इपोकवुल्फ

6

आप अभी भी सभी छोड़ सकते हैं, लेकिन पहले 256chars कम्प्यूटेशनल गहन हालांकि कुछ भी करने से पहले। 1gb डेटा पर एक हैश चलाने पर 256 वर्णों पर समान हैश की तुलना में अधिक समय लगने वाला है ।

— rcreswick

2

@ ईयाल: वेब ऐप के क्लाइंट साइड पर जो कुछ भी होता है वह स्वाभाविक रूप से अविश्वसनीय है; इस प्रकार, हैश एक पासवर्ड के बराबर हो जाता है, जिससे यह व्यर्थता में एक अभ्यास बन जाता है। (एक वेब ब्राउज़र शायद 1-GB टेक्स्ट इनपुट स्वीकार नहीं करेगा, और एक कस्टम क्लाइंट "itisthehashedpassword" फ़ॉर्म फ़ील्ड में 1-GB स्ट्रिंग भेज सकता है)

— Piskvor ने

4

@Piskvor: लेकिन वैसे भी 1-GB स्ट्रिंग को रोकने का कोई तरीका नहीं है। एक उपयोगकर्ता हमेशा example.com/?password=abcabcabcabc ... का अनुरोध कर सकता है और अपने अनुरोध को जितना चाहे उतना बड़ा बना सकता है। मानक DoS।

— ईयाल

4

@Piskvor और Eyal, सौभाग्य से, अपाचे और IIS (और संभवतः अन्य परिपक्व सर्वर) URL द्वारा पारित क्षेत्रों की लंबाई को सीमित करते हैं: boutell.com/newfaq/misc/urllength.html

— sampablokuper 25/25 '18

21

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

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

— Sparr
स्रोत

माना! पिछले कुछ वर्षों में यूके बैंक की ऑनलाइन एक्सेस सुरक्षा विफलताओं के बारे में ...

— स्टु थॉम्पसन

6

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

— रोमन स्टार्कोव

@romkyns मैं इसे लेता हूं आपकी योजना प्रतीकों का उपयोग नहीं करती है? मेरे पास एक बार ऐसी योजना थी जो कम हार्ड-टू-ब्रूट-बल पासवर्ड का उत्पादन करती थी, लेकिन मुझे इसे तब छोड़ना पड़ा जब 10-20% साइटें मैंने सामान्य विशेष पात्रों का उपयोग किया।

— Sparr

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

— रोमन स्टार्कोव

1

@romkyns इस तरह की योजनाओं के साथ अन्य समस्याएं: पासवर्ड साझा करने वाली साइटें। यदि आपकी योजना nameofwebsitefO0 (googlefO0 yahoofO0 आदि) जैसी कुछ है, तो आपको कैसे याद रखें कि आप "yahoofO0" का उपयोग flickr.com, या stackoverflowfO0 askubuntu.com पर करने वाले हैं? पासवर्ड समाप्त करने वाली साइटें। फिर आपको उस हिस्से को शामिल करने के लिए योजना का विस्तार करना होगा जो बदल सकता है। लेकिन यह विफल हो जाता है यदि समाप्ति नियम सबस्ट्रिंग के लिए जाँच करता है।

— स्पर्स 17:10

13

128 से कम वर्णों की अधिकतम पासवर्ड लंबाई निर्धारित करना अब OWASP प्रमाणीकरण धोखा पत्रक द्वारा हतोत्साहित किया जाता है

https://www.owasp.org/index.php/Authentication_Cheat_Sheet

पूरे पैराग्राफ का हवाला देते हुए:

लंबे पासवर्ड वर्णों का एक बड़ा संयोजन प्रदान करते हैं और इसके परिणामस्वरूप एक हमलावर के लिए अनुमान लगाना अधिक कठिन हो जाता है।

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

अधिकतम पासवर्ड की लंबाई बहुत कम नहीं होनी चाहिए, क्योंकि यह उपयोगकर्ताओं को पासफ़्रेज़ बनाने से रोकेगा। विशिष्ट अधिकतम लंबाई 128 वर्ण है। 20 वर्णों से छोटे पासफ़्रेज़ को आमतौर पर कमजोर माना जाता है यदि वे केवल निचले मामले लैटिन वर्णों से मिलकर होते हैं। हर किरदार मायने रखता है !!

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

— kravietz
स्रोत

11

यह स्रोत अधिकतम पासवर्ड लंबाई सीमाओं को हतोत्साहित नहीं करता है, यह कम (128 वर्णों से कम) अधिकतम पासवर्ड लंबाई सीमाओं को हतोत्साहित करता है।

— मैथ्यू

9

एक कारण मैं अधिकतम पासवर्ड लंबाई लागू करने के लिए कल्पना कर सकता हूं, अगर फ्रंटेंड को कई विरासत प्रणाली के बैकएंड के साथ इंटरफ़ेस करना चाहिए, जिसमें से एक स्वयं अधिकतम पासवर्ड लंबाई लागू करता है।

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

— mbac32768
स्रोत

1

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

— कास्टिक वायोज

6

कुछ अधिकतम पासवर्ड लंबाई लगाने का एक संभावित वैध कारण यह है कि इसे हैश करने की प्रक्रिया (एक धीमी गति से हैशिंग फ़ंक्शन जैसे कि bcrypt के उपयोग के कारण) में बहुत अधिक समय लगता है; सर्वर के खिलाफ DOS हमले को अंजाम देने के लिए किसी चीज का दुरुपयोग किया जा सकता है।

फिर से, सर्वरों को स्वचालित रूप से अनुरोध हैंडलर्स को स्वचालित रूप से ड्रॉप करने के लिए कॉन्फ़िगर किया जाना चाहिए जो बहुत लंबा है। इसलिए मुझे संदेह है कि यह एक समस्या होगी।

— AardvarkSoup
स्रोत

4

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

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

— लुकास ओमान
स्रोत

3

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

— DrStalker
स्रोत

1

अधिकतम इनपुट लंबाई होनी चाहिए, हां, लेकिन यह निश्चित रूप से नहीं होना चाहिए <64. 8 या 12 की अधिकतम लंबाई सिर्फ हास्यास्पद है।

— डैन बेहार्ड

2

लंबे पासवर्ड को मान्य नहीं करने के लिए लोगों को अनदेखा करें। ओवस्प का शाब्दिक अर्थ है कि 128 वर्ण पर्याप्त होना चाहिए। बस पर्याप्त सांस की जगह देने के लिए आप थोड़ा और अधिक 300, 250, 500 दे सकते हैं यदि आपको ऐसा लगता है।

https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Password_Length

पासवर्ड लंबाई लंबे पासवर्ड वर्णों का एक बड़ा संयोजन प्रदान करते हैं और इसके परिणामस्वरूप एक हमलावर के लिए अनुमान लगाना अधिक कठिन हो जाता है।

...

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

— CommonSenseCode
स्रोत

चर्चा के लिए प्रासंगिक नहीं है। सवाल यह है कि क्या लंबाई को सीमित करने का कोई लाभ है कि क्या 128 पर्याप्त नहीं है।

— विक्की

1

भंडारण सस्ता है, पासवर्ड की लंबाई को सीमित क्यों करें। यहां तक कि अगर आप पासवर्ड को एन्क्रिप्ट कर रहे हैं, तो इसके विपरीत सिर्फ 64 कैरेक्टर स्ट्रिंग है, यह एनक्रिप्ट करने के लिए 6 कैरेक्टर स्ट्रिंग से ज्यादा नहीं है।

संभावना है कि बैंक प्रणाली एक पुरानी प्रणाली को ओवरले कर रही है, इसलिए वे केवल पासवर्ड के लिए एक निश्चित स्थान की अनुमति देने में सक्षम थे।

— LizB
स्रोत

9

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

— स्टु थॉम्पसन

8

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

— रोमन स्टार्कोव

1

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

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

एक स्मार्ट कार्ड समाधान मेरे साथ ठीक नहीं होगा। मेरे पास पहले से ही बहुत सारे कार्ड हैं क्योंकि यह है ... मुझे दूसरे नौटंकी की आवश्यकता नहीं है।

— विन्सेंट मैकनाब
स्रोत

वे महत्वपूर्ण कीस्पेस को काटते हैं जो समय-समय पर बल बल के हमलों के लिए लंबा हो जाता है (और जब मेरा मतलब है) उनके हैश के डेटाबेस को चुरा लिया जाता है (यह मानते हुए कि वे नमक / हैश / खिंचाव, जो मुझे यकीन है कि वे नहीं करते हैं)। बैंकों को बदलने का समय।

— क्रिस गोमेज़

1

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

— उपयोगकर्ता
स्रोत

1

जब तक आवश्यक न हो, कोई सीमा न लगाने का प्रयास करें। सावधान रहें: यह बहुत से अलग-अलग मामलों में आवश्यक हो सकता है। विरासत प्रणालियों से निपटना इन कारणों में से एक है। सुनिश्चित करें कि आप बहुत लंबे पासवर्ड के मामले का अच्छी तरह से परीक्षण कर सकते हैं (क्या आपका सिस्टम 10 एमबी लंबे पासवर्ड से निपट सकता है?)। आप डेनियल ऑफ सर्विस (डीओएस) की समस्याओं में भाग सकते हैं क्योंकि आपके द्वारा उपयोग किए जा रहे कुंजी परिभाषित क्रिया (केडीएफ) (आमतौर पर PBKDF2, bcrypt, scrypt) में अधिक समय और संसाधन लगेगा। वास्तविक जीवन उदाहरण: http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/

— मारेक पुचलस्की
स्रोत

0

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

मैं व्यक्तिगत रूप से इस विशिष्ट मुद्दे पर विश्वास करता हूं, प्रत्येक उपयोगकर्ता को अपना। अगर आपको लगता है कि आप 40 कैरेक्टर का पासवर्ड याद रख सकते हैं, तो आपके लिए और अधिक शक्ति है!

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

— tekiegreg
स्रोत

लोग आसानी से एक पसंदीदा गीत गीत, बाइबिल कविता, या अन्य कह याद कर सकते हैं। वे एक विशिष्ट पासवर्ड की तुलना में बहुत लंबे हैं। मैंने सिर्फ एक परीक्षण किया और 79 पात्रों में आया! (दी, एक गलती की संभावना अब अधिक हो जाती है एक पासफ़्रेज़। इससे भी बदतर जब एक STUPID वेबसाइट आपको पासवर्ड बॉक्स में आपके द्वारा दर्ज किया गया अंतिम वर्ण नहीं दिखाती है।)

— Katastic Voyage

0

लंबे पासवर्ड, या पास-वाक्यांश, केवल लंबाई के आधार पर दरार करना कठिन है, और जटिल पासवर्ड की आवश्यकता की तुलना में याद रखना आसान है।

संभवतः सबसे लंबा (10+) न्यूनतम लंबाई के लिए जाना सबसे अच्छा है, जिससे लंबाई बेकार हो जाती है।

— benPearce
स्रोत

0

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

— चक
स्रोत

0

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

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

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

— क्रिस जे
स्रोत

-4

सिर्फ 8 char लॉन्ग पासवर्ड सिर्फ गलत लगता है। अगर एक सीमा होनी चाहिए, तो कम से कम 20 बार बेहतर विचार है।

— user17000
स्रोत

3

लेकिन यह बात है - वहाँ एक सीमा नहीं होनी चाहिए।

— ल्यूक स्टीवेंसन

-4

मुझे लगता है कि लागू की जाने वाली एकमात्र सीमा 2000 अक्षर की सीमा की तरह है, या कुछ और अत्यधिक उच्च है, लेकिन केवल डेटाबेस का आकार सीमित करने के लिए यदि यह एक समस्या है

— जोश हंट
स्रोत

9

पासवर्ड हैशेड होना चाहिए ... और डेटाबेस का आकार एक मुद्दा नहीं होगा पासवर्ड हैशेड है।

— epochwolf

4

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

— केनी एविट