Otentikasi dua faktor
Semua yang Anda baca di bagian pertama terkait dengan identifikasi berdasarkan apa yang diketahui pemohon . Dia mengetahui alamat emailnya, tahu cara mengaksesnya (yaitu mengetahui kata sandi emailnya), dan mengetahui jawaban atas pertanyaan keamanan.
"Pengetahuan" dihitung sebagai satu faktor otentikasi; dua faktor umum lainnya adalah apa yang Anda miliki , seperti perangkat fisik, dan siapa Anda , seperti sidik jari atau retina.
Dalam kebanyakan kasus, melakukan identifikasi biologis hampir tidak mungkin dilakukan, terutama ketika kita berbicara tentang keamanan aplikasi web, jadi otentikasi dua faktor (2FA) biasanya menggunakan atribut kedua - "apa yang Anda miliki". Satu variasi populer pada faktor kedua ini adalah token fisik seperti RSA SecurID :
Token fisik sering digunakan untuk otentikasi di VPN perusahaan dan layanan keuangan. Untuk otentikasi dalam layanan, Anda perlu menggunakan kata sandi dan kode pada token (yang sering berubah) bersama PIN. Secara teori, untuk identifikasi, penyerang harus mengetahui sandi, memiliki token, dan juga mengetahui PIN token tersebut. Dalam skenario pengaturan ulang kata sandi, kata sandi itu sendiri jelas tidak dikenal, tetapi kepemilikan token dapat digunakan untuk mengonfirmasi kepemilikan akun. Tentu saja, seperti halnya penerapan keamanan lainnya, ini tidak memberikan "perlindungan yang sangat mudah" , tetapi pasti meningkatkan penghalang untuk masuk.
Salah satu masalah utama dari pendekatan ini adalah biaya dan logistik pelaksanaannya; kita berbicara tentang menyerahkan perangkat fisik kepada setiap klien dan mengajari mereka proses baru. Selain itu, pengguna harus membawa perangkat, yang tidak selalu terjadi dengan token fisik. Pilihan lain adalah dengan menerapkan faktor kedua dari otentikasi menggunakan SMS, yang dalam kasus 2FA dapat berfungsi sebagai konfirmasi bahwa orang yang melakukan proses reset memiliki ponsel pemilik akun. Beginilah cara Google melakukannya:
Anda juga perlu mengaktifkan Verifikasi 2 Langkah , tetapi ini berarti saat Anda menyetel ulang sandi di lain waktu, ponsel Anda dapat menjadi faktor kedua untuk otentikasi. Izinkan saya menunjukkan ini dengan iPhone saya untuk alasan yang akan segera menjadi jelas:
Setelah mengidentifikasi alamat email akun, Google menentukan bahwa 2FA telah diaktifkan dan kami dapat mengatur ulang akun menggunakan verifikasi, yang dikirim melalui SMS ke ponsel pemegang akun:
Sekarang kita perlu memilih awal proses reset:
Tindakan ini menghasilkan email yang dikirim ke alamat terdaftar:
Email ini berisi URL reset:
Saat mengakses URL reset, SMS dikirim dan situs web memintanya untuk memasukkan:
Ini SMSnya:
Setelah memasukkannya ke browser, kami kembali ke wilayah pengaturan ulang kata sandi klasik:
Ini mungkin terdengar agak bertele-tele, dan memang demikian, tetapi formulir tersebut menegaskan bahwa orang yang melakukan pengaturan ulang memiliki akses ke alamat email dan ponsel pemegang akun. Tapi ini bisa sembilan kali lebih aman daripada mengatur ulang kata sandi Anda melalui email saja. Namun, ada masalah ...
Masalahnya ada pada ponsel cerdas. Perangkat yang ditunjukkan di bawah ini hanya dapat mengautentikasi satu faktor otentikasi - perangkat dapat menerima SMS tetapi tidak dapat menerima email:
Namun, perangkat ini dapat menerima SMS dan menerima email pengaturan ulang kata sandi:
Masalahnya adalah kami menganggap email sebagai faktor pertama otentikasi, dan SMS (atau bahkan aplikasi penghasil token) sebagai yang kedua, tetapi saat ini keduanya digabungkan dalam satu perangkat. Tentu saja, ini berarti bahwa jika seseorang mengakses ponsel cerdas Anda, semua kemudahan ini akan bermuara pada fakta bahwa kita kembali ke saluran yang sama; faktor kedua ini, “apa yang Anda miliki” berarti bahwa Anda juga memiliki faktor pertama. Dan semua ini dilindungi oleh satu PIN yang terdiri dari empat digit ... jika telepon memiliki PIN sama sekali dan itu diblokir.
Ya, fitur 2FA Google memang memberikan perlindungan tambahan, tetapi ini tidak selalu mudah, dan tentu saja tidak bergantung pada dua saluran yang sepenuhnya otonom.
Setel ulang dengan nama pengguna vs setel ulang melalui email
Haruskah saya hanya mengizinkan reset ke alamat email? Atau haruskah pengguna dapat menyetel ulang nama juga? Masalah dengan menyetel ulang menggunakan nama pengguna adalah tidak ada cara untuk memberi tahu pengguna tentang nama pengguna yang salah tanpa mengungkapkan bahwa orang lain mungkin memiliki akun dengan nama pengguna tersebut. Di bagian sebelumnya, mengatur ulang melalui email memastikan bahwa pemilik yang sah dari email itu akan selalu menerima umpan balik tanpa mengungkapkan keberadaannya secara publik di sistem. Ini tidak dapat dilakukan hanya dengan menggunakan nama pengguna.
Jadi jawabannya singkat: hanya email. Jika Anda mencoba menyetel ulang hanya dengan nama pengguna, akan ada kalanya pengguna bertanya-tanya apa yang terjadi.atau Anda akan mengungkapkan keberadaan akun. Ya, ini hanya nama pengguna, bukan alamat email, dan ya, siapa pun dapat memilih nama pengguna (tersedia) apa pun, tetapi masih ada kemungkinan besar Anda akan secara tidak langsung mengungkapkan pemilik akun karena kecenderungan pengguna untuk menggunakan kembali. nama.
Jadi apa yang terjadi jika seseorang lupa nama penggunanya? Jika kami menerima bahwa nama pengguna tidak langsung menjadi alamat email (dan ini sering terjadi), maka prosesnya mirip dengan bagaimana pengaturan ulang kata sandi dimulai - kami memasukkan alamat email, dan kemudian mengirim pesan ke alamat ini tanpa mengungkapkan keberadaannya. Satu-satunya perbedaan adalah bahwa kali ini pesan tersebut hanya berisi nama pengguna dan bukan URL pengaturan ulang kata sandi. Baik itu, atau email akan menyatakan bahwa tidak ada akun untuk alamat ini.
Verifikasi identitas dan akurasi alamat email
Aspek kunci dari pengaturan ulang kata sandi, dan bahkan mungkin aspek yang paling penting, adalah memverifikasi identitas orang yang mencoba melakukan pengaturan ulang. Apakah ini benar-benar pemilik sah akun tersebut, atau apakah seseorang mencoba meretasnya atau membuat pemiliknya tidak nyaman?
Jelas, email adalah cara paling nyaman dan paling umum untuk memverifikasi identitas Anda. Itu tidak terlindung dari kesalahan penanganan ("dari orang bodoh"), dan ada banyak kasus di mana kemampuan sederhana untuk menerima surat ke alamat pemilik akun tidak cukup jika diperlukan tingkat kepercayaan yang tinggi dalam identifikasi (itulah mengapa 2FA digunakan), tetapi hampir selalu menjadi titik awal proses reset.
Jika email akan berperan dalam memberikan kepercayaan, langkah pertama adalah memastikan alamat email benar. Jika seseorang salah dengan simbol, maka jelas reset tidak akan dimulai. Proses verifikasi email pada saat pendaftaran adalah cara yang dapat diandalkan untuk memverifikasi kebenaran alamat. Kita semua telah melihat ini dalam praktiknya: Anda mendaftar, mereka mengirimi Anda email dengan URL unik untuk diklik, yang mengonfirmasi bahwa Anda memang pemilik akun email itu. Kegagalan masuk sebelum menyelesaikan proses ini memastikan bahwa ada motivasi untuk memverifikasi alamat.
Seperti banyak aspek keamanan lainnya, model seperti itu mengurangi kegunaan sebagai imbalan untuk memberikan tingkat keamanan yang lebih tinggi dalam kaitannya dengan identitas pengguna. Ini mungkin dapat diterima untuk situs, pendaftaran yang sangat dihargai oleh pengguna dan dengan senang hati akan menambahkan tahap lain dari proses tersebut (layanan berbayar, perbankan, dll.), Tetapi hal-hal seperti itu dapat mengasingkan pengguna jika ia menganggap akun tersebut "dapat dibuang" dan digunakan. , misalnya, hanya sebagai sarana mengomentari postingan.
Mengidentifikasi siapa yang memulai proses reset
Jelas, ada alasan penggunaan yang tidak benar dari fungsi reset, dan penyerang dapat menggunakannya dengan berbagai cara. Salah satu trik sederhana yang dapat kita gunakan untuk membantu memverifikasi asal permintaan (trik ini biasanya berhasil) adalah menambahkan reset alamat IP pemohon ke email. Ini memberi penerima beberapa informasi untuk mengidentifikasi sumber permintaan.
Berikut adalah contoh dari fungsi reset yang saat ini saya tanamkan di ASafaWeb:
Tautan "cari tahu lebih lanjut" mengarahkan pengguna ke ip-adress.com , memberikan informasi seperti lokasi dan organisasi orang yang meminta penyetelan ulang:
Tentu saja, siapa pun yang ingin menyembunyikan identitas mereka memiliki banyak cara untuk mengaburkan alamat IP asli mereka, namun ini adalah cara mudah untuk menambahkan sebagian identitas pemohon, dan dalam banyak kasus ini akan memberi Anda gambaran yang baik tentang siapa yang akan melakukan permintaan pengaturan ulang kata sandi.
Ubah pemberitahuan melalui email
Posting ini dijiwai dengan satu topik - komunikasi; komunikasikan sebanyak mungkin kepada pemilik akun tentang apa yang terjadi pada setiap tahap proses, tanpa mengungkapkan apa pun yang dapat digunakan dengan maksud jahat. Hal yang sama berlaku ketika kata sandi benar-benar berubah - beri tahu pemiliknya!
Ada dua sumber alasan untuk mengubah kata sandi:
- Ubah kata sandi setelah login karena pengguna menginginkan kata sandi baru
- Menyetel ulang kata sandi tanpa masuk karena pengguna lupa
Meskipun posting ini terutama tentang pengaturan ulang, pemberitahuan pada awalnya mengurangi risiko seseorang mengubah kata sandi tanpa sepengetahuan pemilik yang sah. Bagaimana ini bisa terjadi? Skenario yang sangat umum adalah mendapatkan kata sandi pemilik yang sah (kata sandi yang digunakan kembali yang bocor dari sumber lain; kata sandi yang diperoleh dengan keylogging; kata sandi yang mudah ditebak, dll.), Setelah itu penyerang memutuskan untuk mengubahnya, sehingga memblokir pemiliknya. Tanpa pemberitahuan email, pemilik saat ini tidak akan mengetahui perubahan kata sandi.
Tentu saja, dalam kasus penyetelan ulang kata sandi, pemilik sudah harus memulai proses (atau melewati alat verifikasi identifikasi yang dijelaskan di atas), jadi perubahan tidak bolehmengejutkannya, namun konfirmasi email akan menjadi umpan balik positif dan verifikasi tambahan. Selain itu, memberikan konsistensi dengan skenario di atas.
Oh, dan kalau-kalau belum jelas - jangan kirim email kata sandi baru! Ini mungkin membuat beberapa orang tertawa, tetapi ini terjadi :
Log, log, log, dan log lainnya
Fungsi pengaturan ulang kata sandi menarik bagi penyusup: penyerang ingin mendapatkan akses ke akun orang lain, atau sekadar membuat tidak nyaman pemilik akun / sistem. Banyak dari praktik yang dijelaskan di atas dapat mengurangi kemungkinan penyalahgunaan, namun praktik tersebut tidak mencegahnya, dan tentunya tidak akan mencegah orang untuk mencoba menggunakan fitur tersebut dengan cara yang tidak disengaja.
Logging adalah praktik yang benar-benar tak ternilai untuk mengenali perilaku jahat, dan maksud saya logging yang sangat detail . Rekam upaya yang gagal untuk masuk, setel ulang kata sandi, ubah kata sandi (yaitu ketika pengguna sudah masuk) dan hampir semua hal yang dapat membantu Anda memahami apa yang terjadi; itu akan sangat berguna di masa depan. Rekam bahkan bagian terpisah di logproses, misalnya, fungsi reset yang baik harus mencakup memulai reset melalui situs web (menangkap permintaan dan login mencoba untuk mengatur ulang dengan nama pengguna atau email yang salah), mencatat kunjungan ke situs web dengan URL reset (termasuk upaya untuk menggunakan yang salah token), lalu catat keberhasilan atau kegagalan jawaban atas pertanyaan keamanan.
Ketika saya berbicara tentang logging, maksud saya tidak hanya merekam fakta memuat halaman, tetapi juga mengumpulkan informasi sebanyak mungkin jika tidak bersifat rahasia . Teman-teman, tolong jangan memasukkan kata sandi! Di log, Anda perlu mendaftarkan identitas pengguna yang sah (dia akan diberi otorisasi jika dia berubahkata sandi yang ada, atau mencoba menyetel ulang kata sandi orang lain setelah masuk), nama pengguna atau alamat email yang dicoba, ditambah token penyetelan ulang apa pun yang coba digunakan. Tapi ada baiknya juga mencatat aspek seperti alamat IP dan, jika memungkinkan, bahkan meminta header. Hal ini memungkinkan Anda untuk membuat ulang tidak hanya apa yang pengguna (atau penyerang) coba lakukan, tetapi juga siapa mereka.
Pendelegasian tanggung jawab kepada pemain lain
Jika menurut Anda ini adalah pekerjaan yang sangat berat, maka Anda tidak sendiri. Nyatanya, membangun sistem manajemen akun yang kuat bukanlah tugas yang mudah. Ini tidak terlalu berat secara teknis, hanya saja ia memiliki banyak fitur. Ini bukan hanya tentang mengatur ulang, ada seluruh proses pendaftaran, penyimpanan kata sandi yang aman, menangani beberapa upaya login yang salah, dll, dll. Sementara saya mempromosikan ide untuk menggunakan fungsionalitas out-of-the-box seperti penyedia keanggotaan ASP.NET , masih banyak yang harus dilakukan selain itu.
Ada banyak vendor pihak ketiga di luar sana saat ini yang dengan senang hati menghilangkan rasa sakitnya dan mengabstraksikan semuanya menjadi satu layanan terkelola. Layanan ini termasuk OpenID, OAuth, dan bahkan Facebook. Beberapa orangTidak ada batasan untuk mempercayai model ini (OpenID memang sangat sukses di Stack Overflow), namun yang lain melihatnya sebagai mimpi buruk .
Tanpa diragukan lagi, layanan seperti OpenID memecahkan banyak masalah pengembang, tetapi tidak diragukan lagi juga menambahkan yang baru. Apakah mereka memiliki peran untuk dimainkan? Ya, tapi jelas kami tidak melihat penggunaan besar-besaran dari penyedia layanan otentikasi. Bank, maskapai penerbangan, dan bahkan toko semuanya menerapkan mekanisme otentikasi mereka sendiri, dan jelas ada alasan yang sangat bagus untuk ini.
Debit berbahaya
Aspek penting dari masing-masing contoh di atas adalah bahwa kata sandi lama dianggap tidak berguna hanya setelah identitas pemilik akun diverifikasi . Ini penting karena jika akun dapat disetel ulang sebelum verifikasi identitas, itu akan membuka semua jenis aktivitas berbahaya.
Berikut ini contohnya: Seseorang menawar di situs lelang, dan menjelang akhir proses penawaran, mereka memblokir pesaing dengan memulai proses pengaturan ulang, sehingga menghapus mereka dari penawaran. Jelas, jika fungsi reset yang dirancang dengan buruk dapat disalahgunakan, ini dapat menyebabkan hasil negatif yang serius. Perlu dicatat bahwa memblokir akun melalui upaya login yang salah adalah situasi yang serupa, tetapi ini adalah topik untuk posting lain.
Seperti yang saya katakan di atas, memberi pengguna anonim kemampuan untuk mengatur ulang kata sandi akun apa pun hanya dengan mengetahui alamat emailnya adalah situasi yang siap pakai untuk serangan penolakan layanan. Ini mungkin bukan DoS yang sama, yang biasa kita bicarakan, tetapi tidak ada cara yang lebih cepat untuk memblokir akses ke akun Anda selain dengan fungsi pengaturan ulang kata sandi yang tidak dipikirkan dengan matang.
Tautan terlemah
Dari sudut pandang melindungi satu akun, semua yang tertulis di atas bagus, namun, Anda selalu perlu mengingat ekosistem di sekitar akun yang Anda lindungi. Izinkan saya memberi Anda contoh:
ASafaWeb dihosting oleh layanan luar biasa yang disediakan oleh AppHarbor. Proses pengaturan ulang akun hosting adalah sebagai berikut:
Tahap 1:
Tahap 2:
Tahap 3:
Tahap 4:
Setelah membaca semua informasi sebelumnya, sudah mudah untuk memahami aspek mana di dunia ideal yang akan kita terapkan sedikit berbeda. Apa yang ingin saya katakan di sini, bagaimanapun, adalah bahwa jika saya mempublikasikan situs seperti ASafaWeb di AppHarbor, dan kemudian muncul dengan beberapa pertanyaan dan jawaban keamanan yang bagus, menambahkan faktor otentikasi kedua, dan melakukan sisanya sesuai dengan aturan, maka itu tidak mengubah fakta bahwa tautan terlemah dalam keseluruhan proses adalah mampu menghancurkan semuanya. Jika seseorang berhasil mengautentikasi di AppHarbor menggunakan informasi saya, maka mereka dapat mengganti kata sandi untuk akun ASafaWeb mana pun dengan yang mereka butuhkan!
Intinya adalah bahwa ketahanan implementasi perlindungan harus dipertimbangkan secara holistik: perlu untuk mensimulasikan ancaman ke setiap titik masuk sistem, bahkan jika itu adalah proses yang dangkal, misalnya, memasuki sistem AppHarbor. Ini akan memberi saya gambaran yang baik tentang berapa banyak usaha yang harus saya lakukan dalam proses pengaturan ulang kata sandi ASafaWeb.
Menyatukan semuanya
Posting ini berisi banyak informasi, jadi saya ingin memusatkannya dalam garis besar visual yang sederhana:
Ingatlah untuk mencatat sedetail mungkin untuk masing-masing item ini. Itu dia, itu sederhana!
Hasil
Posting saya tampaknya komprehensif, tetapi ada banyak materi tambahan yang dapat saya sertakan di dalamnya, tetapi memutuskan untuk tidak mencantumkannya agar singkat: peran alamat email penyelamat, situasi di mana Anda kehilangan akses ke email yang terkait dengan akun tersebut (misalnya, Anda keluar dari pekerjaan Anda) dan seterusnya. Seperti yang saya katakan sebelumnya, fungsi reset tidak terlalu sulit, hanya ada banyak sudut pandang di atasnya.
Meskipun pengaturan ulang tidak terlalu sulit, namun sering kali salah diterapkan. Kami telah melihat beberapa contoh di atas di mana penerapan dapat menyebabkan masalah, dan ada lebih banyak kasus penggunaan di mana penyetelan ulang yang salah sebenarnya menyebabkan masalah. Baru-baru ini terungkap bahwapengaturan ulang kata sandi digunakan untuk mencuri bitcoin senilai $ 87.000 . Ini adalah hasil negatif yang serius!
Oleh karena itu, berhati-hatilah dengan fungsi reset Anda, simulasikan ancaman di berbagai titik, dan saat mendesain suatu fungsi, jangan melepas topi hitam Anda, karena kemungkinan besar orang lain akan memakainya!
Periklanan
VDSina menawarkan server murah untuk disewa dengan pembayaran harian, setiap server terhubung ke saluran Internet 500 Megabit dan dilindungi dari serangan DDoS secara gratis!
