Apa penanggulangan Brute Force Terdistribusi terbaik?


151

Pertama, sedikit latar belakang: Bukan rahasia bahwa saya menerapkan sistem auth + auth untuk CodeIgniter, dan sejauh ini saya menang (untuk berbicara). Tetapi saya telah menghadapi tantangan yang tidak sepele (salah satu yang paling banyak dilewatkan oleh perpustakaan autentik, tetapi saya bersikeras untuk menanganinya dengan benar): bagaimana menghadapi secara cerdas dengan serangan brute-force skala besar, terdistribusi, variabel-nama pengguna .

Saya tahu semua trik biasa:

  1. Membatasi # upaya gagal per IP / host dan menolak akses pelaku (mis. Fail2Ban) - yang tidak lagi berfungsi karena botnet semakin pintar
  2. Menggabungkan hal-hal di atas dengan daftar hitam dari IP / host 'buruk' yang dikenal (mis. DenyHosts) - yang bergantung pada botnet yang jatuh ke # 1, yang semakin lama semakin meningkat.
  3. Daftar putih IP / host dikombinasikan dengan auth tradisional (sayangnya tidak berguna dengan pengguna IP dinamis dan churn tinggi di sebagian besar situs web)
  4. Menetapkan batas seluruh situs pada # upaya yang gagal dalam periode N menit / jam, dan mencekik (menangguhkan) semua upaya login setelah itu selama beberapa menit / jam (dengan masalah bahwa serangan DoS Anda menjadi permainan anak botnet)
  5. Tanda tangan digital wajib (sertifikat kunci publik) atau token perangkat keras RSA untuk semua pengguna tanpa opsi masuk / kata sandi (tanpa pertanyaan solusi yang tepat, tetapi hanya praktis untuk layanan tertutup, khusus)
  6. Ditegakkan skema sandi ultra-kuat (misalnya> 25 karakter omong kosong dengan simbol - lagi, terlalu tidak praktis untuk pengguna biasa)
  7. Dan akhirnya, CAPTCHA (yang dapat bekerja dalam banyak kasus, tetapi menjengkelkan bagi pengguna dan hampir tidak berguna melawan penyerang yang gigih dan banyak akal )

Sekarang, ini hanya ide yang bisa diterapkan secara teoritis. Ada banyak ide sampah yang membuat situs terbuka lebar (misalnya serangan DoS yang sepele). Yang saya inginkan adalah sesuatu yang lebih baik. Dan lebih baik, maksud saya:

  • Itu harus aman (+) terhadap DoS dan serangan brute-force, dan tidak memperkenalkan kerentanan baru yang mungkin memungkinkan bot sedikit lebih licik untuk terus beroperasi di bawah radar

  • Itu harus otomatis. Jika memerlukan operator manusia untuk memverifikasi setiap login atau memantau aktivitas mencurigakan, itu tidak akan berfungsi dalam skenario dunia nyata

  • Itu harus layak untuk penggunaan web umum (mis. Churn tinggi, volume tinggi, dan pendaftaran terbuka yang dapat dilakukan oleh non-programmer)

  • Itu tidak dapat menghalangi pengalaman pengguna ke titik di mana pengguna biasa akan merasa kesal atau frustrasi (dan berpotensi meninggalkan situs)

  • Itu tidak bisa melibatkan anak kucing, kecuali mereka benar-benar anak kucing yang benar-benar aman

(+) Dengan 'aman', maksud saya setidaknya seaman kemampuan pengguna paranoid untuk merahasiakan kata sandinya

Jadi - mari kita dengarkan! Bagaimana Anda melakukannya ? Apakah Anda tahu praktik terbaik yang belum saya sebutkan (oh tolong katakan Anda lakukan)? Saya akui saya memiliki ide sendiri (menggabungkan ide dari 3 dan 4), tetapi saya akan membiarkan para pakar sejati berbicara sebelum mempermalukan diri saya ;-)

Jawaban:


68

Baiklah, cukup kemacetan; inilah yang saya buat sejauh ini

(Maaf, posting lama di depan. Berani, teman, perjalanan akan sia-sia)

Menggabungkan metode 3 dan 4 dari posting asli menjadi semacam 'fuzzy' atau daftar putih dinamis, dan kemudian - dan inilah triknya - tidak memblokir IP yang tidak masuk daftar putih, hanya mendorong mereka ke neraka dan kembali .

Perhatikan bahwa langkah ini hanya dimaksudkan untuk menggagalkan jenis serangan yang sangat spesifik ini. Dalam praktiknya, tentu saja, itu akan bekerja dalam kombinasi dengan pendekatan praktik terbaik lainnya untuk auth: pelambatan fixed-username, per-IP throttling, kebijakan kata sandi yang kuat yang diberlakukan kode, login cookie yang tidak dilacak, memasukkan semua kata sandi yang setara sebelum menyimpannya, tidak pernah menggunakan pertanyaan keamanan, dll.

Asumsi tentang skenario serangan

Jika penyerang menargetkan nama pengguna variabel, pembatasan nama pengguna kami tidak akan aktif. Jika penyerang menggunakan botnet atau memiliki akses ke rentang IP besar, pembatasan IP kami tidak berdaya. Jika penyerang telah membuat pra-memo daftar pengguna kami (biasanya dimungkinkan pada layanan web pendaftaran terbuka), kami tidak dapat mendeteksi serangan yang sedang berlangsung berdasarkan jumlah kesalahan 'pengguna tidak ditemukan'. Dan jika kita menerapkan pembatasan sistem (semua nama pengguna, semua IP) yang terbatas, serangan seperti itu akan merusak seluruh situs kami selama durasi serangan plus periode pembatasan.

Jadi kita perlu melakukan sesuatu yang lain.

Bagian pertama dari penanggulangan: Daftar putih

Apa yang bisa kita yakini dengan cukup jelas adalah bahwa penyerang tidak dapat mendeteksi dan secara spoof memalsukan alamat IP beberapa ribu pengguna kami (+). Yang membuat daftar putih menjadi layak. Dengan kata lain: untuk setiap pengguna, kami menyimpan daftar IP (hash) dari tempat pengguna sebelumnya (baru-baru ini) masuk.

Dengan demikian, skema daftar putih kami akan berfungsi sebagai 'pintu depan' yang terkunci, di mana pengguna harus terhubung dari salah satu IP 'baik' yang dikenalnya untuk dapat masuk sama sekali. Serangan brutal pada 'pintu depan' ini bisa dibilang mustahil (+).

(+) kecuali jika penyerang 'memiliki' baik server, semua kotak pengguna kami, atau koneksi itu sendiri - dan dalam kasus tersebut, kami tidak lagi memiliki masalah 'otentikasi', kami memiliki tarik ukuran waralaba asli - Situasi FAR-plug

Bagian kedua dari penanggulangan: Pembatasan seluruh sistem IP yang tidak dikenali

Untuk membuat daftar putih berfungsi untuk layanan web pendaftaran terbuka, di mana pengguna sering berganti komputer dan / atau menyambungkan dari alamat IP dinamis, kita perlu menjaga 'pintu kucing' tetap terbuka untuk pengguna yang terhubung dari IP yang tidak dikenal. Caranya adalah dengan mendesain pintu itu sehingga botnet macet, dan pengguna yang sah akan terganggu sesedikit mungkin .

Dalam skema saya, ini dicapai dengan menetapkan jumlah maksimum yang sangat ketat dari upaya login gagal oleh IP yang tidak disetujui, katakanlah, periode 3 jam (mungkin lebih bijaksana untuk menggunakan periode yang lebih pendek atau lebih lama tergantung pada jenis layanan), dan membuat batasan itu bersifat global , yaitu. untuk semua akun pengguna.

Bahkan brute force yang lambat (1-2 menit antar percobaan) akan terdeteksi dan digagalkan dengan cepat dan efektif menggunakan metode ini. Tentu saja, kekuatan brutal yang sangat lambat masih bisa tetap tidak diperhatikan, tetapi kecepatan yang terlalu lambat mengalahkan tujuan serangan brutal itu.

Apa yang ingin saya capai dengan mekanisme pelambatan ini adalah bahwa jika batas maksimum tercapai, 'pintu kucing' kami ditutup untuk sementara waktu, tetapi pintu depan kami tetap terbuka untuk pengguna yang sah yang terhubung dengan cara biasa:

  • Baik dengan menghubungkan dari salah satu IP yang dikenali mereka
  • Atau dengan menggunakan cookie login persisten (dari mana saja)

Satu-satunya pengguna yang sah yang akan terpengaruh selama serangan - yaitu. sementara pembatasan diaktifkan - akan menjadi pengguna tanpa cookie login persisten yang masuk dari lokasi yang tidak diketahui atau dengan IP dinamis. Para pengguna tidak akan bisa masuk sampai throttling hilang (yang berpotensi memakan waktu cukup lama, jika penyerang tetap menjalankan botnet-nya terlepas dari pembatasan).

Untuk memungkinkan sekelompok kecil pengguna ini masuk melalui pintu kucing yang tertutup rapat, meskipun bot masih memaluinya, saya akan menggunakan formulir login 'cadangan' dengan CAPTCHA. Sehingga, ketika Anda menampilkan pesan "Maaf, tetapi Anda tidak dapat masuk dari alamat IP ini saat ini", sertakan tautan yang mengatakan " masuk dengan aman cadangan - HANYA SAJA ( bot: tidak ada dusta ) ". Di samping itu, ketika mereka mengklik tautan itu, berikan mereka formulir login terautentikasi reCAPTCHA yang memintas pelambatan di seluruh situs. Dengan begitu, JIKA mereka manusia DAN mengetahui kata sandi login + yang benar (dan dapat membaca CAPTCHA), mereka tidak akan pernah ditolak layanan, bahkan jika mereka terhubung dari host yang tidak dikenal dan tidak menggunakan cookie autologin.

Oh, dan hanya untuk mengklarifikasi: Karena saya menganggap CAPTCHA secara umum jahat, opsi masuk 'cadangan' hanya akan muncul saat pembatasan sedang aktif .

Tidak dapat disangkal bahwa serangan berkelanjutan seperti itu masih akan merupakan bentuk serangan DoS, tetapi dengan sistem yang dijelaskan di sana, itu hanya akan mempengaruhi apa yang saya curigai sebagai sekelompok kecil pengguna, yaitu orang-orang yang tidak menggunakan cookie "ingat saya" DAN kebetulan masuk saat serangan terjadi DAN tidak masuk dari IP biasa mereka DAN siapa yang tidak bisa membaca CAPTCHA. Hanya mereka yang dapat mengatakan tidak kepada SEMUA kriteria itu - khususnya bot dan orang-orang cacat yang benar - benar sial - yang akan ditolak selama serangan bot.

Suntingan : Sebenarnya, saya memikirkan cara untuk membiarkan bahkan pengguna yang ditantang CAPTCHA melewatinya selama 'penguncian': alih-alih, atau sebagai pelengkap, cadangan masuk CAPTCHA, memberikan pengguna opsi untuk menggunakan sekali pakai , kode kuncian khusus pengguna yang dikirim ke emailnya, yang kemudian dapat ia gunakan untuk memotong pembatasan. Ini jelas melampaui ambang 'gangguan' saya, tetapi karena ini hanya digunakan sebagai upaya terakhir untuk sekelompok kecil pengguna, dan karena masih berdetak karena dikunci dari akun Anda, itu akan dapat diterima.

(Juga, perhatikan bahwa semua ini tidak terjadi jika serangannya kurang canggih dari versi terdistribusi buruk yang saya jelaskan di sini. Jika serangan itu datang dari hanya beberapa IP atau hanya mengenai beberapa nama pengguna, itu akan digagalkan lebih awal. , dan tanpa konsekuensi seluruh situs)


Jadi, itu adalah penanggulangan yang akan saya terapkan di perpustakaan auth, setelah saya yakin bahwa itu suara dan tidak ada solusi yang lebih sederhana yang saya lewatkan. Faktanya adalah, ada begitu banyak cara halus untuk melakukan hal-hal yang salah dalam keamanan, dan saya tidak di atas membuat asumsi yang salah atau logika yang benar-benar cacat. Jadi tolong, setiap dan semua umpan balik, kritik dan peningkatan, seluk-beluk dll sangat dihargai.


1
Mungkin Anda dapat membuat kata sandi 'khusus' untuk setiap pengguna yang dapat digunakan jika dalam mode penguncian (dan mereka terhubung dari IP baru dll), kata sandi khusus tersebut cukup rumit sehingga tidak mungkin dilakukan dengan paksa?
Douglas Leeder

1
Itu bisa bekerja, tetapi hanya jika pengguna mengingat kata sandi tersebut bahkan jika mereka belum pernah menggunakannya sebelumnya (jenis serangan ini tidak biasa, dan tidak ada botmaster yang sepadan dengan garamnya yang akan membuat susah payah menjalankannya lama setelah dicekik). Risikonya terlalu besar sehingga mereka tidak bisa mengingatnya.
Jens Roland

1
Namun, salah satu metode yang pasti bisa berfungsi, adalah menyediakan tautan 'kirim saya kode kuncian' kepada para pengguna tersebut, yang memungkinkan mereka untuk mendapatkan email berisi penggunaan tunggal, token khusus pengguna yang akan memungkinkan mereka untuk masuk, melewati pelambatan.
Jens Roland

1
@ Abtin: Ide bagus, kecuali itu akan 'memasuki perlombaan senjata' - yaitu. memulai 'siapa yang bisa mengakali siapa' dengan orang-orang yang membuat daftar kata sandi untuk serangan kamus. Saya pikir cara yang lebih baik akan menegakkan kebijakan password yang kuat sehingga tidak yang ada password yang lemah
Jens Roland

1
@OrestisP .: Anda kehilangan titik serangan terdistribusi - # upaya yang tidak valid dari setiap IP minimal, sehingga pemblokiran per-IP tidak dapat berfungsi. Selain itu, pertanyaan tersebut secara spesifik menggambarkan serangan brute force otomatis, jadi 1) penyerang bukan manusia, melainkan botnet mesin zombie (yang tidak bisa menggunakan captcha login); dan 2) sifat serangan brute force memerlukan jumlah upaya login yang sangat tinggi untuk memastikan keberhasilan, yang berarti mengolah captcha yang keluar ke toko keringat di suatu tempat tidak layak (walaupun mungkin jika penyerang didanai dan ditentukan dengan baik. cukup).
Jens Roland

17

Beberapa langkah sederhana:

Blacklist nama pengguna umum tertentu, dan gunakan sebagai honeypot. Admin, tamu, dll ... Jangan biarkan siapa pun membuat akun dengan nama-nama ini, jadi jika seseorang mencoba untuk masuk, Anda tahu seseorang melakukan sesuatu yang seharusnya tidak mereka lakukan.

Pastikan siapa pun yang memiliki kekuatan nyata di situs memiliki kata sandi yang aman. Memerlukan admin / moderator untuk memiliki kata sandi yang lebih panjang dengan campuran huruf, angka, dan simbol. Tolak kata sandi sederhana yang sepele dari pengguna biasa dengan penjelasan.

Salah satu hal paling sederhana yang dapat Anda lakukan adalah memberi tahu orang-orang ketika seseorang mencoba masuk ke akun mereka, dan memberi mereka tautan untuk melaporkan kejadian itu jika bukan mereka. Sebuah pesan sederhana ketika mereka masuk seperti "Seseorang mencoba masuk ke akun Anda pada pukul 4:20 Rabu bla bla. Klik di sini jika ini bukan Anda." Ini memungkinkan Anda menyimpan beberapa statistik tentang serangan. Anda dapat meningkatkan pemantauan dan langkah-langkah keamanan jika Anda melihat ada peningkatan tiba-tiba dalam akses penipuan.


Pikiran yang bagus. Saya pasti berencana untuk menerapkan kebijakan kata sandi otomatis yang bervariasi secara dinamis dengan tingkat hak istimewa pengguna. Ide honeypot mungkin bekerja untuk beberapa jenis serangan, tetapi jika serangan itu didistribusikan, memblokir IP yang jatuh untuk itu tidak akan efektif.
Jens Roland

Sehubungan dengan 'Waktu masuk terakhir yang dicoba', itu adalah strategi yang baik untuk pengguna listrik (yang saya bertaruh adalah mengapa SO melakukannya), tetapi ia memiliki dua kelemahan: (a) tidak mengatasi masalah intrusi, itu hanya melaporkan bahwa hal itu mungkin terjadi, dan (b), sebagian besar pengguna hanya tidak ingat / tidak peduli
Jens Roland

1
Ya, honeypot dan pelaporan pengguna lebih tentang pengumpulan informasi. Mereka mungkin memberikan beberapa metrik yang berharga untuk memberi tahu Anda jika / ketika serangan brute force lambat terjadi.
Patros

2
Untuk honeypot, tidak akan memperlakukan setiap nama pengguna tidak ada yang be mencurigakan lebih baik daripada hanya menggunakan daftar tetap nama pengguna yang dikenal-buruk? Anda ingin menghindari mengunci pengguna yang salah mengetik nama pengguna mereka dan tidak melihat kesalahan ketik saat mencoba ulang kata sandi mereka beberapa kali, tapi saya masih berpikir ada cara-cara itu bisa berharga. Anda bahkan dapat menghindari beberapa "false positive" dengan membangun filter bloom besar atau struktur data serupa dengan varian nama pengguna yang valid, nama depan, nama belakang, nama email, dll. Saat pengguna ditambahkan.
R .. GitHub BERHENTI MEMBANTU ICE

11

Jika saya memahami MO serangan brute force dengan benar, maka satu atau lebih nama pengguna dicoba terus menerus.

Ada dua saran yang menurut saya belum pernah saya lihat di sini:

  • Saya selalu berpikir bahwa praktik standar adalah untuk memiliki penundaan pendek (sekitar satu detik) setelah setiap login yang salah untuk setiap pengguna. Ini menghalangi kekuatan kasar, tapi saya tidak tahu berapa lama penundaan satu detik akan membuat serangan kamus di teluk. (kamus 10.000 kata == 10.000 detik == sekitar 3 jam. Hmm. Tidak cukup bagus.)
  • alih-alih melambat di seluruh situs, mengapa bukan throttle nama pengguna. Throttle menjadi semakin keras dengan setiap upaya yang salah (hingga batasnya, saya kira sehingga pengguna yang sebenarnya masih bisa masuk)

Sunting : Menanggapi komentar pada throttle nama pengguna: ini adalah throttle khusus nama pengguna tanpa memperhatikan sumber serangan.

Jika nama pengguna dicekik, maka bahkan serangan nama pengguna terkoordinasi (multi IP, tebakan tunggal per IP, nama pengguna yang sama) akan ditangkap. Nama pengguna individu dilindungi oleh throttle, bahkan jika penyerang bebas untuk mencoba pengguna lain / lulus selama waktu habis.

Dari sudut pandang penyerang, selama waktu habis Anda mungkin dapat menebak pertama kali pada 100 kata sandi, dan dengan cepat menemukan satu kata sandi yang salah per akun. Anda hanya dapat membuat tebakan 50 detik untuk periode waktu yang sama.

Dari sudut pandang akun pengguna, masih dibutuhkan jumlah rata-rata tebakan yang sama untuk memecahkan kata sandi, bahkan jika tebakan tersebut berasal dari berbagai sumber.

Untuk penyerang, paling-paling, ini akan merupakan upaya yang sama untuk memecahkan 100 akun seperti halnya 1 akun, tetapi karena Anda tidak melakukan pelambatan pada basis situs yang luas, Anda dapat meningkatkan throttle dengan cukup cepat.

Perbaikan ekstra:

  • mendeteksi IP yang menebak beberapa akun - 408 Batas Waktu Permintaan
  • mendeteksi IP yang menebak akun yang sama - 408 Batas Waktu Permintaan setelah sejumlah besar (katakanlah 100) tebakan.

Gagasan UI (mungkin tidak cocok dalam konteks ini), yang juga dapat memperbaiki hal di atas:

  • jika Anda mengendalikan pengaturan kata sandi, kemudian menunjukkan kepada pengguna seberapa kuat kata sandi mereka mendorong mereka untuk memilih yang lebih baik.
  • jika Anda mengendalikan halaman login , setelah sejumlah kecil (katakanlah 10) tebakan satu nama pengguna, tawarkan CAPTCHA.

Throttle nama pengguna plus throttle IP baik-baik saja terhadap serangan fixed-username atau fixed-IP, dan mereka membuat serangan kamus tradisional tidak layak. Tetapi jika penyerang terus-menerus mengubah nama pengguna, ia akan lewat tanpa memicu throttle nama pengguna. Itulah yang ingin saya lawan
Jens Roland

2
Terima kasih atas hasil editnya, jamesh. Sekarang kita bicara. Saya suka gagasan 408. Namun, bahkan dengan pembatasan nama pengguna yang ketat, botnet yang menyerang banyak pengguna masih akan berfungsi. Dan memeriksa 5.000 kata sandi teratas terhadap satu pengguna KURANG cenderung berhasil daripada memeriksa THE 1 kata sandi teratas pada 5000 pengguna
Jens Roland

Tidak seperti paradoks ulang tahun. Dalam grup besar, banyak yang akan menggunakan kata sandi tidak aman, dan satu kemungkinan akan menggunakan kata sandi yang populer. Akan ada banyak orang seperti saya yang tidak akan ditangkap oleh serangan seperti itu.
David Thornley

2
Sebenarnya, saya mungkin harus memeriksa ulang matematika pada pernyataan saya sebelumnya. Setelah Anda mengesampingkan N teratas kata sandi yang paling umum, kemungkinan pengguna memiliki kata sandi # (N + 1) dapat meningkat cukup untuk meratakan perbedaannya. Meskipun kurva mungkin cukup curam untuk itu tidak terjadi
Jens Roland

9

Ada tiga faktor otentikasi:

  1. Seorang pengguna mengetahui sesuatu (yaitu, kata sandi)
  2. Seorang pengguna memiliki sesuatu (mis. Key fob)
  3. Seorang pengguna adalah sesuatu (yaitu, pemindaian retina)

Biasanya, situs web hanya memberlakukan kebijakan # 1. Bahkan sebagian besar bank hanya memberlakukan kebijakan 1. Mereka malah mengandalkan pendekatan "tahu sesuatu yang lain" untuk otentikasi dua faktor. (IE: Seorang pengguna mengetahui kata sandi dan nama gadis ibu mereka.) Jika Anda bisa, cara untuk menambahkan faktor kedua otentikasi tidak terlalu sulit.

Jika Anda bisa menghasilkan sekitar 256 karakter acak, Anda bisa menyusunnya dalam tabel 16 × 16, dan kemudian meminta pengguna untuk memberi Anda nilai dalam tabel sel A-14, misalnya. Ketika seorang pengguna mendaftar atau mengubah kata sandi mereka, berikan mereka meja dan minta mereka untuk mencetaknya dan menyimpannya.

Kesulitan dengan pendekatan itu adalah bahwa ketika pengguna lupa kata sandi mereka, seperti yang mereka mau, Anda tidak bisa hanya menawarkan standar "jawab pertanyaan ini dan masukkan kata sandi baru", karena itu juga rentan terhadap kekerasan. Selain itu, Anda tidak dapat mengatur ulang dan mengirimi mereka email baru, karena email mereka juga dapat dikompromikan. (Lihat: Makeuseof.com dan domain curian mereka.)

Gagasan lain (yang melibatkan anak kucing), adalah yang oleh BOA disebut SiteKey (saya yakin mereka merek dagang namanya). Secara singkat, Anda meminta pengguna mengunggah gambar ketika mereka mendaftar, dan ketika mereka mencoba masuk, minta mereka untuk memilih gambar mereka dari 8 atau 15 (atau lebih) yang acak. Jadi, jika pengguna mengunggah gambar anak kucingnya, secara teoritis hanya mereka yang tahu persis gambar mana yang mereka miliki dari semua anak kucing lainnya (atau bunga atau apa pun). Satu-satunya kerentanan nyata yang dimiliki oleh pendekatan ini adalah serangan man-in-the-middle.

Satu ide lagi (tidak ada anak kucing), adalah untuk melacak IP yang digunakan pengguna untuk mengakses sistem, dan mengharuskan mereka untuk melakukan otentikasi tambahan (captcha, pick a kitty, pick a key dari tabel ini) ketika mereka masuk dari alamat yang mereka pilih sebelumnya. Juga, mirip dengan GMail, memungkinkan pengguna untuk melihat dari mana mereka masuk baru-baru ini.

Edit, Ide Baru:

Cara lain untuk memvalidasi upaya login adalah untuk memeriksa apakah pengguna telah datang dari halaman login Anda atau tidak. Anda tidak dapat memeriksa rujukan, karena mereka dapat dengan mudah dipalsukan. Yang Anda butuhkan adalah mengatur kunci di _SESSION var ketika pengguna melihat halaman login, dan kemudian memeriksa untuk memastikan kunci itu ada ketika mereka mengirimkan informasi login mereka. Jika bot tidak mengirimkan dari halaman login, itu tidak akan bisa masuk. Anda juga dapat memfasilitasi ini dengan melibatkan javascript dalam proses, baik dengan menggunakannya untuk mengatur cookie, atau menambahkan beberapa informasi ke formulir setelah dimuat. Atau, Anda dapat membagi formulir menjadi dua kiriman yang berbeda (yaitu, pengguna memasukkan nama pengguna mereka, mengirimkan, lalu pada halaman baru memasukkan kata sandi mereka dan mengirimkan lagi.)

Kuncinya, dalam hal ini, adalah aspek yang paling penting. Metode umum untuk menghasilkan mereka adalah beberapa kombinasi data pengguna, IP mereka, dan waktu pengirimannya.


Saya yakin ada lebih dari itu, tetapi jika ide SiteKey persis seperti yang Anda sebutkan, penyerang tidak harus menjadi MITM, ia hanya dapat menjalankan dua atau tiga upaya login untuk pengguna itu, dan memilih gambar yang berulang di antara yang acak. Bahkan jika set 8-15 gambar statis untuk pengguna X,
Jens Roland

(lanjutan) mungkin tidak akan terlalu sulit untuk memilih yang benar, karena orang cenderung memilih jenis gambar yang dapat diprediksi (bahkan gambar dari album Flickr mereka sendiri!)
Jens Roland

2
Ya, saya memikirkan poin yang Anda kemukakan tadi malam setelah saya pulang. Saya pikir cara untuk memperbaikinya adalah: Ketika seorang pengguna masuk dan memberikan kata sandi yang benar, tampilkan gambar mereka dan sejumlah yang acak lainnya. Ketika mereka tidak memberikan password yang benar, menunjukkan beberapa jumlah acak
davethegr8

1
gambar + 1, yang mungkin atau mungkin tidak termasuk gambar mereka sendiri. Juga, saya punya ide lain, lihat edit di posting. Tapi ya, ide-ide ini agak sulit / rumit.
davethegr8

1
Itu "bisa" bekerja, tetapi saya melihat beberapa masalah. Apa yang terjadi jika pemilik foto menghapus gambar? Bagaimana Anda bisa yakin bahwa gambar yang dikembalikan tidak akan menyinggung pengguna Anda? Bagaimana cara pengguna mengingat di mana mereka mengklik? (Tampaknya sulit untuk melupakan)
davethegr8

7

Saya sebelumnya telah menjawab pertanyaan yang sangat mirip di Bagaimana saya dapat membatasi upaya login pengguna dalam PHP . Saya akan mengulangi solusi yang diusulkan di sini karena saya yakin banyak dari Anda akan menganggapnya sebagai informasi dan berguna untuk melihat beberapa kode aktual. Harap diingat bahwa menggunakan CAPTCHA mungkin bukan solusi terbaik karena algoritma yang semakin akurat yang digunakan dalam bust CAPTCHA saat ini:

Anda tidak bisa begitu saja mencegah serangan DoS dengan merantai throttling ke satu IP atau nama pengguna. Sial, Anda bahkan tidak dapat benar-benar mencegah upaya masuk dengan cepat menggunakan metode ini.

Mengapa? Karena serangan dapat menjangkau beberapa IP dan akun pengguna demi melewati upaya pelambatan Anda.

Saya telah melihat diposting di tempat lain bahwa idealnya Anda harus melacak semua upaya login gagal di situs dan mengaitkannya dengan timestamp, mungkin:

CREATE TABLE failed_logins(
    id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(16) NOT NULL,
    ip_address INT(11) UNSIGNED NOT NULL,
    attempted DATETIME NOT NULL
) engine=InnoDB charset=UTF8;

Tentukan penundaan tertentu berdasarkan jumlah keseluruhan gagal masuk dalam jumlah waktu tertentu. Anda harus mendasarkan ini pada data statistik yang diambil dari failed_loginstabel Anda karena akan berubah dari waktu ke waktu berdasarkan jumlah pengguna dan berapa banyak dari mereka yang dapat mengingat (dan mengetik) kata sandi mereka.


10 failed attempts = 1 second
20 failed attempts = 2 seconds
30 failed attempts = reCaptcha

Permintaan tabel pada setiap upaya login yang gagal untuk menemukan jumlah login gagal untuk periode waktu tertentu, katakanlah 15 menit:


SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute);

Jika jumlah upaya selama periode waktu yang diberikan melebihi batas Anda, baik berlaku pembatasan atau memaksa semua pengguna untuk menggunakan captcha (yaitu reCaptcha) hingga jumlah upaya gagal selama periode waktu yang diberikan kurang dari ambang batas.

// array of throttling
$throttle = array(10 => 1, 20 => 2, 30 => 'recaptcha');

// assume query result of $sql is stored in $row
$sql = 'SELECT MAX(attempted) AS attempted FROM failed_logins';
$latest_attempt = (int) date('U', strtotime($row['attempted']));
// get the number of failed attempts
$sql = 'SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute)';
// assume the number of failed attempts was stored in $failed_attempts
krsort($throttle);
foreach ($throttle as $attempts => $delay) {
    if ($failed_attempts > $attempts) {
        // we need to throttle based on delay
        if (is_numeric($delay)) {
            $remaining_delay = time() - $latest_attempt - $delay;
            // output remaining delay
            echo 'You must wait ' . $remaining_delay . ' seconds before your next login attempt';
        } else {
            // code to display recaptcha on login form goes here
        }
        break;
    }
}

Menggunakan reCaptcha pada ambang tertentu akan memastikan bahwa serangan dari berbagai front akan diminimalkan dan pengguna situs normal tidak akan mengalami penundaan yang signifikan untuk upaya login gagal yang sah. Saya tidak bisa memastikan pencegahan, karena sudah diperluas bahwa CAPTCHA bisa rusak. Ada solusi alternatif, mungkin varian "Beri nama hewan ini", yang bisa berfungsi sebagai pengganti.


6

Saya harus bertanya apakah Anda sudah melakukan analisis biaya-manfaat dari masalah ini; sepertinya Anda mencoba melindungi diri dari penyerang yang memiliki cukup kehadiran web untuk menebak sejumlah kata sandi, mengirimkan mungkin 3-5 permintaan per IP (karena Anda telah menolak pembatasan IP). Berapa (kira-kira) biaya serangan seperti itu? Apakah lebih mahal daripada nilai akun yang Anda coba lindungi? Berapa banyak botnet raksasa yang ingin Anda dapatkan?

Jawabannya mungkin tidak - tetapi jika ya, saya harap Anda mendapatkan bantuan dari beberapa profesional keamanan; keterampilan pemrograman (dan skor StackOverflow) tidak berkorelasi kuat dengan pengetahuan keamanan.


(Anda bermaksud mengatakan jika jawabannya adalah 'tidak' - mis. Bahwa biaya serangan botnet TIDAK terlalu tinggi dalam kaitannya dengan akun)
Jens Roland

Tapi bagaimanapun, Anda memunculkan poin penting. Untuk kegunaan saya sendiri, saya tidak berharap ada operator botnet yang peduli, tapi saya merilis kode sumber untuk siapa saja yang menginginkan keamanan yang layak untuk aplikasi web mereka, dan saya tidak tahu apa yang mungkin orang lain coba untuk lakukan. melindungi, atau siapa musuh mereka
Jens Roland

Tidak akan menjaga rahasia nasional tidak peduli apa (sistem resmi memerlukan sertifikasi khusus, dan saya cukup yakin tidak ada yang dibangun pada PHP yang memenuhi syarat), tetapi semua aplikasi web memerlukan auth aman, jadi jika saya merilis ini, itu ' d menjadi sangat tidak bertanggung jawab untuk tidak menggunakan praktik terbaik di mana pun saya bisa
Jens Roland

1
Jadi jawaban singkat saya adalah: Saya membangun ini karena 99,9% situs web dan aplikasi di luar sana memiliki keamanan yang mengerikan (bahkan di liga besar: AOL, Twitter, Myspace semuanya telah dikompromikan sebelumnya), dan dalam banyak kasus karena mereka menggunakan perpustakaan autentik buruk.
Jens Roland

Baca juga makalah "To Catch A Predator" oleh Niels Provos et al. dari proses USENIX 2008 (tautan: usenix.org/events/sec08/tech/small.html ) Ini adalah pembuka mata: 2 bulan, satu honeypot: 368.000 serangan dari hampir 30.000 IP berbeda, yang berasal dari lebih dari 5.600 botnet!
Jens Roland

5

Untuk meringkas skema Jens 'menjadi diagram transisi keadaan semu / rulebase:

  1. pengguna + kata sandi -> entri
  2. kata sandi pengguna +! -> ditolak
  3. user + known_IP (user) -> pintu depan, // never throttle
  4. user + unknown_IP (user) -> catflap
  5. (#denied> n) via catflaps (situs) -> throttle catflaps (situs) // slow the bots
  6. catflap + throttle + kata sandi + captcha -> entri // humans still welcome
  7. catflap + throttle + kata sandi +! captcha -> ditolak // a correct guess from a bot

Pengamatan:

  • Jangan pernah melambatkan pintu depan. Polisi negara bagian Elbonian memiliki komputer Anda, di rumah Anda, tetapi tidak dapat menginterogasi Anda. Brute force adalah pendekatan yang layak dari komputer Anda.
  • Jika Anda memberikan "Lupa kata sandi Anda?" tautan, maka akun email Anda menjadi bagian dari permukaan serangan.

Pengamatan ini mencakup berbagai jenis serangan dengan yang Anda coba balas.


Tentu saja akun email adalah bagian dari permukaan serangan. Saya memiliki seperangkat asumsi batas atas tentang keamanan yang akan disediakan oleh strategi saya, dan batas terendah adalah keamanan email pengguna sendiri. Jika penyerang melanggar email pengguna, semua taruhan dimatikan.
Jens Roland

Juga, saya pikir diagram transisi negara Anda memerlukan beberapa detail: # 3 dan # 4 harus menyertakan kata sandi; # 1 dan # 2 harus menyertakan known_IP (pengguna) karena login selalu memiliki IP yang dikenal atau tidak dikenal; dan # 6 adalah 'entri meskipun throttle'
Jens Roland

4

Sepertinya Anda mencoba bertahan melawan brute force yang didistribusikan lambat . Tidak banyak yang dapat Anda lakukan tentang itu. Kami menggunakan PKI dan tidak ada login kata sandi. Ini membantu, tetapi jika klien Anda kebetulan menggunakan workstation sesekali, ini tidak terlalu berlaku.


Sebenarnya brute force juga cepat. Saya berharap menjadi agak lunak dengan kekuatan pengguna tetap (pembatasan hanya 20 detik), tetapi di situs dengan pengguna 50k, itu akan membuat kekuatan variabel pengguna- cepat mungkin (dengan asumsi 20 + detik untuk berputar melalui pengguna). Dan bahwa, sebagaimana yang mereka katakan, akan menyedot ..
Jens Roland

Kekuatan brute yang cepat dari satu host menggunakan iptables atau firewall apa pun yang Anda gunakan.
Björn Raupach

Saya merujuk pada brute force yang didistribusikan. Jarang tetapi berpotensi sangat jahat
Jens Roland

3

Penafian: Saya bekerja untuk perusahaan dua faktor, tetapi saya tidak di sini untuk menghubungkannya. Ini beberapa pengamatan.

Cookie dapat dicuri dengan XSS dan browser browser. Pengguna umumnya mengubah browser atau menghapus cookie mereka.

Sumber alamat IP secara simultan variabel dinamis dan spoofable.

Captcha berguna, tetapi tidak mengotentikasi manusia tertentu.

Berbagai metode dapat digabungkan dengan sukses, tetapi selera yang baik pasti ada.

Kompleksitas kata sandi baik, semua kata sandi berbasis kritis tergantung pada kata sandi yang memiliki entropi yang memadai. IMHO, kata sandi yang kuat yang ditulis di lokasi fisik yang aman lebih baik daripada kata sandi yang lemah di memori. Orang-orang tahu cara mengevaluasi keamanan dokumen kertas jauh lebih baik daripada mereka tahu cara mengetahui entropi efektif dalam nama anjing mereka ketika digunakan sebagai kata sandi untuk tiga situs web yang berbeda. Pertimbangkan untuk memberikan kepada pengguna kemampuan untuk mencetak halaman besar atau kecil yang penuh dengan kode akses sekali pakai.

Pertanyaan keamanan seperti "apa maskot sekolah menengah Anda" sebagian besar merupakan bentuk buruk dari "sesuatu yang Anda tahu", kebanyakan dari mereka mudah ditebak atau langsung di domain publik.

Seperti yang Anda catat, pembatasan kembali upaya login yang gagal adalah pertukaran antara mencegah serangan brute-force dan kemudahan DoSing akun. Kebijakan penguncian yang agresif dapat mencerminkan kurangnya kepercayaan pada entropi kata sandi.

Saya pribadi tidak melihat manfaat untuk menerapkan kedaluwarsa kata sandi di situs web. Penyerang mendapatkan kata sandi Anda sekali, ia dapat mengubahnya lalu mematuhi kebijakan itu semudah yang Anda bisa. Mungkin salah satu manfaatnya adalah bahwa pengguna dapat melihat lebih cepat jika penyerang mengubah kata sandi akun. Bahkan lebih baik jika pengguna entah bagaimana diberitahu sebelum penyerang mendapatkan akses. Pesan seperti "N gagal upaya sejak login terakhir" berguna dalam hal ini.

Keamanan terbaik berasal dari faktor kedua otentikasi yang out-of-band relatif terhadap yang pertama. Seperti yang Anda katakan, token perangkat keras dalam "sesuatu yang Anda miliki" sangat bagus, tetapi banyak (tidak semua) memiliki overhead admin nyata yang terkait dengan distribusi mereka. Saya tidak tahu solusi biometrik "sesuatu Anda" yang bagus untuk situs web. Beberapa solusi dua faktor bekerja dengan penyedia openid, beberapa memiliki SDK PHP / Perl / Python.


Semua poin luar biasa - Saya sangat setuju. Poin tentang ketidakamanan cookie sangat valid, tetapi tanpa faktor fisik kedua atau kata sandi satu kali (didistribusikan melalui jalur aman) Anda benar-benar tidak dapat melindungi terhadap titik akhir yang rentan. Jika kotak / browser pengguna terganggu, begitu juga login-nya.
Jens Roland

1

Rekomendasi tertinggi saya adalah memastikan bahwa Anda memberi informasi kepada pengguna tentang upaya masuk yang buruk ke akun mereka - Pengguna mungkin akan menganggap kekuatan kata sandi mereka jauh lebih serius jika mereka diberikan bukti bahwa seseorang benar-benar mencoba masuk ke akun mereka. .

Saya benar-benar menangkap seseorang yang meretas akun myspace saudara saya karena mereka mencoba masuk ke akun gmail yang saya buat untuknya dan menggunakan fitur 'setel ulang kata sandi saya dengan email' ... yang masuk ke kotak masuk saya.


1
  1. Bagaimana dengan meminta kata sandi satu kali sebelum memasukkan kata sandi normal mereka? Itu akan membuatnya sangat jelas bahwa seseorang sedang menyerang sebelum mereka mendapat banyak kesempatan untuk menebak kata sandi utama?

  2. Pertahankan hitungan global / tingkat kegagalan login - ini adalah indikator untuk serangan - selama serangan menjadi lebih ketat tentang kegagalan login misalnya larangan IP lebih cepat.


1) Bagaimana Anda menerapkan kata sandi satu kali pada saluran yang tidak aman dan tidak terauthentikasi? Dengan kata lain, kapan pengguna menetapkan kata sandi satu kali ini? 2) Ya, itulah inti # 4 dalam daftar saya, batas seluruh situs pada upaya yang gagal. Downside adalah peluang DoS yang dibuka.
Jens Roland

0

Saya tidak percaya ada jawaban yang sempurna tetapi saya akan cenderung mendekatinya atas dasar mencoba mengacaukan robot jika ada serangan.

Di luar pikiran saya:

Beralih ke layar login alternatif. Ini memiliki beberapa nama pengguna dan kata sandi kosong yang benar-benar muncul tetapi hanya satu dari mereka yang berada di tempat yang tepat. Nama bidangnya RANDOM --sebuah kunci sesi dikirimkan bersama dengan layar masuk, server kemudian dapat mengetahui bidang apa itu apa. Berhasil atau gagal itu kemudian dibuang sehingga Anda tidak dapat mencoba serangan replay - jika Anda menolak kata sandi mereka mendapatkan ID sesi baru.

Setiap bentuk yang dikirimkan dengan data di bidang yang salah diasumsikan berasal dari robot - login gagal, titik, dan IP dibatasi. Pastikan nama bidang acak tidak pernah cocok dengan nama bidang yang sah sehingga seseorang yang menggunakan sesuatu yang mengingat kata sandi tidak menyesatkan.

Selanjutnya, bagaimana dengan jenis captcha yang berbeda: Anda memiliki serangkaian pertanyaan yang tidak akan menimbulkan masalah bagi manusia. Namun, mereka TIDAK acak. Ketika serangan dimulai, semua orang diberikan pertanyaan # 1. Setelah satu jam pertanyaan # 1 dibuang, jangan pernah digunakan lagi dan semua orang mendapat pertanyaan # 2 dan seterusnya.

Penyerang tidak dapat menyelidiki untuk mengunduh database untuk dimasukkan ke dalam robotnya karena sifat pertanyaan yang dapat dibuang. Dia harus mengirim instruksi baru ke botnetnya dalam waktu satu jam untuk memiliki kemampuan untuk melakukan apa saja.


Layar login alternatif terdengar seperti itu akan membingungkan manusia lebih dari mesin, terus terang. Kami tentu saja berasumsi bahwa penyerang akan memeriksa langkah-langkah keamanan kami sebelumnya. Dia bisa dengan mudah men-tweak scraper-nya untuk menemukan bidang yang ditempatkan dengan benar.
Jens Roland

Pertanyaan pemeriksaan manusia telah dilakukan sebelumnya, dan itu tidak terlalu efektif. Bagi operator botnet manusia untuk menjawab satu pertanyaan per jam (setelah itu jawaban baru akan disebarkan ke bot) selama serangan akan sangat layak.
Jens Roland

Anda tidak mengerti intinya. Penyerang tidak dapat memeriksa terlebih dahulu karena hanya menunjukkan pertahanan tambahan ketika serangan muncul.
Loren Pechtel

Tentu, manusia dapat melihat apa pertanyaannya - tetapi ia harus mengomunikasikannya kepada semua botnya. Itu jalur komunikasi yang membuatnya lebih mudah untuk menjatuhkan botnet.
Loren Pechtel

Saya pikir saya tidak kehilangan intinya. Saya tidak bermaksud dia akan melakukan serangan sebelumnya untuk memeriksa langkah-langkah keamanan kami, maksud saya dia akan membaca utas ini dan memeriksa kode sumber (terbuka) untuk memeriksa weknesses :)
Jens Roland

0

Karena beberapa orang memasukkan CAPTCHA sebagai mekanisme manusia mundur, saya menambahkan pertanyaan StackOverflow sebelumnya dan utas tentang efektivitas CAPTCHA.

Apakah reCaptcha telah di-crack / diretas / OCR / dikalahkan / rusak?

Menggunakan CAPTCHA tidak membatasi peningkatan dari pembatasan Anda dan saran lainnya, tetapi saya pikir jumlah jawaban yang menyertakan CAPTCHA sebagai mundur harus mempertimbangkan metode berbasis manusia yang tersedia untuk orang-orang yang ingin merusak keamanan.


0

Anda juga dapat mencekik berdasarkan kekuatan kata sandi pengguna.

Ketika pengguna mendaftarkan atau mengubah kata sandi mereka, Anda menghitung peringkat kekuatan untuk kata sandi mereka, katakan antara 1 dan 10.

Sesuatu seperti "kata sandi" mendapat skor 1 sedangkan "c6eqapRepe7et * Awr @ ch" mungkin mencetak angka 9 atau 10 dan semakin tinggi skornya, semakin lama waktu yang diperlukan untuk pelambatan untuk memulai.


2
Saya mengerti idenya, tetapi itu secara tidak langsung akan membocorkan informasi tentang kata sandi, membiarkan penyerang tahu apakah kata sandi itu layak diretas atau tidak. Itu mungkin tampak sedikit teoretis, tetapi banyak pengguna menggunakan kembali kata sandi, jadi jika saya ingin membobol Strong_Throttling_Website.com saya cukup menyerang akun (diistimewakan) secara acak sampai saya menemukan pengguna, 'Freddy', yang memiliki kata sandi yang lemah (yaitu pelambatan awal), lalu buka Less_Secure_Website.edu dan lakukan serangan kamus mudah pada akun Freddy di sana. Ini sedikit terlibat, tetapi tentu saja bisa dilakukan dalam praktek.
Jens Roland

0

Jawaban pertama yang biasanya saya dengar ketika menanyakan pertanyaan ini adalah mengubah port, tapi lupakan itu dan cukup nonaktifkan IPv4. Jika Anda hanya mengizinkan klien dari jaringan IPv6 Anda tidak lagi berdoa untuk pemindaian jaringan sederhana dan penyerang akan menggunakan pencarian DNS. Jangan berjalan di alamat yang sama dengan Apache (AAAA) / Sendmail (MX-> AAAA) Anda / apa yang telah Anda berikan kepada semua orang (AAAA). Pastikan zona Anda tidak dapat xferd, tunggu Anda mengizinkan zona Anda diunduh oleh siapa saja?

Jika bot menemukan server Anda membuat nama host baru, cukup tambahkan beberapa omong kosong ke nama host Anda, dan ubah alamat Anda. Biarkan nama lama dan bahkan setup ** nama honeypot untuk bot net habis.

** Uji catatan balik Anda (PTR) (di bawah ip6.arpa.) Untuk melihat apakah mereka dapat digunakan untuk membidik pada / 4 yang memiliki catatan VS / 4 yang tidak. IE Biasanya ip6.arpa akan memiliki ~ 32 "." Di alamat tetapi mencoba dengan beberapa yang terakhir hilang mungkin menghindari blok jaringan yang memiliki catatan VS yang lain yang tidak. Jika Anda mengambil lebih jauh, menjadi mungkin untuk melewatkan sebagian besar ruang alamat.

Dalam kasus terburuk, pengguna harus mengatur terowongan IPv6, tidak seperti mereka harus pergi sejauh VPN ke DMZ ... Meskipun orang bertanya-tanya mengapa itu bukan pilihan pertama.

Kerberos juga keren, tetapi IMHO LDAP berhembus (Apa yang secara teknis salah dengan NISPlus? Saya telah membaca bahwa Sun memutuskan bahwa pengguna menginginkan LDAP dan karena itu mereka menjatuhkan NIS +). Kerberos berfungsi dengan baik tanpa LDAP atau NIS, hanya perlu mengelola pengguna berdasarkan host dengan host. Menggunakan Kerberos memberi Anda PKI yang mudah digunakan, jika tidak otomatis.


0

Agak terlambat di sini, tetapi saya berpikir, dengan asumsi hard case - penyerang menggunakan banyak IP acak, nama pengguna acak dan kata sandi acak dipilih dari katakanlah daftar 10.000 paling populer.

Satu hal yang dapat Anda lakukan, terutama jika sistem tampaknya sedang diserang karena ada banyak upaya kata sandi yang salah pada sistem dan terutama jika kata sandi dengan entropi rendah adalah mengajukan pertanyaan sekunder seperti apa nama depan orang tua Anda, misalnya . Jika seorang penyerang mencapai satu juta akun yang mencoba kata sandi 'kata sandi1' ada peluang bagus mereka akan mendapatkan banyak tetapi peluang mereka untuk mendapatkan nama yang benar akan mengurangi keberhasilan secara dramatis.

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.