it-swarm-id.com

Mengapa situs menerapkan penguncian setelah tiga upaya kata sandi yang gagal?

Saya tahu alasan di balik tidak membiarkan upaya kata sandi yang tak terbatas - upaya brute force bukan meatspace kelemahan, tetapi masalah dengan keamanan komputer - tetapi dari mana mereka mendapatkan nomor tiga?

Bukankah penolakan layanan merupakan masalah saat menerapkan kebijakan penguncian yang mudah diaktifkan?

Apakah ada penelitian keras yang menunjukkan jumlah atau rentang optimal untuk dipilih sebelum mengunci akun yang menyeimbangkan ancaman keamanan aktual dengan kegunaan?

Memikirkannya secara menyeluruh, saya tidak melihat perbedaan keamanan yang dapat diukur antara tiga upaya dan 20 upaya dengan kompleksitas kata sandi yang umumnya digunakan saat ini.

(Saya tahu ini rok subjektivitas, tapi saya sedang mencari pendapat berdasarkan pengukuran)

107
Bradley Kreider

Baru-baru ini, pada konferensi OWASP AppSec 2010 di Orange County, Bill Cheswick dari AT&T berbicara panjang lebar tentang masalah ini.

Singkatnya, ada penelitian yang tidak memadai.

Dalam jangka panjang, berikut adalah beberapa idenya untuk penguncian akun yang kurang menyakitkan:

  • Jangan hitung upaya kata sandi duplikat (mereka mungkin berpikir mereka salah mengetiknya)
  • Buat petunjuk kata sandi tentang kata sandi utama, dan jangan gunakan kata sandi (lemah)
  • Izinkan pihak tepercaya menjamin pengguna, sehingga ia dapat mengubah kata sandi.
  • Kunci akun dalam peningkatan waktu yang meningkat
  • Ingatkan pengguna aturan kata sandi.
75
Zian Choy

Situs web mana pun yang mematuhi Standar Keamanan Data PCI harus mematuhi bagian

  • 8.5.13 (Batasi upaya akses berulang dengan mengunci ID pengguna setelah tidak lebih dari enam upaya)
  • 8.5.14 (Atur durasi penguncian ke tiga puluh menit atau sampai administrator mengaktifkan ID pengguna).

Ini sayangnya mengapa banyak situs yang menerima kartu kredit memiliki kebijakan penguncian yang kejam, meskipun desainer mereka mungkin tidak selalu setuju dengan apa yang telah mereka terapkan.

Edit: Perhatikan bahwa persyaratan ini hanya berlaku untuk sistem "pengguna non-konsumen" sehingga mereka tidak mempengaruhi situs pelanggan yang menerima kartu.

37
realworldcoder

Pengalaman saya adalah mekanisme kunci semakin berkurang dalam popularitas (setidaknya untuk aplikasi web). Alih-alih mengunci akun setelah serangkaian upaya gagal, Anda mulai meminta informasi tambahan agar otentikasi berhasil.

22
Tate Hansen

Tidak akan terkejut jika itu berasal dari aturan "Tiga serangan" bisbol daripada apa pun teknis.

Satu justifikasi (untuk kata sandi alfanumerik) adalah

Biasanya upaya yang gagal adalah salah ketik atau masalah on/off CAPS. Jadi, Anda mencoba masuk dan ditolak (1), coba lagi karena Anda pikir Anda salah mengetik (2) dan kemudian menyadari bahwa kunci CAPS aktif sehingga Anda masuk pada upaya ketiga.

Tidak benar-benar tahan untuk membuka kunci ponsel dari jaringan ketika biasanya kode numerik sedang dimasukkan.

Saran yang lebih baik adalah penundaan yang terus meningkat antara upaya login gagal yang berturut-turut. Pertama Anda mengizinkan coba lagi instan, lalu 1 detik, 2, empat, delapan ... Anda dengan cepat menunggu satu menit di antara upaya yang cukup untuk mensimulasikan serangan brute force.

18
Gary

Saya setuju dengan OP. Jika Anda berpikir tentang apa yang dilindungi lockout terhadap Anda, tidak ada perbedaan antara 3 atau 20 upaya (atau 100, dalam hal ini). Yang Anda capai dengan penguncian ini, selain menghukum pengguna yang pelupa, adalah untuk mencegah serangan brutal. Anda juga dapat menggunakannya untuk memicu peringatan bahwa serangan sedang berlangsung, tetapi itu bukan tujuan utama (jika itu, itu berarti Anda sengaja melakukan DoSing pengguna Anda hanya untuk membuat pekerjaan pemantauan Anda sendiri lebih mudah. ​​Itu bukan praktik yang sangat baik).

Jika seseorang memiliki basis data kata sandi Anda, dan dapat meretasnya secara off-line, mereka akan mencoba tanpa batas. Batas 20 tebakan Anda tidak bagus di sana.

Jika seseorang mencoba kekerasan online, yang Anda butuhkan adalah kata sandi yang dapat bertahan untuk "cukup lama": cukup lama bagi IRT Anda untuk merespons, atau cukup lama bagi penyerang Anda untuk menyerah.

Basis data kata sandi Conficker sedikit di bawah 200 kata sandi, IIRC, dan diisi dengan beberapa kata sandi paling bodoh di planet ini. Sekarang mari kita asumsikan bahwa kata sandi Anda tidak ada dalam daftar ini. Jika Anda mengizinkan 20 percobaan kata sandi, katakanlah per 15 menit, tanpa mengunci, itu akan membutuhkan seorang penyerang lebih dari dua jam hanya untuk melewati daftar itu.

Bahkan, bahkan jika Anda mempersempit daftar tebakan Anda menjadi kata sandi yang dibuat dari info yang relevan tentang pengguna itu, seperti kidsname02, birthday99 dll, Anda masih akan berakhir dengan setidaknya beberapa puluh kata sandi, memperluas serangan kamus hingga mungkin satu jam atau lebih. Tebakan konstan dan keliru dari waktu ke waktu itulah yang seharusnya memicu alarm Anda, bukan segelintir kata sandi yang salah dalam beberapa menit.

Jadi, jika Anda dapat menjauhkan pengguna dari jebakan kata sandi paling dasar, Anda dapat dengan senang hati menerima banyak upaya kata sandi yang salah.

Secara pribadi, saya menarik garis di 15. Benar-benar sewenang-wenang, dan sebagian besar hal yang praktis: Saya menemukan bahwa setiap pengguna nyata telah menyerah jauh sebelum ini. Biasanya jika ada banyak upaya, itu adalah proses atau sesi yang tergantung di suatu tempat dengan kredensial lama. Dan jika itu tidak terjadi, maka kita dapat berbicara tentang mencari serangan.

15
itinsecurity

Ini aturan arbitrer konyol yang datang dengan risiko serangan DDOS yang aneh. Katakanlah Marv membenci situs web X dan situs web X memiliki sejumlah kebijakan upaya mengunci. Marv dapat menimbulkan masalah serius dengan memiliki skrip yang secara otomatis mencoba nama acak Y kali dengan kata sandi palsu. Bahkan jika kata sandi berfungsi, Marv kemungkinan tidak akan peduli dan mengabaikannya. Ini secara efektif akan mengunci banyak pengguna untuk situs web X dan menyebabkan banyak frustrasi pengguna, dan tuhan bantu mereka jika mereka adalah bank yang harus Anda hubungi untuk mengatur ulang kata sandi Anda. Saya terkejut tidak ada yang mencoba ini.

11
AmaDaden

Saya yakin saya terlambat untuk debat ini, tapi saya harap ada sesuatu yang berguna untuk ditambahkan di sini.

Kebijakan penguncian akun (dengan jumlah upaya tidak sah berturut-turut biasanya dalam kisaran satu digit untuk sebagian besar organisasi) tidak dirancang hanya terhadap serangan brute force otomatis.

Ini lebih merupakan perlindungan terhadap tebakan kata sandi oleh penyerang manusia, terutama oleh individu yang sudah mengetahui sebagian kata sandi. Penyerang dapat memperoleh fragmen kata sandi dengan

  • selancar bahu
  • dengan menebak pola yang digunakan oleh seseorang untuk memilih kata sandi mereka. Setelah semua, berapa kali memiliki satu kata sandi yang digunakan dengan elemen dalam urutan, seperti kata sandi # 01 , kata sandi # 02 dll.

Kelemahannya tentu saja, adalah bahwa dengan nilai ambang batas rendah, pasti ada penolakan layanan, dan biaya yang terkait dengan bisnis. Buku Putih Praktik Terbaik Penguncian Akun yang dikeluarkan oleh Microsoft, memberikan nilai yang disarankan sebesar 10. Ini juga menjelaskan cara memperkirakan kemungkinan serangan yang berhasil, menggunakan parameter dalam kebijakan penguncian akun Windows:

Sebagai contoh, asumsikan bahwa administrator me-reset kata sandi ketika akun dikunci dengan nilai registri LockoutDuration dari 0. Dengan nilai registri LockoutDuration diatur ke 0 dan nilai registri LockoutThreshold diatur ke 20, pengguna jahat memiliki 20 tebakan untuk digunakan terhadap itu kata sandi. Jika durasi penguncian adalah 30 menit, pengguna jahat memiliki 20 tebakan setiap 30 menit terhadap kata sandi itu sampai diubah. Ini adalah perbedaan yang sangat signifikan dalam jumlah total tebakan yang tersedia untuk pengguna jahat.

Sebagai perbandingan, jika administrator menetapkan usia kata sandi maksimum menjadi 42 hari, pengguna jahat pertama hanya memiliki 20 tebakan terhadap kata sandi yang diberikan, sedangkan pengguna jahat kedua memiliki 40.320 tebakan (20 percobaan untuk penguncian selamanya, dikalikan dengan 48 penguncian setiap hari, dikalikan dengan 42 hari sebelum pengguna mengubah kata sandi). Dengan pengaturan kata sandi default, ada sekitar 10 ^ 12 kata sandi yang memungkinkan. Ini berarti bahwa pengguna jahat memiliki peluang sekitar 0,000004 persen (%) untuk menebak kata sandi. Dengan skema tebakan yang dioptimalkan, persentase ini kemungkinan besar akan menjadi persentase yang lebih besar.

Tentu saja, tidak mudah bagi orang awam mana pun untuk memilih nomor yang cocok, dan keputusan semacam itu harus dipertimbangkan dengan cermat. Oleh karena itu, dapat diasumsikan dengan aman bahwa beberapa organisasi belum berupaya menghitung efek moneter dari kebijakan penguncian akun mereka, dan manfaat terkait dengan melonggarkan kebijakan mereka sambil mempertahankan manfaat keamanan yang diberikannya.

10
Vineet Reynolds

Ada dua aspek dalam hal ini; yang pertama, seperti yang Anda sebutkan, adalah mencegah serangan brute-force.

Untuk tujuan ini, harus dilakukan sejumlah percobaan - 3, 5, 20, 2000 ... dengan kebijakan kata sandi yang tepat (panjang + kompleksitas + ...) memberikan ruang kunci yang cukup besar, apa saja jenis pelambatan (jumlah percobaan X per jam) akan memastikan bahwa kekerasan yang memaksa seluruh ruang akan memakan waktu beberapa dekade. (Lakukan matematika).

Sekalipun - dan ini harus menjadi persyaratan - penguncian hanya sementara, dan setelah beberapa saat, secara otomatis akan terbuka.

Dengan demikian, jumlah percobaan-sebelum-penguncian adalah arbitrer.

Namun, ada masalah non-matematis lain yang lebih halus yang dimainkan di sini:

Sama sekali tidak masuk akal bagi satu pengguna untuk berulang kali memasukkan kata sandi yang salah sebanyak 2000 kali berturut-turut.

Artinya, jika Anda secara acak memilih 2000, Anda tahu lama sebelum itu bahwa ini BUKAN pengguna yang sah. Dengan demikian, itu benar-benar bermuara pada apa yang masuk akal bisnis, dan analisis risiko yang berfokus pada bisnis dipertukarkan.

Saya pikir secara historis, trade-off lebih condong ke sisi risiko - karena kata sandi lebih pendek dan kurang kompleks, perbedaan 3 atau 10 lebih besar. Selain itu, orang memiliki lebih sedikit kata sandi, sehingga lebih mudah diingat ... Dan, pengguna secara teknis lebih mengerti secara umum.

Saat ini, tiga benar-benar tidak masuk akal, mengingat dampak bisnis. Ini benar-benar sebuah pertanyaan tentang apa yang masuk akal untuk aplikasi Anda, jenis pengguna apa, seberapa sering mereka login, dll. Saya biasanya merekomendasikan untuk mencari tahu berapa banyak upaya gagal, sah yang mungkin dilakukan , lalu gandakan.

( Seperti yang disebutkan @realworldcoder , PCI secara sewenang-wenang memilih enam, dan jika Anda tunduk pada PCI, Anda tidak memiliki banyak keputusan di sini. Jika tidak, pilih nomor yang masuk akal untuk Anda.)

8
AviD

Berkenaan dengan saran penambahan waktu 'lock-out' untuk menunda upaya yang gagal berturut-turut dan karenanya mencegah kekerasan, jangan ingat ini hanya bekerja pada serangan pengguna yang ditargetkan.

Jika penyerang hanya peduli untuk mendapatkan masuk ke sistem, mereka dapat melakukan serangan pertama yang luas (Siklus semua nama pengguna yang diketahui/tebak sebelum bersepeda ke kata sandi berikutnya). Tambahkan bahwa jika dilakukan dengan benar, itu bisa berasal dari jaringan mesin terdistribusi, cukup mudah untuk melihat bahwa sistem penundaan tidak berfungsi baik.

Seperti yang disebutkan oleh orang lain, pemantauan yang benar atas upaya yang gagal untuk menemukan serangan awal sangat penting.

Ya, 3 upaya cukup sewenang-wenang dan menimbulkan risiko DoS. Saya benar-benar berharap orang akan berhenti menggunakan untuk sistem yang menghadap publik ... Tolong!

Solusi lain: identifikasi 2 faktor. Token RSA. Kalau saja kita punya cara untuk secara pribadi memiliki token RSA tunggal dengan 'nomor id'. Kami kemudian dapat mendaftarkan 'nomor id' ini dengan sistem apa pun, yang kemudian akan memerlukan nilai saat ini dari token bersama dengan kata sandi untuk masuk.

Tapi itu menimbulkan banyak masalah untuk implementasi dan kepercayaan ...

7
Dan McGrath

Perusahaan yang bersifat publik (menjual saham di bursa efek) diatur berdasarkan Sarbanes-Oxley Act dan diaudit beberapa kali setahun untuk kepatuhan. Aplikasi perangkat lunak penting harus mematuhi fitur keamanan tertentu, salah satunya untuk mengunci akun setelah upaya sandi gagal.

Mayoritas dari aplikasi ini yang mereka lakukan adalah mengintegrasikan ke dalam Active Directory perusahaan yang sudah mengaktifkan fitur-fiturnya.

3
Jose

Ini bacaan yang sangat bagus yang melampaui apa yang saya yakin Anda cari. Mereka mengambil data dari mahasiswa menggunakan kebijakan tiga-mogok, kebijakan sepuluh-mogok, dan kebijakan tak terbatas untuk menyarankan kami meningkatkan jumlahnya dari tiga menjadi sepuluh (karena kira-kira tiga kali lipat keberhasilan masuk).

Kembali ke pandangan subjektif di sini ...

Mengapa sebagian besar tempat menggunakan kebijakan tiga pukulan? Ini tentu saja hanya heuristik yang berkembang seiring waktu. Tiga upaya lebih atau kurang merupakan jalan tengah bagi administrator dan pengguna, dalam tiga peluang itu lebih dari cukup.

Gagasan di balik kata sandi adalah Anda seharusnya mengetahuinya. Anda benar-benar tidak boleh perlu lebih dari satu kali mencoba. Saya mengerti bahwa ada kesalahan, tetapi dalam perang ... Anda benar-benar hanya mendapatkan satu kesempatan untuk membuktikan bahwa Anda adalah sekutu, bukan ?.

3
user124863

Mereka harus memilih 3 secara acak. Ini sangat rendah. Mungkin mereka telah memiliki masalah keamanan di masa lalu dan telah memilih nomor penguncian rendah daripada mengatasi atau memperbaiki masalah dengan benar.

Saya lebih suka metode mengunci pengguna dalam meningkatkan penambahan waktu. Saya tidak akan menguncinya dari nama pengguna, melainkan menggunakan alamat IP orang tersebut, karena orang tersebut dapat mencoba beberapa nama pengguna. Saya mengatur waktu penguncian ke (jumlah upaya masuk yang tidak valid) ^ 2 detik, setelah pengguna mencapai 5 upaya yang tidak valid. Jika pengguna tidak mengetahui kata sandi mereka dalam jumlah upaya yang relatif rendah, sebagian besar mereka akan menggunakan alat pemulihan kata sandi jika situs menyediakannya. Jika ini adalah upaya hack yang benar, itu akan membuat frustasi bagi hacker sehingga pada akhirnya mereka akan menyerah. Bot akan mencoba berkali-kali sehingga mereka hampir tidak akan pernah diizinkan masuk ... misalnya, jika mereka mencoba 1000 kata sandi (yang akan memakan waktu lama untuk benar-benar melakukan anyways) mereka harus menunggu 11 1/2 hari sebelum mereka bisa coba kata sandi ke-1001. Anda dapat dengan mudah meningkatkan kemampuan pencegahan dengan meningkatkan pengali ke ^ 3. Apa pun di atas yang mungkin sedikit terlalu tinggi untuk pengguna manusia yang valid.

2
Rush Frisby

Belum lama ini saya menerapkan skema keamanan login yang mengikuti aturan dasar ini:

  1. Upaya pertama yang gagal memberikan umpan balik segera. Mereka mungkin gemuk meraba itu.
  2. Upaya gagal kedua hingga kelima menyebabkan respons tertunda satu detik per upaya yang gagal. mis. 2 detik, 3 detik, 4 detik ...
  3. Jika upaya kelima gagal, maka sesi itu berakhir dan mereka disajikan dengan pesan yang menunjukkan bahwa mereka harus menutup browser mereka dan coba lagi.

Bagi saya ini lebih dari cukup untuk mencegah serangan brute force; paling banyak akan merepotkan pengguna akhir, dan tidak membuat pekerjaan tambahan untuk dukungan.

2
Josh