कुछ साइटें पासवर्ड में रिक्त स्थान क्यों रोकती हैं?

Question

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

Comments

हो सकता है कि कुछ साइटें सिंगल साइन ऑन का उपयोग करें, यह मानते हुए कि एसएसओ को गैर-रिक्त पासवर्ड की आवश्यकता है (हालांकि यह सुनिश्चित नहीं है)!

— NoChance

क्या वास्तव में मुझे डराता है, जब साइटें विशेष रूप से एकल उद्धरण को अस्वीकार करती हैं। आपके पास इसके अलावा क्या संभावित कारण हो सकते हैं "insert into USERS (..., password) values (..., '" + $POST['password'] + "');" : -एस

— क्रिश्चियन क्लॉसर

सुरक्षा के लिए जाना चाहिए था, प्रोग्रामर नहीं। यह शायद पहले से ही वहाँ मौजूद है।

— दान मैकग्राथ

Answer 1

जब वेबसाइटों में पासवर्ड की बात आती है, तो बड़ी मात्रा में बेवकूफियां होती हैं।

• कुछ के विशुद्ध रूप से तकनीकी कारण हैं (मान्य या नहीं, यह एक और सवाल है, लेकिन उनमें से लगभग सभी नहीं हैं):

आपका पासवर्ड चार अक्षरों की लंबाई का होना चाहिए और केवल अंक होना चाहिए।

(पासवर्ड को 0001 .. 9999 सीमा तक सीमित करके, आप बस उन्हें डेटाबेस में एक नंबर, प्लेनटेक्स्ट के रूप में स्टोर कर सकते हैं)

• अन्य कुछ गलत विचारों द्वारा समझाया गया है कि वे पासवर्ड को अधिक सुरक्षित बनाएंगे :

आपका पासवर्ड एक बड़े अक्षर से शुरू होना चाहिए और एक अंक के साथ समाप्त होना चाहिए।

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

• अन्य, अंत में, इस तथ्य से समझाया जाता है कि पासवर्ड को प्लेनटेक्स्ट संग्रहीत किया जाता है , और इस बारे में कुछ अस्पष्टताएं हैं कि वे कैसे संग्रहीत, संसाधित या पुनर्प्राप्त किए जाते हैं, और यूनिट परीक्षण के लिए कोई समय नहीं है।

आपके पासवर्ड में एक अमान्य वर्ण है é ।

या,

आपका पासवर्ड y$₯46¥*A'xD<7&฿=ᴙcN&sF5_Ở!d में कुछ अमान्य वर्ण हैं। केवल लैटिन वर्णमाला और अंकों के वर्णों का उपयोग करें।

या,

आपके पासवर्ड में व्हॉट्सएप अक्षर नहीं हो सकते।

सभी तीन मामलों में, डेवलपर सिर्फ बीमा था कि इस तरह के पासवर्ड सही तरीके से संग्रहीत किए जाएंगे।

• पहले मामले में, अगर भेजा éगया तो क्या होगा %C3%A9? या क्या होगा अगर डेटाबेस éगलत तरीके से स्टोर करेगा ?

• दूसरे मामले में, क्या होगा यदि PHP (क्यों PHP?) यूनिकोड से निपट नहीं सकता है, और इस तरह से पासवर्ड प्राप्त करने पर कुछ भयानक होता है? क्या होगा अगर <चरित्र परेशानी का कारण बनता है? क्या होगा यदि &चरित्र को एक URL में विभाजक के रूप में व्याख्या की जाती है (यह मानते हुए कि किसी कारण से, पासवर्ड को POST के बजाय GET के माध्यम से भेजा जा रहा है)? क्या होगा अगर 'डेटाबेस द्वारा व्याख्या की जाती है, क्योंकि, लगता है कि, हमें पता नहीं है कि SQL इंजेक्शन क्या है और इससे कैसे बचा जाए? या अगर 'तब्दील हो जाए तो क्या होगा \'?

• तीसरे मामले में, क्या होगा यदि PHP (फिर से?) कुछ मामलों में व्हाट्सएप को ट्रिम करता है और दूसरों में नहीं? क्या होगा अगर प्रशासक (जो स्पष्ट रूप से प्लेटेक्स्ट में उपयोगकर्ताओं के पासवर्ड तक पहुंच रखते हैं) खो गए हैं क्योंकि वे केवल एक व्हाट्सएप देखते हैं, जबकि उपयोगकर्ता ने लगातार तीन व्हाट्सएप सेट किए हैं ?

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

इसका मतलब यह है कि क्या डेवलपर रिक्त स्थान , या यूनिकोड वर्ण, या ASCII 48..57 48 65..90 48 97..122 के बाहर किसी भी चरित्र के संभावित परिणामों के बारे में सोचने की कोशिश करता है (अंक, निचला अक्षर, अपरकेस अक्षर) , सबसे आसान तरीका है, जब परीक्षण संभव नहीं है, बस उन्हें मना करने के लिए है ।

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

Comments

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

— लेज़ मेज़े

मैं जो कुछ भी सुनता हूं, उससे सहमत हूं, लेकिन मेरे पास "सबसे आसान तरीका है, जब परीक्षण संभव नहीं है ..." को पचाने के लिए एक वास्तविक कठिन समय है। परीक्षण संभव नहीं है ??? जो कोई भी उस परियोजना के लिए सहमत होता है, जहां ऐसा होता है: मूर्खता को अधिकतम रूप से अधिकतम किया जाता है ... हाँ मुझे पता है कि यह होता है: - |

— थॉमस

@ थोमस: यह सामान्य रूप से सिद्धांत और ज्ञान के बीच का अंतर है और इसकी सामान्य अज्ञानता और समय की कमी के साथ अभ्यास, जहां बहुत से लोग समय परीक्षण बर्बाद नहीं करना चाहते हैं, यह अनदेखी करते हुए कि वे कम से कम दो बार बाद में डिबगिंग में खर्च करेंगे।

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

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

— सुपरकैट

Answer 2

उत्तर है इतिहास

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

पासवर्ड के बारे में बहुत सारे रैन हैं जो हम अभी जानते हैं और हम अब क्या कर सकते हैं, इसके आधार पर, लेकिन सरल तथ्य यह है कि हम अक्सर विरासत सोच और विरासत प्रणालियों के संयोजन के साथ काम कर रहे हैं।

क्या अब नए सिस्टम में प्रतिबंध होना चाहिए ? मुझे उम्मीद है कि अब कम कारण नहीं होगा

Comments

आप कह रहे हैं वहाँ थे पासवर्ड है कि वहाँ से पहले नहीं थे में रिक्तियों के साथ तकनीकी प्रतिबंध? भंडारण वास्तव में क्या हिस्सा था?

— इयान हंटर

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

— मर्फ़

Answer 3

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

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

Comments

मैं पासवर्ड से अग्रणी / अनुगामी रिक्त स्थान को छीनना पसंद करता हूं क्योंकि वे समस्याएं पैदा करते हैं, लेकिन उन्हें अस्वीकार करने का कोई कारण नहीं है - वे बस सेटिंग और परीक्षण दोनों पर छीन लेंगे, कोई समस्या नहीं।

— लोरेन Pechtel

और वास्तव में "समस्याएं" क्या हैं? मैं उस जवाब पर जोर दे रहा हूं, जिसमें रिक्त स्थान की अनुमति दी जानी चाहिए। "वे सेटिंग और परीक्षण दोनों पर छीन लेंगे" - फिर क्या बात है? तब "1 4m 1337" और "1 4am 1337" दोनों ही समान मूल्य पर हैश (वास्तव में, सिद्धांत में अनंत संभावनाएं हैं)।

— यति सगड़े २५'११ को ade:

What's the point then?माइनर बिंदु यह है कि उपयोगकर्ता के इरादे से पासवर्ड कम एन्ट्रॉपी का है। और कुछ प्रणालियाँ डिफ़ॉल्ट रूप से GET / POST var को ट्रिम कर देती हैं, (उस व्यवहार में परिवर्तन की संभावना नहीं है) और अधिक गंभीर समस्याएँ पैदा करेंगी।

— यानिस डे

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

— लोरेन Pechtel

Answer 4

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

यह उसी कारण से किया जाता है जब कई साइटों के शब्द फ़िल्टर आपको "कॉकी", "मंदबुद्धि" या "संचित" जैसे शब्दों का उपयोग नहीं करने देंगे (हालांकि कई सामान्य नस्लीय स्लर्स बिल्कुल ठीक हैं)।

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

Comments

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

— लेजे मेजेस्टे