Mengapa situs tertentu mencegah spasi pada kata sandi?

Tampaknya kurang umum dengan situs web yang lebih baru, tetapi banyak situs web tempat saya memerlukan akun (seperti untuk membayar tagihan, dll.) Mencegah saya membuat kata sandi dengan spasi di dalamnya. Ini hanya membuat hal-hal lebih sulit untuk diingat , dan saya menyadari tidak ada batasan basis data atau pemrograman pada kata sandi, terenkripsi atau (surga dilarang) sebaliknya. Lalu, mengapa spasi begitu sering didiskriminasi ketika mendaftar untuk sebuah situs?

Ada sejumlah besar kebodohan dalam hal kata sandi di situs web.

• Beberapa memiliki alasan teknis murni (valid atau tidak, itu pertanyaan lain, tetapi hampir semuanya tidak):

Kata sandi Anda harus sepanjang empat karakter dan hanya memiliki digit.

(Dengan membatasi kata sandi hingga 0001 .. rentang 9999, Anda dapat menyimpannya sebagai angka, plaintext, dalam database)

• Lainnya dijelaskan oleh beberapa pemikiran keliru bahwa mereka akan membuat kata sandi lebih aman :

Kata sandi Anda harus dimulai dengan huruf kapital dan diakhiri dengan angka.

(Dengan melakukan ini, pengembang, atau manajer, berasumsi bahwa ini akan memaksa pengguna untuk memilih kata sandi yang aman, sementara aturan sebagai "Kata sandi Anda harus mengandung minimal 6 karakter dan mengandung setidaknya satu huruf kapital, huruf kecil dan digit "secara ajaib akan gagal melakukannya)

• Lainnya, akhirnya, dijelaskan oleh fakta bahwa kata sandi disimpan plaintext , dan ada beberapa ambiguitas tentang bagaimana mereka disimpan, diproses atau diambil, dan tidak ada waktu untuk unit mengujinya.

Kata sandi Anda mengandung karakter yang tidak valid é.

atau,

Kata sandi Anda y$₯46¥*A'xD<7&฿=ᴙcN&sF5_Ở!dmengandung beberapa karakter yang tidak valid. Gunakan karakter dari alfabet Latin dan digit saja.

atau,

Kata sandi Anda tidak boleh mengandung karakter spasi putih.

Dalam ketiga kasus, pengembang hanya memastikan bahwa kata sandi seperti ini akan disimpan dengan benar.

• Dalam kasus pertama, bagaimana jika éakan diubah menjadi %C3%A9ketika dikirim? Atau bagaimana jika database akan disimpan secara étidak benar?

• Dalam kasus kedua, bagaimana jika PHP (mengapa PHP?) Tidak dapat menangani unicode, dan melakukan sesuatu yang mengerikan ketika menerima kata sandi seperti ini? Bagaimana jika <karakter menyebabkan masalah? Bagaimana jika &karakter ditafsirkan sebagai pemisah dalam URL (dengan asumsi bahwa karena suatu alasan, kata sandi dikirim melalui GET bukannya POST)? Bagaimana jika 'ditafsirkan oleh database, karena, coba tebak, kami tidak tahu apa itu SQL Injection dan bagaimana cara menghindarinya? Atau bagaimana jika 'diubah menjadi \'?

• Dalam kasus ketiga, bagaimana jika PHP (lagi?) Memangkas spasi putih dalam beberapa kasus dan tidak dalam yang lain? Bagaimana jika administrator (yang secara mengejutkan memiliki akses ke kata sandi pengguna dalam plaintext) hilang karena mereka hanya melihat satu spasi putih, sementara pengguna telah menetapkan tiga spasi putih berturut-turut ?

Dalam ketiga kasus tersebut, ambiguitas tersebut mudah diselesaikan melalui pengujian , terutama pengujian unit. Tetapi dalam sejumlah besar proyek, tidak ada pengujian sama sekali , dan tidak ada waktu untuk menguji (tapi masih banyak waktu untuk debug nanti).

Ini berarti apakah pengembang mencoba untuk memikirkan kemungkinan konsekuensi dari memungkinkan spasi , atau unicode karakter, atau sembarang karakter di luar ASCII 48..57 ∪ 65..90 ∪ 97..122 (digit, huruf kecil, huruf besar) , cara termudah, ketika pengujian tidak memungkinkan, adalah dengan hanya melarang mereka .

Menurut pendapat saya, ini adalah satu-satunya alasan untuk melarang ruang. Yannis Rizos memberi alasan lain terkait UX. Meskipun menjadi alasan yang masuk akal secara teori, itu tidak bekerja sama sekali dalam praktiknya: situs web yang dibuat oleh orang-orang yang benar-benar peduli tentang UX tidak memperbaiki aturan kata sandi yang bodoh. Sebaliknya, situs web di mana spasi putih sebenarnya dilarang sebagian besar dilakukan oleh orang-orang yang tidak pernah mendengar tentang UX . Ini terutama benar karena melarang karakter apa pun benar-benar menjengkelkan dari sudut pandang UX, karena setiap pembatasan terkait kata sandi, termasuk yang bermanfaat, sebagai jumlah minimum karakter.

Jawabannya adalah Sejarah

Kita sepertinya lupa bahwa dasar dari banyak hal ini berasal dari waktu ketika penyimpanan tidak secara efektif gratis (pada disk atau dalam memori) ketika kemampuan kita untuk mengelola semua hal ini agak kurang dari sekarang dan sama - sama kemampuan sistem otomatis mencoba untuk memecahkan yang sama juga agak kurang.

Ada banyak kata-kata kasar tentang kata sandi berdasarkan apa yang kita ketahui sekarang dan apa yang bisa kita lakukan sekarang tetapi faktanya adalah kita sering berhadapan dengan kombinasi pemikiran legacy dan sistem legacy.

Haruskah ada pembatasan dalam sistem baru sekarang ? Saya berharap tidak - alasan yang jauh lebih sedikit sekarang

IMHO, Ini benar-benar bodoh dari semua situs / aplikasi yang menggunakan hashing modern dan / atau salting untuk menyimpan kata sandi untuk tidak mengizinkan spasi dalam kata sandi. Namun, beberapa sistem lawas (baca tentang ini di suatu tempat) masih menyebarkan kata sandi dalam plaintext - jadi tidak mengizinkan ruang di sana mungkin masuk akal. Juga, beberapa aplikasi mungkin "menghapus" semua input string yang mereka terima. Jadi, kata sandi yang dimulai atau diakhiri dengan spasi tidak akan bagus (tentu saja, itu sudah dibuat-buat, tetapi Anda bisa membayangkan apa yang tidak bisa terjadi dengan hampir semua orang yang datang dengan situsnya sendiri). Tidak ada yang "buruk" dalam memberikan spasi pada kata sandi - seperti yang Anda tunjukkan, DB tidak akan melarang hash atau versi plaintext.

Sebenarnya sebagian besar teman Windows saya tidak tahu bahwa mereka dapat menggunakan spasi di kata sandi mereka - Jadi, mungkin, sesuai jawaban Tim Medora, pemilik situs tidak ingin mengambil risiko dengan lamah (maafkan itu) atau mungkin beberapa dari mereka memiliki kesalahpahaman dan / atau tidak tahu manfaat yang bisa diberikan ruang.

Ini dilakukan dengan alasan yang sama bahwa banyak situs tidak mengizinkan tanda hubung, apostrof, atau huruf non-ASCII dalam nama, meskipun ini adalah praktik yang sangat umum bahkan hanya di AS dan memerlukan lebih banyak pekerjaan untuk melarang karakter ini daripada hanya mengizinkan mereka.

Ini juga dilakukan karena alasan yang sama dengan banyak filter kata situs tidak akan membiarkan Anda menggunakan kata-kata seperti "sombong", "tahan" atau bahkan "menumpuk" (meskipun banyak penghinaan ras umum baik-baik saja).

Itu karena banyak pengembang tampaknya benar-benar kurang masuk akal, atau setidaknya memiliki imajinasi yang sangat terbatas ketika mempertimbangkan kemungkinan input dan skenario pengguna. Sebagian kecil dari mereka mungkin bekerja dari informasi palsu (yang mengecualikan karakter non-alfanumerik entah bagaimana merupakan praktik standar, atau bahwa algoritma hashing atau metode penyimpanan tidak dapat menangani spasi atau karakter khusus). Orang lain mungkin malas — mereka khawatir tentang masalah rangkaian karakter, sehingga mereka hanya membatasi input ke ruang karakter minimal. Dan kemudian mungkin ada orang-orang yang menggunakan validasi / sanitasi input terlalu bersemangat karena paranoia karena kurangnya pemahaman tentang ancaman nyata.