Baru-baru ini saya mempunyai waktu untuk memikirkan kembali tentang cara kerja fitur pengaturan ulang kata sandi yang aman, pertama kali ketika saya sedang membangun fungsi ini , dan kemudian ketika dia membantu orang lain melakukan hal serupa. Dalam kasus kedua, saya ingin memberinya tautan ke sumber daya kanonik dengan semua detail tentang cara menerapkan fungsi reset dengan aman. Namun, masalahnya adalah tidak ada sumber daya seperti itu, setidaknya tidak ada sumber daya yang menjelaskan segala sesuatu yang menurut saya penting. Jadi saya memutuskan untuk menulisnya sendiri.
Soalnya, dunia lupa kata sandi sebenarnya cukup misterius. Ada banyak sudut pandang berbeda yang sepenuhnya dapat diterima dan banyak juga sudut pandang yang cukup berbahaya. Kemungkinannya adalah Anda telah menemui masing-masingnya berkali-kali sebagai pengguna akhir; jadi saya akan mencoba menggunakan contoh ini untuk menunjukkan siapa yang melakukannya dengan benar, siapa yang tidak, dan apa yang perlu Anda fokuskan agar fitur tersebut tepat di aplikasi Anda.
Penyimpanan kata sandi: hashing, enkripsi, dan teks biasa (terkesiap!).
Kita tidak bisa membahas apa yang harus dilakukan terhadap kata sandi yang terlupa sebelum kita membahas cara menyimpannya. Kata sandi disimpan dalam database dalam salah satu dari tiga jenis utama:
- Teks sederhana. Terdapat kolom password yang disimpan dalam bentuk teks biasa.
- Terenkripsi. Biasanya menggunakan enkripsi simetris (satu kunci digunakan untuk enkripsi dan dekripsi), dan kata sandi terenkripsi juga disimpan di kolom yang sama.
- Di-hash. Proses satu arah (kata sandi dapat di-hash, tetapi tidak dapat dihilangkan); kata sandi, Saya ingin berharap, diikuti dengan garam, dan masing-masing berada pada kolomnya sendiri.
Mari kita langsung ke pertanyaan paling sederhana: Jangan pernah menyimpan kata sandi dalam teks biasa! Tidak pernah. Satu kerentanan terhadap , satu pencadangan yang ceroboh, atau salah satu dari lusinan kesalahan sederhana lainnya - dan hanya itu, gameover, semua kata sandi Anda - yaitu, maaf, kata sandi semua klien Anda akan menjadi domain publik. Tentu saja, ini berarti kemungkinannya sangat besar dari semua akun mereka di sistem lain. Dan itu akan menjadi kesalahanmu.
Enkripsi lebih baik, namun memiliki kelemahan. Masalah dengan enkripsi adalah dekripsi; kita dapat mengambil sandi yang tampak gila ini dan mengubahnya kembali menjadi teks biasa, dan ketika itu terjadi, kita kembali ke situasi kata sandi yang dapat dibaca manusia. Bagaimana ini bisa terjadi? Sebuah kelemahan kecil masuk ke dalam kode yang mendekripsi kata sandi, membuatnya tersedia untuk umum - ini adalah salah satu caranya. Peretas mendapatkan akses ke mesin tempat data terenkripsi disimpan - ini adalah metode kedua. Cara lain, sekali lagi, adalah dengan mencuri cadangan database dan seseorang juga mendapatkan kunci enkripsi, yang seringkali disimpan dengan sangat tidak aman.
Dan ini membawa kita pada hashing. Ide dibalik hashing adalah bahwa hashing bersifat satu arah; satu-satunya cara untuk membandingkan kata sandi yang dimasukkan pengguna dengan versi hashnya adalah dengan melakukan hash pada masukan dan membandingkannya. Untuk mencegah serangan dari alat seperti tabel pelangi, kami menggarami prosesnya secara acak (baca my tentang penyimpanan kriptografi). Pada akhirnya, jika diterapkan dengan benar, kita dapat yakin bahwa kata sandi yang di-hash tidak akan pernah menjadi teks biasa lagi (saya akan membicarakan manfaat berbagai algoritma hashing di postingan lain).
Argumen singkat tentang hashing vs. enkripsi: satu-satunya alasan Anda perlu mengenkripsi daripada meng-hash kata sandi adalah ketika Anda perlu melihat kata sandi dalam teks biasa, dan kamu seharusnya tidak menginginkan ini, setidaknya dalam situasi situs web standar. Jika Anda membutuhkannya, kemungkinan besar Anda melakukan sesuatu yang salah!
Peringatan!
Di bawah teks postingan tersebut terdapat bagian tangkapan layar situs pornografi AlotPorn. Sudah dipangkas rapi sehingga tidak ada yang tidak bisa Anda lihat di pantai, tapi jika masih mungkin menimbulkan masalah, jangan gulir ke bawah.
Selalu setel ulang kata sandi Anda tak pernah jangan ingatkan dia
Pernahkah Anda diminta untuk membuat suatu fungsi pengingat kata sandi? Ambil langkah mundur dan pikirkan permintaan ini secara terbalik: mengapa “pengingat” ini diperlukan? Karena pengguna lupa kata sandinya. Apa yang sebenarnya ingin kita lakukan? Bantu dia login lagi.
Saya menyadari kata "pengingat" digunakan (sering) dalam arti sehari-hari, tapi apa yang sebenarnya kami coba lakukan adalah dengan aman membantu pengguna untuk online lagi. Karena kita memerlukan keamanan, ada dua alasan mengapa pengingat (yaitu mengirimkan kata sandi kepada pengguna) tidak tepat:
- Email adalah saluran yang tidak aman. Sama seperti kita tidak akan mengirim sesuatu yang sensitif melalui HTTP (kita akan menggunakan HTTPS), kita juga tidak boleh mengirim sesuatu yang sensitif melalui email karena lapisan transportnya tidak aman. Faktanya, hal ini jauh lebih buruk daripada sekadar mengirimkan informasi melalui protokol transport yang tidak aman, karena email sering kali disimpan di perangkat penyimpanan, dapat diakses oleh administrator sistem, diteruskan dan didistribusikan, dapat diakses oleh malware, dan sebagainya. Email yang tidak terenkripsi adalah saluran yang sangat tidak aman.
- Lagipula Anda seharusnya tidak memiliki akses ke kata sandi. Baca kembali bagian sebelumnya tentang penyimpanan - Anda harus memiliki hash kata sandi (dengan garam yang kuat), yang berarti Anda tidak dapat mengekstrak kata sandi dengan cara apa pun dan mengirimkannya melalui surat.
Izinkan saya menunjukkan masalahnya dengan sebuah contoh : Berikut ini adalah halaman login yang khas:
Jelas, masalah pertama adalah halaman login tidak dimuat melalui HTTPS, tetapi situs tersebut juga meminta Anda mengirimkan kata sandi (“Kirim Kata Sandi”). Ini mungkin merupakan contoh penggunaan istilah sehari-hari yang disebutkan di atas, jadi mari kita selangkah lebih jauh dan lihat apa yang terjadi:
Sayangnya, tampilannya tidak jauh lebih baik; dan email mengonfirmasi bahwa ada masalah:
Ini memberi tahu kita dua aspek penting dari usoutdoor.com:
- Situs ini tidak meng-hash kata sandi. Paling-paling, mereka dienkripsi, tetapi kemungkinan besar disimpan dalam teks biasa; Kami tidak melihat bukti sebaliknya.
- Situs ini mengirimkan kata sandi jangka panjang (kita dapat kembali dan menggunakannya lagi dan lagi) melalui saluran yang tidak aman.
Jika hal ini tidak terjadi, kita perlu memeriksa apakah proses reset dilakukan dengan cara yang aman. Langkah pertama yang harus dilakukan adalah memastikan bahwa pemohon mempunyai hak untuk melakukan reset. Dengan kata lain, sebelum itu kita memerlukan pemeriksaan identitas; mari kita lihat apa yang terjadi jika suatu identitas diverifikasi tanpa terlebih dahulu memverifikasi bahwa pemohon sebenarnya adalah pemilik akun.
Mencantumkan nama pengguna dan dampaknya terhadap anonimitas
Masalah ini paling baik diilustrasikan secara visual. Masalah:
Apakah kamu lihat? Perhatikan pesan “Tidak ada pengguna yang terdaftar dengan alamat email ini.” Masalah jelas muncul jika situs tersebut mengonfirmasi ketersediaan pengguna terdaftar dengan alamat email tersebut. Bingo - Anda baru saja menemukan fetish porno suami/bos/tetangga Anda!
Tentu saja, pornografi adalah contoh yang cukup ikonik mengenai pentingnya privasi, namun bahaya mengasosiasikan seseorang dengan situs web tertentu jauh lebih luas daripada situasi yang berpotensi canggung seperti dijelaskan di atas. Salah satu bahayanya adalah rekayasa sosial; Jika penyerang dapat mencocokkan seseorang dengan layanan tersebut, maka dia akan memiliki informasi yang dapat mulai dia gunakan. Misalnya, dia mungkin menghubungi seseorang yang menyamar sebagai perwakilan sebuah situs web dan meminta informasi tambahan dalam upaya untuk berkomitmen .
Praktik semacam ini juga meningkatkan bahaya “pencacahan nama pengguna”, yang memungkinkan seseorang memverifikasi keberadaan seluruh kumpulan nama pengguna atau alamat email di situs web hanya dengan melakukan kueri grup dan memeriksa tanggapannya. Apakah Anda memiliki daftar alamat email seluruh karyawan dan waktu beberapa menit untuk menulis naskah? Lalu Anda lihat apa masalahnya!
Apa alternatifnya? Faktanya, ini cukup sederhana, dan diterapkan dengan luar biasa :
Di sini Entropay sama sekali tidak mengungkapkan apa pun tentang keberadaan alamat email di sistemnya kepada seseorang yang tidak memiliki alamat ini... Jika kamu memiliki alamat ini dan tidak ada di sistem, maka Anda akan menerima email seperti ini:
Tentu saja, mungkin ada situasi yang dapat diterima di mana seseorang berpikiryang telah Anda daftarkan di situs web. tapi bukan ini masalahnya, atau saya melakukannya dari alamat email lain. Contoh yang ditunjukkan di atas menangani kedua situasi dengan baik. Tentunya jika alamatnya cocok, Anda akan menerima email yang memudahkan untuk mereset kata sandi Anda.
Kehalusan solusi yang dipilih oleh Entropay adalah verifikasi identifikasi dilakukan sesuai dengan e-mail sebelum verifikasi online apa pun. Beberapa situs menanyakan jawaban pertanyaan keamanan kepada pengguna (lebih lanjut tentang ini di bawah) untuk bagaimana pengaturan ulang dapat dimulai; namun, masalahnya adalah Anda harus menjawab pertanyaan sambil memberikan beberapa bentuk identifikasi (email atau nama pengguna), yang kemudian membuat hampir tidak mungkin untuk menjawab secara intuitif tanpa mengungkapkan keberadaan akun pengguna anonim tersebut.
Dengan pendekatan ini ada kecil kegunaannya menurun karena jika mencoba mereset akun yang tidak ada, tidak ada tanggapan langsung. Tentu saja, itulah inti dari pengiriman email, namun dari sudut pandang pengguna akhir yang sebenarnya, jika mereka memasukkan alamat yang salah, mereka hanya akan mengetahui untuk pertama kalinya kapan mereka menerima email tersebut. Hal ini mungkin menimbulkan ketegangan di pihaknya, namun ini adalah harga kecil yang harus dibayar untuk proses yang jarang terjadi ini.
Catatan lain, sedikit keluar dari topik: fungsi bantuan login yang menunjukkan apakah nama pengguna atau alamat email benar memiliki masalah yang sama. Selalu tanggapi pengguna dengan pesan “Kombinasi nama pengguna dan kata sandi Anda tidak valid” daripada secara eksplisit mengonfirmasi keberadaan kredensial (misalnya, “nama pengguna benar, tetapi kata sandi salah”).
Mengirim setel ulang kata sandi vs mengirim URL setel ulang
Konsep selanjutnya yang perlu kita bahas adalah bagaimana cara mereset password Anda. Ada dua solusi populer:
- Menghasilkan kata sandi baru di server dan mengirimkannya melalui email
- Kirim email dengan URL unik untuk mempermudah proses reset
Meskipun , poin pertama tidak boleh digunakan. Masalahnya adalah artinya memang ada kata sandi yang disimpan, yang dapat Anda kembalikan dan gunakan lagi kapan saja; itu dikirim melalui saluran yang tidak aman dan tetap berada di kotak masuk Anda. Kemungkinannya adalah kotak masuk disinkronkan di seluruh perangkat seluler dan klien email, ditambah lagi kotak masuk tersebut dapat disimpan online di layanan email web untuk waktu yang sangat lama. Intinya adalah itu kotak surat tidak dapat dianggap sebagai sarana penyimpanan jangka panjang yang dapat diandalkan.
Namun selain itu, poin pertama memiliki masalah serius lainnya - itu menyederhanakan sebanyak mungkin memblokir akun dengan niat jahat. Jika saya mengetahui alamat email seseorang yang memiliki akun di suatu situs web, maka saya dapat memblokirnya kapan saja hanya dengan mengatur ulang kata sandinya; Ini adalah serangan penolakan layanan yang disajikan di piring perak! Inilah sebabnya mengapa penyetelan ulang hanya boleh dilakukan setelah verifikasi berhasil atas hak pemohon atas penyetelan ulang tersebut.
Ketika kita berbicara tentang URL penyetelan ulang, yang kami maksud adalah alamat situs web tersebut unik untuk kasus khusus proses reset ini. Tentu saja, ini harus acak, tidak mudah ditebak, dan tidak boleh berisi tautan eksternal apa pun ke akun yang memudahkan pengaturan ulang. Misalnya, URL penyetelan ulang tidak boleh sekadar berupa jalur seperti "Reset/?namapengguna=JohnSmith".
Kami ingin membuat token unik yang dapat dikirimkan sebagai URL penyetelan ulang, lalu dicocokkan dengan catatan server akun pengguna, sehingga mengonfirmasi bahwa pemilik akun sebenarnya adalah orang yang sama yang mencoba menyetel ulang kata sandi. Misalnya, token dapat berupa "3ce7854015cd38c862cb9e14a1ae552b" dan disimpan dalam tabel bersama dengan ID pengguna yang melakukan penyetelan ulang dan waktu pembuatan token (lebih lanjut tentang ini di bawah). Saat email terkirim, berisi URL seperti “Reset/?id=3ce7854015cd38c862cb9e14a1ae552b”, dan saat pengguna mendownloadnya, halaman tersebut menanyakan keberadaan token, setelah itu mengonfirmasi informasi pengguna dan memungkinkan mereka untuk mengubah kata sandi.
Tentu saja, karena proses di atas (semoga) memungkinkan pengguna membuat kata sandi baru, kita perlu memastikan bahwa URL dimuat melalui HTTPS. TIDAK, , URL token ini harus menggunakan keamanan lapisan transport agar bentuk kata sandi baru tidak dapat diserang dan kata sandi yang dibuat pengguna dikirimkan melalui koneksi aman.
Selain itu untuk URL reset Anda perlu menambahkan batas waktu token agar proses reset dapat diselesaikan dalam interval tertentu, misalnya dalam waktu satu jam. Hal ini memastikan bahwa jangka waktu penyetelan ulang dijaga seminimal mungkin sehingga penerima URL penyetelan ulang hanya dapat bertindak dalam jangka waktu yang sangat kecil tersebut. Tentu saja, penyerang dapat memulai proses penyetelan ulang lagi, namun mereka perlu mendapatkan URL penyetelan ulang unik lainnya.
Terakhir, kita perlu memastikan bahwa proses ini dapat dilakukan satu kali saja. Setelah proses reset selesai, token harus dihapus agar URL reset tidak lagi berfungsi. Poin sebelumnya diperlukan untuk memastikan bahwa penyerang memiliki jendela yang sangat kecil di mana ia dapat memanipulasi URL setel ulang. Ditambah lagi tentunya setelah reset berhasil maka token tidak diperlukan lagi.
Beberapa langkah ini mungkin tampak berlebihan, namun tidak mengganggu kegunaan dan sebenarnya meningkatkan keselamatan, meskipun dalam situasi yang kami harap jarang terjadi. Dalam 99% kasus, pengguna akan mengaktifkan pengaturan ulang dalam waktu yang sangat singkat dan tidak akan mengatur ulang kata sandi lagi dalam waktu dekat.
Peran CAPTCHA
Oh, CAPTCHA, fitur keamanan yang kita semua benci! Faktanya, CAPTCHA bukanlah alat perlindungan melainkan alat identifikasi - apakah Anda manusia atau robot (atau skrip otomatis). Tujuannya adalah untuk menghindari pengiriman formulir otomatis, yang tentu saja, bisa digunakan sebagai upaya untuk merusak keamanan. Dalam konteks pengaturan ulang kata sandi, CAPTCHA berarti bahwa fungsi pengaturan ulang tidak dapat dipaksakan untuk mengirim spam ke pengguna atau mencoba menentukan keberadaan akun (yang, tentu saja, tidak akan mungkin dilakukan jika Anda mengikuti saran di bagian tentang memverifikasi identitas).
Tentu saja, CAPTCHA itu sendiri tidaklah sempurna; Ada banyak preseden untuk “peretasan” perangkat lunaknya dan mencapai tingkat keberhasilan yang memadai (60-70%). Selain itu, ada solusi yang ditunjukkan di postingan saya tentang , di mana Anda dapat membayar sepersekian sen kepada orang-orang untuk menyelesaikan setiap CAPTCHA dan mencapai tingkat keberhasilan 94%. Artinya, negara ini rentan, namun (sedikit) meningkatkan hambatan masuk.
Mari kita lihat contoh PayPal:
Dalam hal ini, proses reset tidak dapat dimulai sampai CAPTCHA diselesaikan secara teoritis tidak mungkin untuk mengotomatiskan prosesnya. Secara teori.
Namun, untuk sebagian besar aplikasi web, hal ini berlebihan dan benar-benar tepat mewakili penurunan kegunaan - orang tidak menyukai CAPTCHA! Selain itu, CAPTCHA adalah sesuatu yang dapat Anda kembalikan dengan mudah jika diperlukan. Jika layanan mulai diserang (di sinilah logging berguna, tetapi akan dibahas lebih lanjut nanti), maka menambahkan CAPTCHA sangatlah mudah.
Pertanyaan dan jawaban rahasia
Dengan semua metode yang kami pertimbangkan, kami dapat mengatur ulang kata sandi hanya dengan memiliki akses ke akun email. Saya bilang “hanya”, tapi tentu saja mendapatkan akses ke akun email orang lain adalah tindakan ilegal. должно menjadi suatu proses yang kompleks. Namun .
Faktanya, link di atas tentang peretasan Yahoo! melayani dua tujuan; pertama, ini menggambarkan betapa mudahnya meretas (beberapa) akun email, dan kedua, ini menunjukkan betapa pertanyaan keamanan yang buruk dapat digunakan dengan niat jahat. Tapi kita akan membahasnya lagi nanti.
Masalah dengan penyetelan ulang kata sandi berbasis email XNUMX% adalah integritas akun situs yang Anda coba atur ulang menjadi XNUMX% bergantung pada integritas akun email. Siapa pun yang memiliki akses ke email Anda memiliki akses ke akun apa pun yang dapat diatur ulang hanya dengan menerima email. Untuk akun seperti itu, email adalah “kunci semua pintu” kehidupan online Anda.
Salah satu cara untuk mengurangi risiko ini adalah dengan menerapkan pola tanya jawab keamanan. Pasti Anda pernah melihatnya: pilihlah pertanyaan yang hanya dapat Anda jawab memiliki tahu jawabannya, dan kemudian ketika Anda mengatur ulang kata sandi Anda, Anda akan diminta untuk itu. Hal ini menambah keyakinan bahwa orang yang mencoba melakukan reset memang benar pemilik akun.
Kembali ke Sarah Palin: kesalahannya adalah jawaban atas pertanyaan/pertanyaan keamanannya dapat dengan mudah ditemukan. Terutama jika Anda adalah figur publik yang penting, informasi tentang nama gadis ibu Anda, riwayat pendidikan, atau di mana seseorang pernah tinggal di masa lalu bukanlah rahasia. Faktanya, sebagian besar dapat ditemukan oleh hampir semua orang. Inilah yang terjadi pada Sarah:
Peretas David Kernell memperoleh akses ke akun Palin dengan mencari rincian tentang latar belakangnya, seperti universitas dan tanggal lahirnya, dan kemudian menggunakan fitur pemulihan kata sandi Yahoo! yang terlupa.
Pertama-tama, ini adalah kesalahan desain dari pihak Yahoo! — dengan menentukan pertanyaan sederhana seperti itu, perusahaan pada dasarnya menyabotase nilai pertanyaan keamanan, dan juga perlindungan sistemnya. Tentu saja, mengatur ulang kata sandi untuk akun email selalu lebih sulit karena Anda tidak dapat membuktikan kepemilikan dengan mengirimkan email ke pemiliknya (tanpa alamat kedua), namun untungnya tidak banyak kegunaan untuk membuat sistem seperti itu saat ini.
Mari kembali ke pertanyaan keamanan - ada opsi untuk memungkinkan pengguna membuat pertanyaan mereka sendiri. Masalahnya adalah hal ini akan menimbulkan pertanyaan yang sangat jelas:
Apa warna langitnya?
Pertanyaan yang membuat orang tidak nyaman ketika pertanyaan keamanan digunakan untuk mengidentifikasi orang (misalnya, di pusat panggilan):
Dengan siapa aku tidur saat Natal?
Atau sejujurnya pertanyaan bodoh:
Bagaimana Anda mengeja "kata sandi"?
Jika menyangkut pertanyaan keamanan, pengguna harus menyelamatkan diri mereka sendiri! Dengan kata lain, pertanyaan keamanan harus ditentukan oleh situs itu sendiri, atau lebih baik lagi, ditanyakan seri pertanyaan keamanan yang dapat dipilih pengguna. Dan memilihnya tidaklah mudah satu; idealnya pengguna harus memilih dua atau lebih pertanyaan keamanan pada saat pendaftaran akun, yang kemudian akan digunakan sebagai saluran identifikasi kedua. Memiliki beberapa pertanyaan meningkatkan kepercayaan diri dalam proses verifikasi, dan juga memberikan kemampuan untuk menambahkan keacakan (tidak selalu menampilkan pertanyaan yang sama), ditambah memberikan sedikit redundansi jika pengguna sebenarnya lupa kata sandinya.
Apa pertanyaan keamanan yang bagus? Hal ini dipengaruhi oleh beberapa faktor:
- Harus singkat — pertanyaannya harus jelas dan tidak ambigu.
- Jawabannya pasti spesifik — kita tidak membutuhkan pertanyaan yang bisa dijawab berbeda oleh satu orang
- Jawaban yang mungkin seharusnya adalah beragam - menanyakan warna favorit seseorang hanya menghasilkan sedikit kemungkinan jawaban
- pencarian jawabannya harus rumit – jika jawabannya dapat dengan mudah ditemukan apa saja (ingat orang yang jabatannya tinggi), maka dia jahat
- Jawabannya pasti permanen tepat waktu - jika Anda menanyakan film favorit seseorang, setahun kemudian jawabannya mungkin berbeda
Kebetulan, ada situs web yang didedikasikan untuk mengajukan pertanyaan bagus bernama . Beberapa soal nampaknya cukup bagus, ada pula yang tidak lulus beberapa tes yang dijelaskan di atas, terutama tes “kemudahan pencarian”.
Izinkan saya menunjukkan bagaimana PayPal menerapkan pertanyaan keamanan dan, khususnya, upaya yang dilakukan situs dalam otentikasi. Di atas kami melihat halaman untuk memulai proses (dengan CAPTCHA), dan di sini kami akan menunjukkan apa yang terjadi setelah Anda memasukkan alamat email dan menyelesaikan CAPTCHA:
Akibatnya, pengguna menerima surat berikut:
Sejauh ini semuanya cukup normal, namun inilah yang tersembunyi di balik URL penyetelan ulang ini:
Jadi, pertanyaan keamanan ikut berperan. Faktanya, PayPal juga memungkinkan Anda mengatur ulang kata sandi dengan memverifikasi nomor kartu kredit Anda, sehingga ada saluran tambahan yang tidak dapat diakses oleh banyak situs. Saya tidak bisa mengubah kata sandi saya tanpa menjawab keduanya pertanyaan keamanan (atau tidak mengetahui nomor kartu). Bahkan jika seseorang membajak email saya, mereka tidak akan dapat mengatur ulang kata sandi akun PayPal saya kecuali mereka mengetahui lebih banyak informasi pribadi tentang saya. Informasi apa? Berikut adalah opsi pertanyaan keamanan yang ditawarkan PayPal:
Pertanyaan tentang sekolah dan rumah sakit mungkin sedikit meragukan dalam hal kemudahan pencarian, namun pertanyaan lainnya tidak terlalu buruk. Namun, untuk meningkatkan keamanan, PayPal memerlukan identifikasi tambahan perubahan jawaban atas pertanyaan keamanan:
PayPal adalah contoh yang cukup utopis mengenai pengaturan ulang kata sandi yang aman: PayPal menerapkan CAPTCHA untuk mengurangi bahaya serangan brute force, memerlukan dua pertanyaan keamanan, dan kemudian memerlukan jenis identifikasi lain yang sama sekali berbeda hanya untuk mengubah jawabannya—dan ini setelah pengguna sudah masuk. Tentu saja, inilah yang kami lakukan mengharapkan dari PayPal; adalah lembaga keuangan yang menangani uang dalam jumlah besar. Ini tidak berarti bahwa setiap penyetelan ulang kata sandi harus mengikuti langkah-langkah ini—seringkali langkah ini berlebihan—tetapi ini adalah contoh yang baik untuk kasus di mana keamanan adalah urusan yang serius.
Kenyamanan sistem pertanyaan keamanan adalah jika Anda belum segera menerapkannya, Anda dapat menambahkannya nanti jika tingkat perlindungan sumber daya memerlukannya. Contoh bagusnya adalah Apple, yang baru saja menerapkan mekanisme ini [artikel ditulis pada tahun 2012]. Setelah saya mulai memperbarui aplikasi di iPad saya, saya melihat permintaan berikut:
Lalu saya melihat layar di mana saya dapat memilih beberapa pasang pertanyaan dan jawaban keamanan, serta alamat email penyelamat:
Sedangkan untuk PayPal, pertanyaannya sudah dipilih sebelumnya dan beberapa di antaranya sebenarnya cukup bagus:
Masing-masing dari tiga pasangan pertanyaan/jawaban mewakili serangkaian kemungkinan pertanyaan yang berbeda, jadi ada banyak cara untuk mengonfigurasi akun.
Aspek lain yang perlu dipertimbangkan dalam menjawab pertanyaan keamanan Anda adalah penyimpanan. Memiliki database teks biasa dalam database menimbulkan ancaman yang hampir sama dengan kata sandi, yaitu mengekspos database secara instan mengungkapkan nilai dan tidak hanya menempatkan aplikasi dalam risiko, namun berpotensi aplikasi yang sama sekali berbeda menggunakan pertanyaan keamanan yang sama (di sana lagi ). Salah satu opsinya adalah hashing yang aman (algoritme yang kuat dan garam yang acak secara kriptografis), namun tidak seperti kebanyakan kasus penyimpanan kata sandi, mungkin ada alasan bagus mengapa responsnya terlihat sebagai teks biasa. Skenario yang umum adalah verifikasi identitas oleh operator telepon langsung. Tentu saja, hashing juga berlaku dalam kasus ini (operator cukup memasukkan respons yang disebutkan oleh klien), namun dalam kasus terburuk, respons rahasia harus ditempatkan pada tingkat penyimpanan kriptografi tertentu, meskipun itu hanya enkripsi simetris. . Meringkaskan: perlakukan rahasia seperti rahasia!
Salah satu aspek terakhir dari pertanyaan dan jawaban keamanan adalah bahwa mereka lebih rentan terhadap rekayasa sosial. Mencoba mengekstrak kata sandi akun orang lain secara langsung adalah satu hal, tetapi memulai percakapan tentang pembentukannya (pertanyaan keamanan populer) adalah hal yang sama sekali berbeda. Faktanya, Anda bisa berkomunikasi dengan baik dengan seseorang tentang banyak aspek kehidupannya yang mungkin menimbulkan pertanyaan rahasia tanpa menimbulkan kecurigaan. Tentu saja, inti dari pertanyaan keamanan adalah bahwa hal itu berkaitan dengan pengalaman hidup seseorang, sehingga mudah diingat, dan di situlah letak masalahnya - orang suka berbicara tentang pengalaman hidup mereka! Tidak banyak yang dapat Anda lakukan mengenai hal ini, hanya jika Anda memilih opsi pertanyaan keamanan seperti itu lebih rendah mungkin bisa dihilangkan dengan rekayasa sosial.
[Bersambung.]Tentang Hak Periklanan
VDSina menawarkan dapat diandalkan , setiap server terhubung ke saluran Internet 500 Megabit dan terlindungi dari serangan DDoS secara gratis!
Sumber: www.habr.com