Menghukum pengguna karena kata sandi tidak aman [ditutup]

Saya sedang berpikir tentang membatasi hak-hak pengguna yang memilih kata sandi tidak aman (ketidakamanan kata sandi ditentukan oleh panjangnya, berapa banyak jenis karakter (huruf besar / kecil, angka, simbol, dll.) Yang digunakan, dan apakah itu dapat terletak di tabel pelangi) untuk membatasi berapa banyak kerusakan yang dapat dilakukan akun mereka jika dikompromikan.

Saya belum memiliki aplikasi untuk ide ini, tetapi katakan saya sedang menulis forum atau sesuatu: Pengguna yang menggunakan 1234 sebagai kata sandi mungkin harus mengisi captcha sebelum memposting, atau tunduk pada langkah-langkah anti-spam yang ketat seperti sebagai batas waktu atau filter Bayesian yang menolak konten mereka. Jika forum ini sangat hierarkis, memungkinkan untuk "promosi" ke moderator atau apa pun dengan cara apa pun, ini akan menghentikan mereka dari mendapatkan hak istimewa sama sekali atau mengatakan kepada mereka bahwa mereka memiliki hak istimewa, tetapi tidak membiarkan mereka menggunakan mereka tanpa perubahan ke yang lebih aman kata sandi.

Tentu saja ini tidak bisa menjadi satu-satunya ukuran keamanan, tetapi mungkin berjalan baik di samping praktik keamanan yang baik.

Bagaimana menurut anda? Apakah ini hanya berlebihan, mencuri fokus dari praktik keamanan yang lebih penting, atau apakah itu cara yang baik untuk membatasi risiko dan mendorong pengguna untuk menggunakan kata sandi yang lebih aman (dan mudah-mudahan meyakinkan orang bahwa Anda menggunakan praktik keamanan yang baik)?

YAGNI , CIUMAN , KERING , aturan 10 detik dan fakta bahwa "[kamu] tidak peduli tentang ANDA" mungkin harus mempersempitnya menjadi satu solusi: Jangan.

• Ini lebih banyak pekerjaan pengembangan yang akan membutuhkan banyak pengujian untuk dapat diandalkan dan aman.
• Mungkin mengurangi keamanan situs dengan cara apa pun Anda melihatnya. Kemungkinan beberapa bug yang mengarah ke eskalasi hak istimewa dengan kata sandi yang mengerikan terlalu besar.
• Ini meningkatkan kompleksitas untuk pengembang, penguji, pemelihara, DBA, sysadmin dan pengguna.
• Semakin kompleks, semakin sulit untuk menghindari mengulangi diri Anda dengan cara tertentu.
• Pengguna tidak memiliki rentang perhatian untuk membaca informasi Anda dan menindaklanjutinya. Mereka terbiasa men-tweak formulir pendaftaran hingga menerima input, tidak sampai mereka mencapai tingkat ideal.
• Pengguna tidak peduli.

Entah memaksakan kata sandi aman pada perubahan registrasi, atau menggunakan OpenId (Jeff Atwood's 2c: http://www.codinghorror.com/blog/2010/11/your-internet-drivers-license.html ). Kemudian berkonsentrasi pada fungsionalitas yang lebih menarik.

Untuk satu hal, pengguna terbiasa dipaksa membuat kata sandi aman atau menggunakan OpenID mereka, jadi itu mudah bagi mereka.

Mengapa membiarkan kata sandi yang Anda anggap buruk pada awalnya? Menghentikan masalah pada sumbernya akan menghemat banyak waktu desain untuk mencari tahu kelas-kelas kata sandi yang dipetakan ke peran apa. Karena seorang admin, menurut definisi, akan memiliki hak penuh, Anda akan memerlukan fungsionalitas untuk memastikan dia tidak memasukkan kata sandi yang akan membatasi dirinya.

Jawaban saya benar-benar sampai pada CIUMAN .

Sebagai pengguna, itu mungkin akan meyakinkan saya untuk tidak menggunakan situs Anda. Maksud saya, sungguh-sungguh, bank saya memberi tahu saya kode 6 digit sangat aman untuk perbankan online, tetapi ketika saya ingin menulis komentar ke beberapa blog yang kurang dikenal, saya seharusnya mengingat kata sandi unik yang berisi setidaknya 8 angka di atas - dan karakter huruf kecil, digit, karakter khusus dan simbol Yunani atau Sirilik yang hanya dapat dimasukkan jika Anda mengetahui urutan unicode dengan hati. Dan mengubahnya secara teratur.

Jangan salah paham, keamanan itu penting. Tetapi jika Anda tidak boleh mengganggu pengguna Anda kecuali Anda memiliki alasan kuat untuk percaya bahwa seseorang akan mencoba memecahkan kata sandi mereka untuk mendapatkan akses ke situs Anda. Jika situs Anda kebetulan menyediakan akses VPN ke jaringan FBI, silakan, jengkel. Tetapi jika itu adalah forum pengguna tempat siapa pun yang memiliki alamat email dapat mendaftar, apa gunanya?

Solusi yang lebih baik: wajah tersenyum.

Aku serius! Membaca buku ekonomi behavioral seperti "Nudge: Meningkatkan Keputusan Tentang Kesehatan, Kekayaan, dan Kebahagiaan" telah meyakinkan saya tentang beberapa hal:

1. Anda tidak bisa memaksa semua orang untuk membuat keputusan yang bijak.
2. Orang suka bebas memilih, tetapi mereka tidak suka banyak pilihan.
3. Namun, Anda dapat secara signifikan memengaruhi pilihan mereka menjadi lebih baik dengan trik sederhana.

Saya melihat prinsip-prinsip ini berlaku untuk situasi Anda seperti ini:

1. Membatasi pengguna berdasarkan kata sandi tidak aman kemungkinan besar akan membuat frustrasi dan membingungkan mereka ... terutama bagi sebagian besar orang yang tidak membaca penjelasan yang ditulis dengan hati-hati di kotak dialog, dan hanya memanggil Helpdesk untuk mengatakan, "Itu tidak kerja."
2. Saat membuat kata sandi, pengguna tidak perlu melihat daftar semua kemungkinan karakter khusus dan yang dapat mereka gunakan. Lebih baik untuk menunjukkan kepada mereka sedikit pop-up yang menyarankan mereka menambahkan beberapa kompleksitas hanya jika entri mereka tidak memenuhi persyaratan.
3. Orang-orang sangat dipengaruhi oleh isyarat sosial - bahkan yang kecil seperti wajah bahagia menunjukkan bahwa kita menyetujui perilaku mereka, atau wajah cemberut jika kita tidak. Beberapa situs web yang dirancang lebih baik akan menampilkan bilah kemajuan berwarna yang berubah dari merah menjadi Tidak cukup baik :( menjadi hijau untuk Kerja bagus! :) saat pengguna mengetikkan kata sandi dan konfirmasi (diusulkan). UI ini memberi mereka beberapa tekanan sosial untuk memenuhi standar - untuk membuat bar berubah menjadi hijau, atau mengubah kerutan menjadi senyuman - saat mereka menemukan sendiri cara membuat kata sandi yang lebih aman dengan bantuan umpan balik langsung dari perubahan warna.

Bukan untuk menumpuk, tapi saya memikirkan alasan lain untuk mengajukan ini di bawah "Gagasan Buruk" yang belum saya lihat disebutkan - dukungan pelanggan.

Jika ini adalah produk yang akan memiliki perwakilan dukungan pelanggan di belakangnya, mereka tidak akan terlalu menyukai ini. Salah satu asumsi yang mendasari dukungan adalah bahwa mereka memahami dan dapat memprediksi pengalaman pengguna - jika mereka membantu pengguna biasa, maka Halaman 1 harus memiliki tautan ke Halaman 2, 3, dan 4, di mana mereka dapat melakukan X, Y, Z , dll.

Sekarang, Anda memberi mereka variabel lain yang harus mereka perhatikan. Jika pengguna tidak melihat tautan ke halaman, apakah itu karena mereka melakukan sesuatu yang bodoh? Atau apakah itu karena kata sandi mereka payah dan sistem Anda menghukum mereka dengan menolak akses mereka ke Halaman 4? Tunggu ... omong kosong, apakah menolak akses ke salah satu hukuman untuk kata sandi yang buruk, atau apakah saya memikirkan Page 5? Biarkan saya melihat ke atas, hanya satu saat ... oke, dikatakan bahwa untuk kata sandi yang tidak mencampur huruf besar dan kecil, akses ke halaman bernomor genap diperbolehkan tetapi dibatasi hanya untuk baca saja ... oke, Pak, kata sandi Anda, apakah itu terdiri dari semua huruf besar atau semua huruf kecil? Kasus. Saat Anda mengetikkan huruf, itu huruf kecil; ketika Anda menggunakan shift, saat itulah huruf besar. Apakah Anda mencampur case dalam kata sandi Anda? Kata sandi yang Anda gunakan untuk masuk ke sistem. Yang baru saja kamu gunakan. Oke, buka Edit, lalu pilih Preferensi, lalu Keamanan. Pilih "Kata Sandi Tersimpan" ... tidak, tuan, saya tidak dapat melihat kata sandi Anda dari sini ....

Ya. Jangan lakukan ini.

Batasi kata sandi atau beri tahu pengguna tentang risiko kata sandi yang lemah. Saya kira jika pengguna tidak peduli dengan data mereka, Anda mungkin ingin membatasi akses ke yang lain. Mungkin pengguna merasa lebih percaya diri jika mereka yang mengikuti praktik kata sandi yang ceroboh disingkirkan. Apa gunanya meminta kata sandi yang lebih kuat jika akan berakhir dengan catatan tempel di bawah keyboard atau ditempelkan ke laptop (Tidak dapat memperbaikinya; saya sudah melihatnya terjadi.).

dan apakah itu dapat ditemukan di meja pelangi

Saya kira maksud Anda kamus dan bukan tabel pelangi. Serangan kamus berfungsi hanya dengan menguji semua kata kamus jika cocok dengan kata sandi. Serangan ini dapat diperbaiki dengan 5 upaya dan memblokir selama x menit ...

Tabel pelangi hanya akan digunakan jika Anda memiliki kata sandi dan penyerang tahu hash. Daripada dia mungkin bisa menemukan hash di tabel pelangi jika itu hanya "12345" atau yang serupa.

Hanya untuk menyelesaikan perjalanan pulang-pergi: Untuk membuat meja pelangi tidak berguna, Anda harus memberi garam kata sandi. Dan gunakan garam unqiue untuk setiap kata sandi dan bukan hanya satu untuk semua. Jika Anda melakukan itu, penyerang perlu membuat tabel pelangi dengan garam unik untuk setiap akun yang ingin diakses. Pandai dilakukan oleh sisi Anda, Anda dapat membumbui hashing dengan concatenation multiple hash algoritma sehingga satu generasi mungkin membutuhkan setengah detik. Jika Anda telah melakukan ini, mengakses akun di situs web Anda harus bernilai berhari-hari, mungkin sebulan menghasilkan hash untuk menemukan kecocokan dengan akun ini ... Saya tidak bisa memikirkan penyerang yang akan mencoba mendapatkan semua kata sandi ketika itu akan butuh waktu lama.

Untuk saat hashing: Pikirkan sekitar 500 ms waktu tunggu untuk mekanisme login. Saya pikir itu dapat diterima ... (pengingat: hampir satu detik membutuhkan jabat tangan untuk SSL)