ওয়েবসাইটগুলিতে পাসওয়ার্ডের বিষয়টি আসে যখন প্রচুর পরিমাণে বোকামি থাকে ।
- কারও কারও কাছে বিশুদ্ধ প্রযুক্তিগত কারণ রয়েছে (বৈধ বা না, এটি অন্য একটি প্রশ্ন, তবে প্রায় সবগুলিই নয়):
আপনার পাসওয়ার্ডটি অবশ্যই চারটি অক্ষরের দৈর্ঘ্যের এবং শুধুমাত্র সংখ্যা থাকতে হবে।
(পাসওয়ার্ডটি 0001 .. 9999 সীমার মধ্যে সীমাবদ্ধ করে আপনি কেবল এগুলি ডাটাবেসে একটি সংখ্যা, প্লেইন টেক্সট হিসাবে সংরক্ষণ করতে পারেন)
- অন্যান্যগুলিকে কিছু ভুল ধারণা দ্বারা ব্যাখ্যা করা হয় যে তারা পাসওয়ার্ডগুলি আরও সুরক্ষিত করে তুলবে :
আপনার পাসওয়ার্ড অবশ্যই একটি মূল অক্ষর দিয়ে শুরু হবে এবং একটি অঙ্কের সাথে শেষ হবে।
(এটি বিকাশকারী বা পরিচালক হিসাবে ধরে নিয়েছেন যে এটি আসলে ব্যবহারকারীদের নিরাপদ পাসওয়ার্ড বেছে নিতে বাধ্য করবে, যদিও "আপনার পাসওয়ার্ডে ন্যূনতম 6 টি অক্ষর থাকতে হবে এবং কমপক্ষে একটি বড় অক্ষর, ছোট হাতের অক্ষর এবং একটি থাকতে হবে অঙ্ক "জাদুকরভাবে এটি করতে ব্যর্থ হবে)
- অন্যান্য, শেষ অবধি, পাসওয়ার্ডগুলি সরলরেখাগুলি সংরক্ষণ করা হয় , এবং সেগুলি কীভাবে সংরক্ষণ করা হয়, প্রক্রিয়াজাত করা হয় বা পুনরুদ্ধার করা হয় সে সম্পর্কে কিছুটা অস্পষ্টতা রয়েছে এবং এগুলি পরীক্ষা করার সময় নেই time
আপনার পাসওয়ার্ডে একটি অবৈধ অক্ষর রয়েছে é।
বা,
আপনার পাসওয়ার্ডে y$₯46¥*A'xD<7&฿=ᴙcN&sF5_Ở!dকিছু অবৈধ অক্ষর রয়েছে। শুধুমাত্র লাতিন বর্ণমালা এবং অঙ্কগুলি থেকে অক্ষরগুলি ব্যবহার করুন।
বা,
আপনার পাসওয়ার্ডে সাদা স্থানের অক্ষর থাকতে পারে না।
তিনটি ক্ষেত্রেই, বিকাশকারী কেবলমাত্র নিশ্চিত হয়েছিলেন যে এই জাতীয় পাসওয়ার্ডগুলি সঠিকভাবে সংরক্ষণ করা হবে।
প্রথম ক্ষেত্রে, প্রেরণ éকরা %C3%A9হলে কি রূপান্তরিত হবে ? বা যদি ডাটাবেসটি éভুলভাবে সংরক্ষণ করবে ?
দ্বিতীয় ক্ষেত্রে, যদি পিএইচপি (কেন পিএইচপি?) ইউনিকোড মোকাবেলা করতে না পারে এবং এই জাতীয় পাসওয়ার্ড পাওয়ার সময় ভয়ঙ্কর কিছু করে? <চরিত্র যদি সমস্যার কারণ হয়? যদি &কোনও ইউআরএলটিতে চরিত্রটিকে বিভাজক হিসাবে ব্যাখ্যা করা হয় (ধরে নেওয়া যায় যে কোনও কারণে, পাসওয়ার্ডটি পোষ্টের পরিবর্তে জিইটি-র মাধ্যমে প্রেরণ করা হচ্ছে)? 'ডাটাবেস দ্বারা যদি ব্যাখ্যা করা হয়, তবে কী অনুমান করুন, এসকিউএল ইনজেকশন কী এবং কীভাবে তা এড়ানো যায় সে সম্পর্কে আমাদের ধারণা নেই বা যদি 'রূপান্তরিত হয় \'?
তৃতীয় ক্ষেত্রে, যদি পিএইচপি (আবার?) কিছু ক্ষেত্রে হোয়াইট স্পেস ছাঁটাই করে অন্যকে না? যদি প্রশাসকরা (যাদের আশ্চর্যরূপে প্লেইন্টেক্সটে ব্যবহারকারীদের পাসওয়ার্ডগুলিতে অ্যাক্সেস রয়েছে) তারা যদি কেবল একটি সাদা স্থান দেখেন তবে তারা যদি হারিয়ে যায় তবে ব্যবহারকারীরা পরপর তিনটি শ্বেতস্পেস সেট করেছেন ?
তিনটি ক্ষেত্রেই those অস্পষ্টতাগুলি সহজেই পরীক্ষার মাধ্যমে সমাধান করা হয় , বিশেষত ইউনিট পরীক্ষার মাধ্যমে। তবে প্রচুর পরিমাণে প্রকল্পে মোটেও কোনও পরীক্ষা-নিরীক্ষা হয় না , এবং পরীক্ষার সময় হয় না (তবে পরে ডিবাগ করার জন্য এখনও প্রচুর সময়)।
এর অর্থ হ'ল বিকাশকারী স্পেসগুলি , বা ইউনিকোড অক্ষরগুলিকে অনুমতি দেওয়ার সম্ভাব্য পরিণতিগুলি , বা ASCII 48..57 ∪ 65..90 ∪ 97..122 (অঙ্কগুলি, ছোট হাতের অক্ষর, বড় হাতের অক্ষর) এর সম্ভাব্য পরিণতি সম্পর্কে চিন্তাভাবনা করার চেষ্টা করছে কিনা , সবচেয়ে সহজ উপায়, যখন পরীক্ষা করা সম্ভব হয় না, কেবল তাদের নিষেধ করা ।
আমার মতে স্পেস নিষেধ করার একমাত্র কারণ এটি। ইউনিস রিজস ইউএক্স সম্পর্কিত আরও একটি কারণ দিয়েছেন। তত্ত্বের এক ধরণের কারণ হিসাবে চলাকালীন, এটি অনুশীলনে মোটেও কাজ করে না: লোকদের দ্বারা তৈরি ওয়েবসাইটগুলি যারা ইউএক্সের বিষয়ে সত্যই যত্নশীল তাদের বোকা পাসওয়ার্ডের নিয়ম ঠিক করে না। পরিবর্তে, ওয়েবসাইট যেখানে হোয়াইটস্পেস আসলে নিষিদ্ধ করা হয় অধিকাংশ অংশ যারা ইউএক্স সম্পর্কে কথা শুনিনি দ্বারা সম্পন্ন হয় । এটি বিশেষত সত্য যেহেতু কোনও অক্ষর নিষিদ্ধ করা ইউএক্স দৃষ্টিকোণ থেকে সত্যই বিরক্তিকর, কোনও পাসওয়ার্ড-সম্পর্কিত বিধিনিষেধ, দরকারীগুলি সহ ন্যূনতম সংখ্যার হিসাবে।