มีจำนวนมากโง่เมื่อมันมาถึงรหัสผ่านในเว็บไซต์
- บางคนมีเหตุผลทางเทคนิคอย่างหมดจด(ถูกต้องหรือไม่นั่นคือคำถามอื่น แต่เกือบทั้งหมดไม่ใช่):
รหัสผ่านของคุณจะต้องมีความยาวสี่ตัวอักษรและมีตัวเลขเท่านั้น
(โดยการ จำกัด รหัสผ่านให้กับ 0001 .. ช่วง 9999 คุณสามารถเก็บไว้เป็นตัวเลข, ข้อความธรรมดา, ในฐานข้อมูล)
- อื่น ๆ อธิบายโดยความคิดที่ผิดพลาดบางอย่างที่พวกเขาจะทำให้รหัสผ่านที่ปลอดภัยยิ่งขึ้น :
รหัสผ่านของคุณจะต้องเริ่มต้นด้วยอักษรตัวใหญ่และลงท้ายด้วยหลัก
(โดยการทำเช่นนี้ผู้พัฒนาหรือผู้จัดการสันนิษฐานว่าสิ่งนี้จริง ๆ แล้วจะบังคับให้ผู้ใช้เลือกรหัสผ่านที่ปลอดภัยในขณะที่กฎเป็น "รหัสผ่านของคุณต้องมีอักขระอย่างน้อย 6 ตัวและมีอักษรตัวใหญ่อย่างน้อยหนึ่งตัวพิมพ์เล็กและ ตัวเลข "จะล้มเหลวอย่างน่าอัศจรรย์ที่จะทำมัน)
- ในที่สุดก็มีการอธิบายด้วยความจริงที่ว่ารหัสผ่านนั้นถูกเก็บรักษาไว้อย่างเรียบง่ายและมีความคลุมเครือเกี่ยวกับวิธีการจัดเก็บประมวลผลหรือดึงข้อมูลและไม่มีเวลาทดสอบหน่วย
éรหัสผ่านของคุณประกอบด้วยอักขระที่ไม่ถูกต้อง
หรือ,
รหัสผ่านของคุณy$₯46¥*A'xD<7&฿=ᴙcN&sF5_Ở!dมีอักขระที่ไม่ถูกต้อง ใช้อักขระจากตัวอักษรละตินและตัวเลขเท่านั้น
หรือ,
รหัสผ่านของคุณต้องไม่มีอักขระช่องว่าง
ในทั้งสามกรณีผู้พัฒนาได้รับการประกันว่ารหัสผ่านเช่นนี้จะถูกจัดเก็บอย่างถูกต้อง
ในกรณีแรกสิ่งที่ถ้าéจะเปลี่ยนเป็น%C3%A9เมื่อส่ง? หรือถ้าฐานข้อมูลจะจัดเก็บéไม่ถูกต้อง
ในกรณีที่สองจะเกิดอะไรขึ้นถ้า PHP (เพราะเหตุใด PHP) ไม่สามารถจัดการกับยูนิโค้ดได้และสิ่งที่น่ากลัวเมื่อได้รับรหัสผ่านเช่นนี้? เกิดอะไรขึ้นถ้า<ตัวละครทำให้เกิดปัญหา? เกิดอะไรขึ้นถ้า&ตัวละครถูกตีความว่าเป็นตัวแยกใน URL (สมมติว่าด้วยเหตุผลบางอย่างรหัสผ่านจะถูกส่งผ่าน GET แทน POST)? จะเกิดอะไรขึ้นถ้า'ฐานข้อมูลตีความเพราะเดาว่าเราไม่รู้ว่า SQL Injection คืออะไรและจะหลีกเลี่ยงได้อย่างไร หรือถ้า'เปลี่ยนเป็น\'อะไร
ในกรณีที่สามจะเกิดอะไรขึ้นถ้า PHP (อีกครั้ง?) จดจ้องช่องว่างในบางกรณีและไม่ใช่ในกรณีอื่น ๆ เกิดอะไรขึ้นถ้าผู้บริหาร (ที่น่าแปลกใจที่มีการเข้าถึงรหัสผ่านผู้ใช้ใน plaintext) จะหายไปเพราะพวกเขาเห็นเพียงหนึ่งช่องว่างในขณะที่ผู้ใช้มีการตั้งสามช่องว่างติดต่อกัน ?
ในทั้งสามกรณีความคลุมเครือเหล่านั้นสามารถแก้ไขได้อย่างง่ายดายผ่านการทดสอบโดยเฉพาะการทดสอบหน่วย แต่ในโครงการจำนวนมากไม่มีการทดสอบเลยและไม่มีเวลาในการทดสอบ (แต่ยังมีเวลาอีกมากในการดีบักในภายหลัง)
ซึ่งหมายความว่าผู้พัฒนาพยายามที่จะคิดถึงผลที่ตามมาที่อาจเกิดขึ้นจากการอนุญาตให้มีช่องว่างหรือ unicode อักขระหรือเพียงแค่ตัวละครใด ๆ นอก ASCII 48..57 .. 65 .. 90 90 90..90 ∪ 97..122 (ตัวเลขตัวอักษรตัวพิมพ์เล็กตัวอักษรตัวพิมพ์ใหญ่) , วิธีที่ง่ายที่สุดเมื่อการทดสอบเป็นไปไม่ได้เป็นเพียงการห้ามเขา
ในความคิดของฉันนี้เป็นเหตุผลเดียวที่จะห้ามช่องว่าง Yannis Rizos ให้อีกเหตุผลที่เกี่ยวข้องกับ UX ในขณะที่เป็นเหตุผลที่เป็นไปได้ในทางทฤษฎีมันไม่สามารถใช้งานได้จริง: เว็บไซต์ที่สร้างโดยผู้ที่สนใจเกี่ยวกับ UX ไม่ได้แก้ไขกฎรหัสผ่านโง่ ๆ ในทางกลับกันเว็บไซต์ที่ห้ามใช้ช่องว่างนั้นส่วนใหญ่ทำโดยผู้ที่ไม่เคยได้ยินเกี่ยวกับ UX มาก่อน นี่เป็นเรื่องจริงโดยเฉพาะอย่างยิ่งเนื่องจากการห้ามอักขระใด ๆ นั้นน่ารำคาญจริง ๆ จากมุมมองของ UX เนื่องจากข้อ จำกัด เกี่ยวกับรหัสผ่านใด ๆ รวมถึงอักขระที่มีประโยชน์เป็นจำนวนอักขระขั้นต่ำ