Soalnya, dunia lupa kata sandi sebenarnya cukup misterius. Ada banyak sudut pandang berbeda yang dapat diterima dengan sempurna dan banyak sudut pandang yang cukup berbahaya. Kemungkinannya adalah Anda telah menjumpai masing-masingnya berkali-kali sebagai pengguna akhir; jadi saya akan mencoba menggunakan contoh-contoh ini untuk menunjukkan siapa yang melakukan hal-hal dengan benar dan siapa yang tidak, dan apa yang harus difokuskan untuk mengimplementasikan fungsi dengan benar dalam aplikasi Anda.
Penyimpanan kata sandi: hashing, enkripsi, dan (ooh!) Teks biasa
Kami tidak dapat membahas apa yang harus dilakukan dengan kata sandi yang terlupa sebelum membahas cara menyimpannya. Dalam database, kata sandi disimpan dalam salah satu dari tiga jenis utama:
- Teks sederhana. Ada kolom kata sandi, yang disimpan dalam teks biasa.
- . ( ), .
- . ( , ); , , , .
Mari kita hadapi pertanyaan paling sederhana segera: jangan pernah menyimpan kata sandi dalam teks biasa! Tidak pernah. Satu kerentanan injeksi tunggal , satu cadangan dibuat secara tidak sengaja, atau salah satu dari lusinan kesalahan sederhana lainnya - dan hanya itu, gamer, semua sandi Anda - yaitu, maaf, semua sandi pelanggan Anda akan menjadi domain publik. Tentu saja, ini berarti kemungkinan besar bahwa semua kata sandi mereka dari semua akun mereka di sistem lain akan menjadi domain publik . Dan itu salahmu.
Enkripsi lebih baik, tetapi memiliki kelemahan. Masalah dengan enkripsi adalah dekripsi; Anda dapat mengambil cipher yang tampak gila ini dan mengubahnya kembali menjadi teks biasa, dan ketika itu terjadi, kita akan kembali ke situasi dengan sandi yang dapat dibaca. Bagaimana ini bisa terjadi? Cacat kecil menembus kode yang mendekripsi kata sandi, membuatnya tersedia untuk umum - ini adalah salah satu cara. Peretas mendapatkan akses ke mesin tempat data terenkripsi disimpan - ini adalah metode kedua. Cara lain, sekali lagi, adalah dengan mencuri backup database, dan seseorang juga mendapatkan kunci enkripsi, yang seringkali disimpan dengan sangat tidak aman.
Dan itu membawa kita pada hashing. Ide di balik hashing adalah bahwa itu dilakukan dengan satu cara; satu-satunya cara untuk membandingkan kata sandi yang dimasukkan oleh pengguna dengan versi hashnya adalah dengan mencirikan kata sandi yang dimasukkan dan membandingkannya. Untuk mencegah serangan dengan alat seperti tabel pelangi, kami menggunakan garam untuk menambahkan keacakan proses (baca posting saya di penyimpanan kriptografi untuk gambaran lengkap ). Pada akhirnya, jika diterapkan dengan benar, kami dapat dengan yakin berasumsi bahwa kata sandi yang di-hash tidak akan pernah menjadi teks biasa lagi (saya akan berbicara tentang manfaat berbagai algoritme hashing di posting lain).
Argumen singkat tentang hashing dan enkripsi: Satu-satunya alasan Anda perlu mengenkripsi daripada meng-hash kata sandi adalah ketika Anda perlu melihat kata sandi dalam teks biasa, dan Anda tidak boleh menginginkannya , setidaknya dalam situasi standar. situs web. Jika Anda membutuhkannya, kemungkinan besar Anda melakukan sesuatu yang salah!
Perhatian!
Teks postingan di bawah ini adalah bagian dari tangkapan layar situs porno AlotPorn. Itu terpotong dengan rapi, sehingga tidak ada yang tidak dapat dilihat di pantai, tetapi jika masih mungkin menyebabkan beberapa masalah maka jangan gulir ke bawah halaman.
Selalu setel ulang kata sandi Anda, jangan pernah mengingatkannya
Pernahkah Anda diminta untuk membuat fitur pengingat kata sandi? Ambil langkah mundur dan pikirkan tentang permintaan ini secara terbalik: mengapa "pengingat" ini perlu? Karena pengguna lupa kata sandinya. Apa yang sebenarnya ingin kita lakukan? Bantu dia masuk lagi.
Saya memahami kata "reminder" digunakan (sering) dalam bahasa sehari-hari, tetapi yang sebenarnya kami coba lakukan adalah membantu pengguna agar dapat online kembali dengan aman . Karena kami membutuhkan keamanan, ada dua alasan mengapa pengingat (yaitu mengirim pengguna kata sandinya) tidak sesuai:
- — . , HTTP ( HTTPS), , . , , , , , , , . — .
- . — ( ), .
Izinkan saya mengilustrasikan masalah dengan usoutdoor.com sebagai contoh : Berikut adalah halaman login yang khas:
Jelas, masalah pertama adalah halaman login tidak dimuat melalui HTTPS, tetapi situs tersebut juga menawarkan untuk mengirim kata sandi ("Kirim Kata Sandi"). Ini mungkin contoh penggunaan sehari-hari dari istilah yang disebutkan di atas, jadi mari kita selangkah lebih maju dan lihat apa yang terjadi:
Sayangnya, tidak terlihat jauh lebih baik; dan email mengonfirmasi masalahnya:
Ini memberi tahu kita dua aspek penting dari usoutdoor.com:
- Situs tidak mencirikan kata sandi. Paling banter, mereka dienkripsi, tetapi kemungkinan besar mereka disimpan dalam teks biasa; kami tidak melihat bukti yang sebaliknya.
- Situs mengirimkan kata sandi jangka panjang (kita dapat kembali dan menggunakannya berulang kali) melalui saluran yang tidak aman.
Dengan pemikiran ini, kami perlu memeriksa apakah proses reset dilakukan dengan cara yang aman. Langkah pertama untuk melakukannya adalah memastikan pemohon memiliki hak untuk melakukan penyetelan ulang. Dengan kata lain, sebelumnya kita membutuhkan pemeriksaan identitas; Mari kita lihat apa yang terjadi ketika sebuah identitas diverifikasi tanpa terlebih dahulu memverifikasi bahwa pemohon memang pemilik akun.
Mencantumkan nama pengguna dan dampaknya terhadap anonimitas
Masalah ini paling baik diilustrasikan secara visual. Masalah:
Lihat? Perhatikan pesan "Tidak ada pengguna terdaftar dengan alamat email ini" ("Pengguna dengan alamat email ini tidak terdaftar"). Masalahnya jelas muncul jika situs serupa mengonfirmasi keberadaan pengguna yang terdaftar dengan alamat email tersebut. Bingo - Anda baru saja menemukan fetish porno Suami / Bos / Tetangga Anda!
Tentu saja, pornografi adalah contoh yang cukup kanonik tentang pentingnya privasi, tetapi bahaya menghubungkan seseorang dengan situs web tertentu jauh lebih luas daripada situasi yang berpotensi memalukan yang dijelaskan di atas. Salah satu bahayanya adalah rekayasa sosial; jika penyerang dapat mencocokkan orang tersebut dengan layanan tersebut, maka dia akan memiliki informasi yang dapat mulai digunakannya. Misalnya, dia mungkin menghubungi seseorang yang menyamar sebagai juru bicara situs web dan meminta informasi lebih lanjut dalam upaya spearphishing .
Praktik seperti ini juga meningkatkan bahaya "enumerasi nama pengguna", di mana seseorang dapat memverifikasi keberadaan seluruh kumpulan nama pengguna atau alamat email di situs web dengan kueri grup sederhana dan memeriksa tanggapannya. Apakah Anda memiliki daftar alamat email semua karyawan dan beberapa menit untuk menulis skrip? Kemudian Anda melihat apa masalahnya!
Apa alternatifnya? Sebenarnya, ini cukup sederhana, dan diterapkan dengan baik di Entropay :
Di sini Entropay sama sekali tidak mengungkapkan keberadaan alamat email di sistemnya kepada siapa pun yang bukan pemilik alamat email tersebut . Jika Anda memiliki alamat ini dan itu tidak ada dalam sistem, maka Anda akan menerima email seperti ini:
Tentu saja, ada situasi yang dapat diterima di mana seseorang mengira mereka telah terdaftar di situs web. tetapi tidak, atau melakukannya dari alamat email yang berbeda. Contoh yang ditunjukkan di atas menangani kedua situasi dengan baik. Tentunya jika alamatnya cocok, maka Anda akan menerima email sehingga memudahkan untuk mereset password Anda.
Kehalusan solusi Entropay adalah bahwa verifikasi identitas dilakukan melalui email sebelum verifikasi online apa pun. Beberapa situs meminta pengguna untuk pertanyaan rahasia (lebih lanjut tentang ini di bawah) sebelumnyabagaimana penyetelan ulang dapat dimulai; namun, masalah dengan ini adalah Anda perlu menjawab pertanyaan sambil memberikan beberapa bentuk identifikasi (email atau nama pengguna), yang membuatnya hampir tidak mungkin untuk menjawab secara intuitif tanpa mengungkapkan keberadaan akun pengguna anonim.
Ada sedikit penurunan dalam kegunaan dengan pendekatan ini , karena tidak ada umpan balik instan jika terjadi upaya untuk mengatur ulang akun yang tidak ada. Tentu saja, ini adalah inti dari mengirim email, tetapi dari sudut pandang pengguna akhir yang sebenarnya, jika dia memasukkan alamat yang salah, dia pertama kali mempelajarinya hanya ketika dia menerima email. Hal ini dapat menyebabkan ketegangan di pihaknya, tetapi ini adalah harga kecil yang harus dibayar untuk proses yang jarang terjadi.
Catatan tambahan, sedikit keluar dari topik, fungsi bantuan login yang mengungkapkan nama pengguna atau alamat email yang benar memiliki masalah yang sama. Selalu tanggapi pengguna dengan pesan "Kombinasi nama pengguna dan sandi Anda tidak valid", daripada secara eksplisit mengonfirmasi keberadaan kredensial (misalnya, "nama pengguna benar, tetapi sandi dimasukkan dengan salah").
Mengirim ulang kata sandi versus mengirim url penyetelan ulang
Konsep selanjutnya yang perlu kita bahas berkaitan dengan cara reset password. Ada dua solusi populer:
- Membuat kata sandi baru di server dan mengirimkannya melalui email
- Mengirim email dengan URL unik untuk mempermudah proses reset
Meskipun banyak tutorial , poin pertama tidak boleh digunakan. Masalahnya adalah itu berarti ada sandi tersimpan yang dapat dikembalikan dan digunakan kembali kapan saja; itu dikirim melalui saluran yang tidak aman dan tetap ada di kotak masuk Anda. Kemungkinannya, kotak masuk disinkronkan ke perangkat seluler dan klien email, ditambah lagi mereka dapat disimpan secara online di layanan email web untuk waktu yang sangat lama. Intinya adalah kotak surat tidak dapat dilihat sebagai media yang dapat diandalkan untuk penyimpanan jangka panjang .
Tapi selain itu, paragraf pertama memiliki masalah serius lainnya - ini sederhanakan mungkinpenguncian akun dengan niat jahat. Jika saya mengetahui alamat email orang yang memiliki akun di situs web, maka saya dapat memblokirnya kapan saja hanya dengan menyetel ulang kata sandinya; ini adalah serangan denial-of-service, diletakkan di atas piring perak! Itulah mengapa penyetelan ulang harus dilakukan hanya setelah pemeriksaan yang berhasil dengan pemohon hak untuk itu.
Ketika kita berbicara tentang URL reset, yang kami maksud adalah alamat situs web yang unik untuk contoh khusus dari proses reset . Ini tentu saja harus acak, tidak mudah ditebak, dan tidak boleh berisi tautan akun eksternal untuk memudahkan pengaturan ulang. Misalnya, URL setel ulang tidak boleh hanya berupa jalur seperti "Reset /? Username = JohnSmith".
Kami ingin membuat token unik yang dapat dikirim melalui email sebagai URL penyetelan ulang, dan kemudian diverifikasi dengan catatan server terhadap akun pengguna, dengan demikian mengonfirmasi bahwa pemilik akun memang orang yang sama yang mencoba menyetel ulang kata sandi. ... Misalnya, token bisa dalam bentuk "3ce7854015cd38c862cb9e14a1ae552b" dan disimpan dalam tabel bersama dengan ID pengguna dari pengguna yang menyetel ulang dan waktu token dibuat (lebih lanjut tentang ini di bawah). Ketika email dikirim, itu berisi URL seperti "Reset /? Id = 3ce7854015cd38c862cb9e14a1ae552b", dan ketika pengguna memuatnya, halaman menanyakan keberadaan token, setelah itu mengkonfirmasi informasi pengguna dan memungkinkan mengubah kata sandi.
Tentu saja, karena proses di atas (semoga) memungkinkan pengguna untuk membuat kata sandi baru, pastikan bahwa URL dimuat melalui HTTPS. Tidak, tidak cukup mengirimnya dengan permintaan POST melalui HTTPS , URL dengan token ini harus menggunakan keamanan lapisan transport sehingga tidak mungkin melakukan serangan MITM pada formulir entri kata sandi baru dan kata sandi yang dibuat oleh pengguna ditransmisikan melalui koneksi yang aman.
Selain itu, untuk reset URL, Anda perlu menambahkan token time limit agar proses reset bisa dilakukan dalam interval tertentu, misalnya dalam satu jam. Ini memastikan bahwa jendela setel ulang minimal sehingga penerima URL setel ulang hanya dapat bertindak dalam jendela yang sangat kecil ini. Tentu saja, penyerang dapat memulai proses penyetelan ulang, tetapi ia perlu mendapatkan URL penyetelan ulang unik lainnya.
Terakhir, kita perlu membuat proses ini sekali jalan. Setelah proses reset selesai, token harus dihapus sehingga URL reset tidak lagi berfungsi. Poin sebelumnya diperlukan agar penyerang memiliki jendela yang sangat kecil di mana dia dapat memanipulasi URL reset. Plus, tentu saja, setelah reset berhasil, token tidak lagi diperlukan.
Beberapa dari langkah ini mungkin tampak terlalu berlebihan, tetapi tidak mengganggu kegunaan sama sekali dan benar-benar meningkatkan keamanan, meskipun dalam situasi yang kami harap akan jarang terjadi. Dalam 99% kasus, pengguna akan melakukan penyetelan ulang dalam waktu yang sangat singkat dan tidak akan menyetel ulang kata sandi lagi dalam waktu dekat.
Peran CAPTCHA
Oh, CAPTCHA, obat yang kita semua suka benci! Faktanya, CAPTCHA tidak berarti perlindungan seperti identifikasi - Anda adalah manusia atau robot (atau skrip otomatis). Tujuannya adalah untuk menghindari pengiriman formulir otomatis, yang tentu saja dapat digunakan sebagai upaya untuk melanggar keamanan. Dalam konteks menyetel ulang kata sandi, CAPTCHA berarti bahwa fungsi penyetelan ulang tidak dapat dibobol secara brute force baik untuk mengirim spam kepada pengguna atau mencoba menentukan keberadaan akun (yang, tentu saja, tidak akan mungkin jika Anda mengikuti saran dari bagian tentang verifikasi identitas).
Tentu saja, CAPTCHA itu sendiri tidak ideal; ada banyak preseden untuk software "hacking" dan mencapai tingkat keberhasilan yang memadai (60-70%). Selain itu, ada solusi yang ditunjukkan dalam posting saya tentang meretas CAPTCHA dengan orang-orang otomatis di mana Anda dapat membayar orang sepersekian sen untuk menyelesaikan setiap CAPTCHA dan mendapatkan tingkat keberhasilan 94%. Artinya, ini rentan, tetapi (sedikit) meningkatkan penghalang untuk masuk.
Mari kita lihat contoh PayPal:
Dalam kasus ini, proses reset tidak dapat dimulai sebelum CAPTCHA diselesaikan, sehingga secara teoritis tidak mungkin untuk mengotomatiskan proses tersebut. Dalam teori.
Namun, untuk sebagian besar aplikasi web ini akan berlebihan dan jelas merupakan penurunan kegunaan - orang tidak suka CAPTCHA! Selain itu, CAPTCHA adalah hal yang dapat dengan mudah dikunjungi kembali saat dibutuhkan. Jika layanan mulai diserang (logging berguna di sini, tetapi lebih dari itu nanti), maka menambahkan CAPTCHA jauh lebih mudah.
Pertanyaan dan jawaban rahasia
Dengan semua metode yang kami lihat, kami dapat mengatur ulang kata sandi hanya dengan memiliki akses ke akun email. Saya mengatakan "hanya", tetapi tentu saja, mendapatkan akses ke akun email orang lain secara ilegal pasti merupakan proses yang sulit. Namun, tidak selalu demikian .
Faktanya, tautan di atas tentang meretas akun Yahoo! melayani dua tujuan; pertama, ini menggambarkan betapa mudahnya meretas (beberapa) akun email, dan kedua, ini menunjukkan bagaimana pertanyaan keamanan yang buruk dapat digunakan secara jahat. Tapi kita akan membahasnya nanti.
Masalah dengan menyetel ulang sandi dengan 100% ketergantungan pada email adalah integritas akun situs yang Anda coba setel ulang menjadi 100% bergantung pada integritas akun email. Siapa pun yang memiliki akses ke email Anda memiliki akses ke akun mana pun yang dapat disetel ulang hanya dengan menerima email . Untuk akun seperti itu, email adalah "kunci ke semua pintu" kehidupan online Anda.
Salah satu cara untuk mengurangi risiko ini adalah dengan menerapkan pola tanya jawab keamanan. Pasti Anda pernah melihatnya sebelumnya: pilih pertanyaan yang hanya Anda miliki untuk menjawabnyatahu jawabannya, setelah itu ketika Anda mengatur ulang kata sandi, Anda akan ditanya. Ini menambah keyakinan bahwa orang yang mencoba menyetel ulang memang adalah pemilik akun tersebut.
Kembali ke Sarah Palin, kesalahannya adalah jawaban atas pertanyaan / pertanyaan keamanannya mudah ditemukan. Khususnya, jika Anda adalah figur publik yang penting, informasi tentang nama gadis ibu Anda, riwayat pendidikan, atau di mana seseorang mungkin pernah hidup di masa lalu bukanlah rahasia. Faktanya, sebagian besar dapat ditemukan oleh hampir semua orang. Dan begitulah yang terjadi dengan Sarah:
Hacker David Kernell memperoleh akses ke akun Palin dengan mencari informasi latar belakangnya, seperti universitas dan tanggal lahirnya, kemudian menggunakan fitur pemulihan kata sandi Yahoo! yang terlupa.
Ini terutama merupakan cacat desain di pihak Yahoo! - Dengan menunjukkan pertanyaan sederhana ini, perusahaan pada dasarnya menyabotase nilai pertanyaan rahasia, dan karena itu melindungi 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 memiliki alamat kedua), tetapi untungnya, tidak banyak cara untuk menggunakan sistem ini saat ini.
Kembali ke pertanyaan rahasia - ada opsi untuk memberi pengguna kemampuan untuk membuat pertanyaan mereka sendiri. Masalahnya adalah bahwa hasilnya adalah pertanyaan yang sangat jelas:
Apa warna langit itu?
Pertanyaan yang membuat orang berada dalam posisi yang canggung saat seseorang menggunakan pertanyaan keamanan untuk mengidentifikasi(misalnya, di call center): Dengan
siapa saya tidur pada hari Natal?
Atau pertanyaan bodoh yang terus terang:
Bagaimana Anda mengeja "password"?
Ketika datang ke pertanyaan keamanan, pengguna harus diselamatkan dari diri mereka sendiri! Dengan kata lain, pertanyaan rahasia harus ditentukan oleh situs itu sendiri, atau lebih baik lagi, ajukan serangkaian pertanyaan rahasia yang dapat dipilih pengguna. Dan jangan hanya memilih satu ; idealnya pengguna harus memilih dua atau lebih pertanyaan keamanan pada saat pendaftaranyang kemudian akan digunakan sebagai saluran identifikasi kedua. Memiliki banyak pertanyaan meningkatkan kepercayaan dalam proses verifikasi, serta kemampuan untuk menambahkan keacakan (tidak selalu menampilkan pertanyaan yang sama), ditambah lagi memberikan sedikit redundansi jika pengguna sebenarnya lupa kata sandi.
Apa yang seharusnya menjadi pertanyaan keamanan yang bagus? Hal ini dipengaruhi oleh beberapa faktor:
- Ini harus singkat - pertanyaannya harus jelas dan tidak ambigu.
- Jawabannya harus spesifik - kita tidak memerlukan pertanyaan yang dapat dijawab oleh satu orang dengan cara yang berbeda
- Jawaban yang mungkin harus bervariasi - menanyakan tentang warna favorit seseorang memberikan sebagian kecil kemungkinan jawaban
- — ( , ),
- — - ,
Saat itu terjadi, ada situs web pertanyaan bagus yang disebut GoodSecurityQuestions.com . Beberapa pertanyaan tampaknya cukup bagus, yang lain tidak lulus beberapa tes yang dijelaskan di atas, khususnya tes "kemudahan pencarian".
Izinkan saya menunjukkan kepada Anda bagaimana pertanyaan keamanan diterapkan di PayPal dan, khususnya, seberapa besar upaya yang dilakukan situs untuk mengidentifikasi. Di atas kami melihat halaman untuk memulai proses (dengan CAPTCHA), tetapi di sini kami menunjukkan apa yang terjadi setelah Anda memasukkan alamat email dan menyelesaikan CAPTCHA:
Akibatnya, pengguna menerima surat berikut:
Meskipun ini normal, inilah yang ada di balik URL reset ini:
Jadi, pertanyaan rahasia ikut bermain. Faktanya, PayPal juga memungkinkan Anda untuk mengatur ulang kata sandi dengan memverifikasi nomor kartu kredit Anda, jadi ada saluran tambahan yang tidak dapat diakses oleh banyak situs. Saya tidak bisa mengubah kata sandi saya tanpa menjawab kedua pertanyaan keamanan (atau mengetahui nomor kartu). Bahkan jika seseorang mengambil email saya, mereka tidak akan dapat mengatur ulang kata sandi akun PayPal saya jika mereka tidak mengetahui lebih banyak informasi pribadi tentang saya. Informasi apa? Berikut adalah opsi pertanyaan keamanan yang ditawarkan oleh PayPal:
Pertanyaan sekolah dan rumah sakit mungkin sedikit meragukan dalam hal kemudahan pencarian, tetapi sisanya tidak terlalu buruk. Namun, untuk meningkatkan keamanan, PayPal memerlukan identifikasi tambahan untuk mengubah jawaban keamanan:
PayPal adalah contoh yang cukup utopis dari penyetelan ulang kata sandi yang aman: PayPal menerapkan CAPTCHA untuk mengurangi risiko kekerasan, memerlukan dua pertanyaan rahasia, dan kemudian memerlukan jenis identifikasi lain yang sama sekali berbeda hanya untuk mengubah jawaban - dan ini dilakukan setelah pengguna masuk. Ini tentu saja yang kami harapkan dari PayPal; itu adalah lembaga keuangan yang berurusan dengan uang dalam jumlah besar. Ini tidak berarti bahwa setiap pengaturan ulang kata sandi harus mengikuti langkah-langkah ini - dalam banyak kasus itu berlebihan - tetapi ini adalah contoh yang baik ketika keamanan adalah urusan yang serius.
Kenyamanan sistem pertanyaan rahasia adalah jika Anda tidak segera mengimplementasikannya, maka dapat ditambahkan nanti jika tingkat perlindungan sumber daya memerlukannya. Contoh bagusnya adalah Apple, yang baru-baru ini menerapkan mekanisme ini [ditulis pada 2012] . Setelah saya mulai memperbarui aplikasi di iPad, saya melihat permintaan berikut:
Kemudian saya melihat layar tempat saya dapat memilih beberapa pasang pertanyaan dan jawaban rahasia, serta alamat email penyelamatan:
Sedangkan untuk PayPal, pertanyaannya telah dipilih sebelumnya dan beberapa di antaranya sebenarnya cukup bagus:
Masing-masing dari tiga pasang pertanyaan dan jawaban mewakili serangkaian kemungkinan pertanyaan terpisah, jadi ada banyak cara untuk mengonfigurasi akun.
Aspek lain yang perlu dipertimbangkan mengenai jawaban pertanyaan keamanan adalah penyimpanan. Menemukan teks biasa di DB menimbulkan ancaman yang hampir sama seperti dalam kasus kata sandi, yaitu, mengungkapkan database secara instan mengungkapkan artinya dan menempatkan risiko tidak hanya aplikasi, tetapi juga aplikasi yang berpotensi sama sekali berbeda menggunakan pertanyaan keamanan yang sama (ini lagi-lagi pertanyaan tentang beri acai). Salah satu opsinya adalah hashing yang aman (algoritme yang kuat dan salt yang acak secara kriptografik), tetapi tidak seperti kebanyakan kasus penyimpanan kata sandi, mungkin ada alasan yang baik agar respons tersebut muncul sebagai teks biasa. Skenario tipikal adalah verifikasi identitas oleh operator langsung melalui telepon. Tentu saja, dalam kasus ini, hashing juga berlaku (operator dapat dengan mudah memasukkan respons yang disebutkan oleh klien), tetapi dalam kasus terburuk, jawaban rahasia harus berada di beberapa tingkat penyimpanan kriptografi, meskipun itu hanya enkripsi simetris. Untuk meringkas: perlakukan rahasia sebagai rahasia!
Dan aspek terakhir dari pertanyaan dan jawaban rahasia - mereka lebih rentan terhadap manipulasi psikologis. Mencoba mendapatkan kata sandi untuk akun orang lain secara langsung adalah satu hal, tetapi memulai percakapan tentang pendidikannya (pertanyaan rahasia populer) sama sekali berbeda. Nyatanya, Anda dapat berkomunikasi secara realistis dengan seseorang tentang banyak aspek kehidupan mereka yang mungkin merupakan pertanyaan keamanan, tanpa menimbulkan kecurigaan. Tentu saja, inti dari pertanyaan rahasia adalah bahwa ini terkait dengan pengalaman hidup seseorang, jadi itu diingat, dan inilah masalahnya - orang suka berbicara tentang pengalaman hidup mereka! Tidak banyak yang dapat dilakukan untuk mengatasinya, hanya dengan memilih opsi pertanyaan keamanan sehingga kecil kemungkinannya untuk ditarik keluar oleh manipulasi psikologis.
[Bersambung.]
Periklanan
VDSina menawarkan server yang andal dengan pembayaran harian , setiap server terhubung ke saluran Internet 500 megabit dan dilindungi dari serangan DDoS secara gratis!
