Kelemahan Keamanan 3-Strike


10

Saya telah membaca beberapa literatur tentang keamanan, khususnya keamanan / enkripsi kata sandi, dan ada satu hal yang saya ingin tahu: apakah aturan 3-serangan merupakan solusi sempurna untuk keamanan kata sandi? Yaitu, jika jumlah upaya kata sandi terbatas pada sejumlah kecil, setelah semua permintaan otentikasi tidak dihormati, apakah itu tidak akan melindungi pengguna dari gangguan? Saya menyadari mendapatkan akses atau kontrol atas sesuatu tidak selalu berarti melalui sistem otentikasi, tetapi tidakkah fitur ini membuat serangan kamus / brute-force menjadi usang? Apakah ada sesuatu yang saya lewatkan?


3
Pertanyaan ini mungkin lebih baik ditanyakan di Keamanan untuk referensi di masa mendatang.
maple_shaft

1
Seperti yang saya temukan, selalu ada tempat yang lebih tepat untuk ditanyakan. Terima kasih, saya akan mencoba dan mengingatnya.
prelic

Jawaban:


13

Ya, itu akan membuat serangan kamus menjadi mustahil melalui mekanisme login . (Namun, itu tidak berarti banyak jika mereka mendapatkan akses ke database. Untuk keamanan di sana, Anda perlu hash dan salt password dengan benar.)

Ini juga memungkinkan kemungkinan serangan DOS terhadap pengguna tertentu. Katakanlah saya ingin mencegah Anda masuk. Yang harus saya lakukan adalah menjalankan tiga upaya login palsu terhadap akun Anda, dan kemudian melakukannya lagi setiap kali Anda melakukan apa pun yang diperlukan untuk mengatur ulang login. Berurusan dengan masalah itu agak sulit.


1
Terima kasih! Karena penasaran, apa yang akan menjadi pendekatan untuk menangani masalah terakhir yang Anda jelaskan? Sebagai contoh dunia nyata, banyak forum online menggunakan nama pengguna publik sebagai id login (bukan email yang dilampirkan ke acct atau sesuatu yang lain), yang berarti saya bisa melihat apa yang digunakan setiap pengguna untuk login. Apa yang mencegah saya mengunci setiap pengguna dari akun mereka? Administrator yang baik? Sepertinya sepele akan mudah untuk mengunci setiap pengguna dari situs.
prelic

@prelic: Baiklah, untuk mengatasi masalah itu, saya akan mengimplementasikan sesuatu seperti "jika alamat IP tertentu membuat terlalu banyak upaya masuk yang tidak valid, blokir mereka." Itu akan menghentikan skenario yang Anda sebutkan, tetapi itu tidak akan berurusan dengan upaya hack serius seperti botnet. Untuk itu Anda membutuhkan keamanan yang lebih berat.
Mason Wheeler

4
Solusi yang biasa adalah untuk membatasi laju upaya yang datang untuk pengguna tertentu dari IP tetap untuk mengatakan 5 per menit. Itu tidak sempurna tetapi biasanya Anda tidak membuat masalah kepada pengguna lain, kecuali jika Anda berada di belakang proxy yang sama
Andrea

Pendekatan lain adalah menghadirkan captcha setelah 2 upaya login gagal dari IP yang sama - tetapi kemudian, seorang penyerang yang gigih hanya dapat menyewa turk mekanik pemecahan-captcha untuk tujuan ini, plus itu cukup sulit untuk menemukan captcha yang baik yang benar-benar menjaga mesin di luar.
tdammers

3

Saya juga setuju bahwa itu membuat serangan kamus kurang efektif sebagai cara untuk mendapatkan akses ke akun tanpa otoritas yang tepat. Namun:

  • Pendekatan ini dapat mengubah serangan kamus menjadi serangan DOS terhadap sistem yang mencegah akses jika diimplementasikan dengan buruk. Misalnya, server dapat dibanjiri dengan upaya otentikasi. Salah satu cara mengatasi hal ini adalah dengan meminta layanan autentikasi mengendalikan aliran akses selanjutnya ke akun yang dikunci. Misalnya, jika akun dikunci, berikan penundaan sebelum setiap upaya masuk berikutnya. Seseorang dapat menunda antara upaya login dan `akses ditolak ', namun, yang membuat pintu tetap terbuka terhadap serangan penolakan layanan terdistribusi di mana penyerang meluncurkan banyak upaya otentikasi simultan.

  • Seperti yang disebutkan dalam jawaban lain, ini juga bisa mengubah serangan kamus menjadi DOS mentah terhadap pemilik sah akun yang sedang diserang. Cara untuk mengurangi dampak terhadap pemilik yang sah meliputi:

    • Memperlambat nama pengguna dengan tidak memberikan petunjuk apakah nama pengguna atau kata sandi yang salah. Ini membuat serangan di mana pelakunya menebak nama pengguna lebih terlihat oleh administrator dan kurang efektif.
    • Alih-alih mengunci akun setelah sejumlah upaya gagal yang gagal, hanya mengunci mode otentikasi itu. Dengan kata lain, mengharuskan pengguna yang akunnya diserang untuk mengautentikasi menggunakan metode yang berbeda (mungkin lebih banyak terlibat, tetapi kurang mudah diserang). Contoh yang baik adalah bagaimana ponsel Android akan mengharuskan pengguna untuk menggunakan informasi Google Login mereka setelah gagal mengautentikasi menggunakan pola buka kunci layar atau PIN. Secara teori, ini seperti mengharuskan pengguna yang diserang untuk meminta akun mereka tidak dikunci, namun, tidak memerlukan intervensi langsung dari administrator sistem.
    • Alih-alih mengunci akun (atau di samping mengunci akun, untuk mode otentikasi khusus ini - lihat di atas) mengunci upaya untuk mengotentikasi dari lokasi tempat serangan berasal. Misalnya, jika otentikasi dilakukan melalui nama pengguna dan kata sandi, melalui jaringan, setelah tiga upaya otentikasi gagal, Anda dapat mencegah upaya lebih lanjut dari pengguna dari IP atau subnet yang sama untuk masuk dengan nama pengguna atau kata sandi. Di mana ada peluang bagus bahwa banyak pengguna (termasuk penyerang) dapat menggunakan IP atau subnet yang sama, Anda hanya dapat menonaktifkan otentikasi nama pengguna / kata sandi untuk IP atau subnet selama jangka waktu tertentu, membiarkan metode otentikasi yang lebih terlibat terbuka bagi orang yang tidak bersalah pengguna yang dekat dengan penyerang.
  • Jika rasa takut Anda secara tidak sengaja menghukum pengguna yang pelupa seolah-olah mereka adalah seorang penyerang, alih-alih mengendalikan aliran upaya login yang gagal setelah sejumlah upaya gagal yang gagal, Anda dapat menggunakan frekuensi upaya login sebagai bukti bahwa akun sedang diserang. Misalnya, jika Anda melihat 10 upaya otentikasi dalam rentang detik, Anda dapat menggunakan salah satu metode di atas untuk mencegah upaya otentikasi serupa yang lebih jauh. Sebagai alternatif, Anda bisa menggunakan banjir ini upaya login sebagai sinyal untuk mulai mengontrol aliran. Metode ini menjadi lebih dan lebih populer di forum, sedangkan, setelah sejumlah upaya login gagal dari IP tertentu, IP tersebut dicegah dari otentikasi untuk periode waktu yang singkat.

  • Akhirnya, cara yang baik untuk mencegah pengguna berulang kali menjadi sasaran serangan DOS adalah dengan membiarkannya mengatur ulang kata sandi dan nama pengguna . Dengan kata lain, perlakukan baik nama pengguna dan kata sandi sebagai rahasia. Di mana nama pengguna digunakan di tempat lain (misalnya di forum, jika nama pengguna adalah nama tampilan pengguna), cukup memperlakukan nama tampilan ini sebagai sesuatu yang terpisah. Pendekatan ini biasanya digunakan oleh jejaring sosial di mana nama pengguna yang digunakan dalam otentikasi adalah alamat email seseorang - sesuatu yang dapat diubah, tetapi jarang dibagikan - sedangkan nama tampilan yang digunakan di situs adalah sesuatu yang ditentukan pengguna yang mungkin atau mungkin tidak diubah.

Bagaimanapun, saya berharap satu atau beberapa kombinasi dari pendekatan ini akan berguna.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.