Apa penanggulangan Brute Force Terdistribusi terbaik?

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 ;-)

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.

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.

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.

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 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.

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.

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.

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.

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.

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. 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.

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.

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.

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.

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.

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.