Salah satu masalah yang muncul di depan sumber daya WEB yang memiliki akun pribadi adalah serangan brute force. Ya, penghitungan sederhana semua opsi kata sandi untuk akun tertentu. Bodoh? Mungkin, tetapi serangan semacam itu bisa sangat memuat sumber daya. Selain itu, jika tidak ada kontrol atas kompleksitas kata sandi pengguna selama pendaftaran, itu mungkin juga berhasil.
Paling sering, masalah diselesaikan relatif sederhana. Jika pengguna salah memasukkan kata sandi beberapa kali, akunnya diblokir untuk beberapa waktu. Solusi alternatif adalah menampilkan captcha. Segera, atau setelah beberapa upaya gagal. Yah, jangan lupa tentang otorisasi 2F, yang hampir kebal. Tampaknya - untung! Tapi, tidak semuanya begitu cerah ...
Mari kita lihat beberapa solusi pemecahan masalah:
Pemblokiran sementara - akun pengguna diblokir sementara dan ia tidak bisa masuk ke sistem. Pengguna sebenarnya selama serangan mengalami sakit hati dan siksaan. Dia tidak bisa masuk ke sistem. Dan kemungkinan besar itu memuat dukungan Anda. Dan hal yang paling menarik adalah mungkin inilah tujuan penyerang.
Captcha adalah solusi yang relatif baik dan efektif. Yang sebenarnya tidak nyaman bagi pengguna, mengharuskan Anda untuk memasukkan sesuatu di sana juga. Cukup "tidak menyenangkan" untuk disematkan dalam desain. Oh ya ... tetap saja hal ini, tergantung pada implementasinya, dapat dikenakan serangan DoS.
Otorisasi 2F - Semuanya bagus. Benar ... paling sering ini adalah hal opsional. Aktifkan untuk melawan serangan itu tidak akan berhasil. Dia ada di sana atau tidak. Dan pada beberapa sumber, masukkan otorisasi 2F, katakanlah, tembak burung pipit dari tangki.
Saya mencoba menciptakan layanan yang nyaman dan andal. Oleh karena itu, saya memutuskan untuk sedikit menegang otak saya. Dan itulah yang terjadi.
Jika Anda menggunakan email, misalnya mail.ru, dan Anda telah menginstal otorisasi 2F, Anda mungkin telah memperhatikan bahwa otorisasi 2F hanya diminta untuk "perangkat" baru pada login pertama. Selanjutnya, perangkat ini dianggap tepercaya. Dan Anda hanya perlu memasukkan login dan kata sandi Anda.
Hal yang nyaman. Ramah pengguna, jadi untuk berbicara. Ini diterapkan oleh dua token. Pengidentifikasi pertama adalah "perangkat" (didefinisikan sebagai devid), dan yang kedua adalah pengidentifikasi sesi (didefinisikan sebagai sesi). Devid, tidak seperti sesi, tidak kehilangan relevansinya bahkan setelah pengguna mengakhiri sesi. Ini dikirimkan pada upaya login berikutnya, dan jika nama pengguna / kata sandi benar, serta dipercaya tepercaya, 2F tidak lagi diminta. Tetapi, jika upaya login berikutnya tidak berhasil, token yang dibagi segera mati. Dan sekarang Anda harus menempuh jalur otorisasi penuh.
Paradigma ini diambil sebagai dasar. Yaitu masukkan devid token, yang akan dikeluarkan terus-menerus, dengan respons apa pun dari sumber WEB, tentu saja, jika tidak ada dalam permintaan.
Untuk kasus otorisasi 2F, algoritma di atas sebenarnya diterapkan. Dan segera semua orang menjadi bahagia. T.ch. tidak masuk akal untuk memeriksanya secara rinci. Tapi "lonceng dan peluit", lebih baik untuk mempertimbangkan diagram, dengan penjelasan:
Bahkan jika otorisasi 2F tidak diinstal, tetapi login berhasil, maka token devidenya ditandai sebagai tepercaya. Tampaknya tidak masuk akal untuk melakukan ini tanpa otorisasi 2F. Tapi, semuanya agak rumit. Jika kita tahu bahwa devid tepercaya, mis. ia berhasil masuk, setidaknya kami berasumsi bahwa dari perangkat inilah pengguna yang sebenarnya datang. Ini adalah informasi yang sangat penting yang digunakan algoritma yang dijelaskan dalam kerjanya dalam mode refleksi serangan.
Sebuah strategi telah diadopsi: otorisasi apa pun dapat terjadi hanya jika ada token yang sah. Devid yang valid berbeda dari yang tepercaya karena belum dipercaya, mis. tidak ada login yang berhasil dari itu, tetapi sistem siap untuk memproses permintaan otorisasi dengannya. Jumlah upaya dibatasi hingga N kali per token yang valid. Jika kesalahan otorisasi terjadi lebih dari N kali berturut-turut, token ditandai sebagai "dikompromikan". Itu ditransfer ke jurnal terpisah dengan statistik pada seleksi. Permintaan dengan partisipasinya terus diproses, tetapi ... tidak mungkin lagi untuk masuk dengannya. Semua yang terjadi adalah akumulasi statistik aktivitas.
Jadi serangan paling bodoh melawan balik. Misalnya, jika seorang penyerang, mengabaikan devid, mencoba masuk ke sistem, atau jika ia tidak dapat memahami logika devid (bagaimana ia tahu berapa banyak upaya login yang diberikan dengan devid yang sama?), Permintaannya dihentikan.
Front sendiri tahu bahwa setelah N kali gagal login mencoba dari satu devid, itu sudah "busuk". Sekarang Anda perlu mendapatkan token baru, sebelum upaya login berikutnya.
Tampaknya, kebodohan macam apa? Bagian depan untuk memenuhi upaya masuk ... tetapi, seperti yang saya katakan di atas, semuanya lebih rumit. Jika pengguna bekerja melalui front standar, kemungkinan dia benar-benar mencoba untuk menyerang sistem dapat diabaikan. Dipasangkan dengan sistem kontrol kompleksitas kata sandi selama pendaftaran pengguna, ini sama sekali sia-sia. Kemungkinan besar, pengguna sebenarnya benar-benar mencoba mengingat kata sandinya.
Jadi apa masalahnya? Pada kenyataannya bahwa di bagian belakang kami menghasilkan devid yang sangat valid dengan batas waktu tertentu. Misalnya, tidak lebih dari 1000 pcs per menit. Jika tiba-tiba batas ini terlampaui, mode serangan terpotong. Dan di sini Anda bisa pergi secara radikal dan menghentikan emisi devid untuk beberapa waktu, yang akan mendinginkan semangat penyerang, atau mengurangi generasi devid yang valid. Dan Anda dapat mengaktifkan captcha yang sama untuk semua devid yang valid, tetapi tidak terpercaya.
Dengan demikian, sistem yang fleksibel untuk mengendalikan dan mengelola serangan diperoleh. Metrik yang andal dihasilkan oleh pemantauan yang dapat memicu peningkatan alarm. Akumulasi statistik dapat dikonversi menjadi aturan pemblokiran, dll.
Sistem yang ramah adalah karena para pengguna yang sebelumnya masuk ke dalamnya, yaitu telah mempercayai devid bahkan tidak memperhatikan serangan itu. Mereka akan dilewati oleh sistem tanpa masalah.
Sekarang untung. Algoritma ini sangat mapan pada sumber daya dengan beban yang sangat tinggi. Ada, antara lain, upaya DoS pada algoritma itu sendiri, tetapi bahkan di sini terbukti layak.