Saya baru-baru ini mempunyai masa untuk berfikir semula tentang cara ciri tetapan semula kata laluan yang selamat harus berfungsi, pertama apabila saya membina fungsi ini , dan kemudian apabila dia membantu orang lain melakukan sesuatu yang serupa. Dalam kes kedua, saya ingin memberinya pautan ke sumber kanonik dengan semua butiran tentang cara melaksanakan fungsi tetapan semula dengan selamat. Walau bagaimanapun, masalahnya ialah sumber sedemikian tidak wujud, sekurang-kurangnya tidak satu pun yang menerangkan segala-galanya yang kelihatan penting kepada saya. Jadi saya memutuskan untuk menulisnya sendiri.
Anda lihat, dunia kata laluan yang terlupa sebenarnya agak misteri. Terdapat banyak sudut pandangan yang berbeza, boleh diterima dengan sempurna dan banyak yang agak berbahaya. Berkemungkinan anda telah menemui setiap daripada mereka berkali-kali sebagai pengguna akhir; jadi saya akan cuba menggunakan contoh ini untuk menunjukkan siapa yang melakukannya dengan betul dan siapa yang tidak, dan perkara yang perlu anda fokuskan untuk melaksanakan ciri dengan betul dalam aplikasi anda.
Penyimpanan kata laluan: pencincangan, penyulitan dan (tergap!) teks biasa
Kami tidak boleh membincangkan perkara yang perlu dilakukan dengan kata laluan yang terlupa sebelum kami membincangkan cara ia disimpan. Kata laluan disimpan dalam pangkalan data dalam salah satu daripada tiga jenis utama:
- Teks kosong. Terdapat lajur dengan kata laluan, yang disimpan dalam teks biasa.
- disulitkan. Biasanya menggunakan penyulitan simetri (satu kunci digunakan untuk kedua-dua penyulitan dan penyahsulitan), dan kata laluan yang disulitkan juga disimpan dalam lajur yang sama.
- dicincang. Proses sehala (kata laluan boleh dicincang tetapi tidak dicincang); kata laluan, Saya ingin berharap, diikuti dengan garam, dan setiap satu berada dalam lajurnya sendiri.
Mari kita terus kepada soalan paling mudah: jangan sekali-kali menyimpan kata laluan dalam teks biasa! tidak pernah. Satu kelemahan tunggal , satu sandaran yang cuai, atau satu daripada berpuluh-puluh kesilapan mudah lain - dan itu sahaja, gameover, semua kata laluan anda - iaitu, maaf, kata laluan semua pelanggan anda akan menjadi domain awam. Sudah tentu, ini bermakna kemungkinan besar itu daripada semua akaun mereka dalam sistem lain. Dan ia akan menjadi kesalahan anda.
Penyulitan adalah lebih baik, tetapi mempunyai kelemahannya. Masalah penyulitan adalah dalam penyahsulitan; kita boleh mengambil sifir yang kelihatan gila ini dan menukarnya kembali kepada teks biasa, dan apabila itu berlaku, kita kembali kepada situasi dengan kata laluan yang boleh dibaca. Bagaimana ini berlaku? Cacat kecil berlaku pada kod yang menyahsulit kata laluan, menjadikannya tersedia secara umum - ini adalah satu cara. Akses kepada mesin di mana data yang disulitkan disimpan diperoleh oleh penggodam - ini adalah cara kedua. Satu lagi cara, sekali lagi, adalah untuk mencuri sandaran pangkalan data, dan seseorang juga mendapat kunci penyulitan, yang sering disimpan dengan sangat tidak selamat.
Dan itu membawa kita kepada pencincangan. Idea di sebalik pencincangan ialah ia dilakukan sehala; satu-satunya cara untuk membandingkan kata laluan yang dimasukkan oleh pengguna dengan versi cincangnya ialah dengan mencincang kata laluan yang dimasukkan dan membandingkannya. Untuk mengelakkan serangan menggunakan alat seperti jadual pelangi, kami menggunakan garam untuk menambah rawak pada proses (untuk gambar penuh, baca saya mengenai storan kriptografi). Akhirnya, jika dilaksanakan dengan betul, kita boleh menganggap bahawa kata laluan cincang tidak akan menjadi teks biasa lagi (saya akan membincangkan faedah algoritma pencincangan yang berbeza dalam siaran lain).
Hujah pantas tentang pencincangan dan penyulitan: Satu-satunya sebab anda perlu menyulitkan daripada mencincang kata laluan adalah apabila anda perlu melihat kata laluan dalam teks biasa dan bukannya anda tidak sepatutnya menginginkannya, sekurang-kurangnya dalam situasi laman web standard. Jika anda memerlukan ini, kemungkinan besar anda melakukan sesuatu yang salah!
Amaran!
Di bawah teks siaran itu terdapat sebahagian daripada tangkapan skrin laman web lucah AlotPorn. Ia dipangkas dengan kemas supaya tiada apa-apa yang anda tidak dapat lihat di pantai, tetapi jika ia masih mungkin menyebabkan sebarang masalah, jangan tatal ke bawah.
Sentiasa tetapkan semula kata laluan anda tidak pernah jangan ingatkan dia
Pernahkah anda diminta untuk mencipta fungsi peringatan kata laluan? Ambil langkah ke belakang dan fikirkan permintaan ini secara terbalik: mengapa "peringatan" ini diperlukan? Kerana pengguna terlupa kata laluan. Apa yang kita nak buat sebenarnya? Bantu dia log masuk semula.
Saya sedar perkataan "peringatan" digunakan (selalunya) dalam erti kata sehari-hari, tetapi apa yang sebenarnya kita cuba lakukan ialah selamat membantu pengguna untuk berada dalam talian semula. Memandangkan kami memerlukan keselamatan, terdapat dua sebab mengapa peringatan (iaitu menghantar kepada pengguna kata laluan mereka) tidak sesuai:
- E-mel ialah saluran yang tidak selamat. Sama seperti kami tidak akan menghantar apa-apa yang sulit melalui HTTP (kami akan menggunakan HTTPS), kami tidak seharusnya menghantar apa-apa melalui e-mel kerana lapisan pengangkutannya tidak selamat. Malah, ini lebih teruk daripada hanya menghantar maklumat melalui protokol pengangkutan yang tidak selamat, kerana mel sering disimpan pada pemacu, tersedia kepada pentadbir sistem, dimajukan dan diedarkan, tersedia untuk perisian hasad dan sebagainya. E-mel yang tidak disulitkan ialah saluran yang sangat tidak selamat.
- Anda sepatutnya tidak mempunyai akses kepada kata laluan pula. Baca semula bahagian sebelumnya tentang storan - anda mesti mempunyai cincang kata laluan (dengan garam kuat yang baik), bermakna tidak mungkin anda boleh mengekstrak kata laluan dan menghantarnya.
Biar saya tunjukkan masalah dengan contoh : Berikut ialah halaman log masuk biasa:
Jelas sekali masalah pertama ialah halaman log masuk tidak dimuatkan melalui HTTPS, tetapi tapak itu juga menawarkan untuk menghantar kata laluan ("Hantar Kata Laluan"). Mungkin ini adalah contoh penggunaan bahasa sehari-hari bagi istilah yang disebutkan di atas, jadi mari kita melangkah lebih jauh dan lihat apa yang berlaku:
Ia tidak kelihatan lebih baik, malangnya; dan e-mel mengesahkan terdapat masalah:
Ini memberitahu kami tentang dua aspek penting usoutdoor.com:
- Tapak ini tidak mencincang kata laluan. Paling baik, ia disulitkan, tetapi kemungkinan besar ia disimpan dalam teks biasa; Kami tidak melihat bukti sebaliknya.
- Tapak ini menghantar kata laluan jangka panjang (kita boleh kembali dan menggunakannya berulang kali) melalui saluran yang tidak selamat.
Dengan itu, kita perlu menyemak sama ada proses tetapan semula berjalan dengan cara yang selamat. Langkah pertama untuk melakukan ini adalah untuk memastikan bahawa peminta mempunyai hak untuk melakukan penetapan semula. Dalam erti kata lain, sebelum itu kita memerlukan semakan identiti; Mari kita lihat apa yang berlaku apabila identiti disahkan tanpa terlebih dahulu mengesahkan bahawa peminta sememangnya pemilik akaun tersebut.
Penghitungan nama pengguna dan kesannya terhadap ketaknamaan
Masalah ini paling baik digambarkan secara visual. Masalah:
Nampak? Beri perhatian kepada mesej "Tiada pengguna berdaftar dengan alamat e-mel ini". Masalahnya jelas timbul jika tapak yang serupa mengesahkan ketersediaan berdaftar dengan alamat e-mel pengguna sedemikian. Bingo - anda baru sahaja menemui fetish lucah suami/bos/jiran anda!
Sudah tentu, lucah ialah contoh yang agak ikonik tentang kepentingan privasi, tetapi bahaya mengaitkan identiti dengan tapak web tertentu adalah lebih luas daripada situasi yang mungkin janggal yang diterangkan di atas. Satu bahaya ialah kejuruteraan sosial; Jika penyerang boleh memadankan seseorang dengan perkhidmatan itu, maka dia akan mempunyai maklumat yang boleh dia mula gunakan. Sebagai contoh, dia boleh menghubungi seseorang yang menyamar sebagai wakil tapak web dan meminta maklumat tambahan dalam usaha untuk melakukan .
Amalan sedemikian juga meningkatkan bahaya "penghitungan nama pengguna," di mana seseorang boleh mengesahkan kewujudan keseluruhan koleksi nama pengguna atau alamat e-mel di tapak web dengan hanya menjalankan pertanyaan kumpulan dan memeriksa respons kepada mereka. Adakah anda mempunyai senarai alamat e-mel semua pekerja dan beberapa minit untuk menulis skrip? Kemudian anda lihat apa masalahnya!
Apakah alternatifnya? Malah, ia agak mudah, dan dilaksanakan dengan hebat :
Di sini, Entropay tidak mendedahkan apa-apa tentang kewujudan alamat e-mel dalam sistemnya. kepada seseorang yang tidak memiliki alamat ini... Jika awak sendiri alamat ini dan ia tidak wujud dalam sistem, maka anda akan menerima e-mel seperti ini:
Sudah tentu, mungkin terdapat situasi yang boleh diterima di mana seseorang berfikiryang didaftarkan di laman web. tetapi ini tidak berlaku, atau melakukannya dari alamat mel yang berbeza. Contoh di atas berjaya mengendalikan kedua-dua situasi. Jelas sekali, jika alamat sepadan, maka anda akan menerima e-mel yang memudahkan anda menetapkan semula kata laluan anda.
Kehalusan penyelesaian yang dipilih oleh Entropay ialah pengesahan pengenalan dilakukan oleh e-mel sebelum sebarang pengesahan dalam talian. Sesetengah tapak meminta jawapan kepada soalan keselamatan kepada pengguna (lebih lanjut mengenai perkara ini di bawah) kepada bagaimana penetapan semula boleh bermula; namun, masalah dengan ini ialah anda perlu menjawab soalan sambil menyediakan beberapa bentuk pengenalan (e-mel atau nama pengguna), yang menjadikannya mustahil untuk menjawab secara intuitif tanpa mendedahkan kewujudan akaun pengguna tanpa nama.
Dengan pendekatan ini ada kecil kebolehgunaan berkurangan kerana jika anda cuba menetapkan semula akaun yang tidak wujud, tiada maklum balas segera. Sudah tentu, itulah tujuan utama menghantar e-mel, tetapi dari perspektif pengguna akhir yang sebenar, jika mereka memasukkan alamat yang salah, mereka hanya akan tahu buat kali pertama apabila mereka menerima e-mel. Ini mungkin menyebabkan sedikit ketegangan di pihaknya, tetapi ini adalah harga yang kecil untuk dibayar untuk proses yang jarang berlaku.
Nota lain, sedikit di luar topik: fungsi bantuan log masuk yang mendedahkan sama ada nama pengguna atau alamat e-mel adalah betul mempunyai masalah yang sama. Sentiasa balas kepada pengguna dengan mesej "Kombinasi nama pengguna dan kata laluan anda tidak sah" dan bukannya mengesahkan kewujudan bukti kelayakan secara jelas (contohnya, "nama pengguna adalah betul, tetapi kata laluan tidak betul").
Menghantar Kata Laluan Tetapan Semula vs Menghantar URL Tetapan Semula
Konsep seterusnya yang perlu kita bincangkan adalah berkaitan dengan kaedah set semula kata laluan. Terdapat dua penyelesaian popular:
- Menjana kata laluan baharu pada pelayan dan menghantarnya melalui e-mel
- Hantar e-mel dengan URL unik untuk memudahkan proses penetapan semula
Walaupun , titik pertama tidak boleh digunakan. Masalahnya ialah ia bermakna mempunyai kata laluan yang disimpan, yang anda boleh kembali dan gunakan semula pada bila-bila masa; ia telah dihantar melalui saluran yang tidak selamat dan kekal dalam peti masuk anda. Kemungkinan peti masuk disegerakkan merentas peranti mudah alih dan klien e-mel, serta peti masuk itu mungkin disimpan dalam talian dalam perkhidmatan e-mel web untuk masa yang sangat lama. Intinya ialah peti mel tidak boleh dianggap sebagai alat yang boleh dipercayai untuk penyimpanan jangka panjang.
Tetapi selain ini, perenggan pertama mempunyai satu lagi masalah serius - ia dipermudahkan sebaik mungkin menyekat akaun dengan niat jahat. Jika saya tahu alamat e-mel seseorang yang memiliki akaun di tapak web, maka saya boleh menyekat mereka pada bila-bila masa dengan hanya menetapkan semula kata laluan mereka; Ini adalah serangan penafian perkhidmatan yang dihidangkan di atas pinggan perak! Inilah sebabnya mengapa tetapan semula hanya perlu dilakukan selepas berjaya mengesahkan hak peminta ke atasnya.
Apabila kita bercakap tentang penetapan semula URL, kami maksudkan alamat tapak web itu unik untuk kes tertentu proses penetapan semula ini. Sudah tentu, ia harus rawak, ia tidak sepatutnya mudah diteka dan ia tidak sepatutnya mengandungi sebarang pautan luaran ke akaun yang memudahkan untuk menetapkan semula. Sebagai contoh, URL tetapan semula tidak sepatutnya menjadi laluan seperti "Reset/?username=JohnSmith".
Kami ingin mencipta token unik yang boleh dihantar sebagai URL tetapan semula dan kemudian dipadankan dengan rekod pelayan akaun pengguna, sekali gus mengesahkan bahawa pemilik akaun sememangnya orang yang sama yang cuba menetapkan semula kata laluan. . Sebagai contoh, token mungkin kelihatan seperti "3ce7854015cd38c862cb9e14a1ae552b" dan disimpan dalam jadual bersama-sama dengan penetapan semula ID pengguna dan masa penjanaan token (lebih lanjut mengenainya sebentar lagi). Apabila e-mel dihantar, ia mengandungi URL seperti "Reset/?id=3ce7854015cd38c862cb9e14a1ae552b", dan apabila pengguna memuatkannya, halaman tersebut meminta kewujudan token, kemudian mengesahkan maklumat pengguna dan membenarkan kata laluan ditukar.
Sudah tentu, memandangkan proses di atas (mudah-mudahan) membolehkan pengguna mencipta kata laluan baharu, kami perlu memastikan bahawa URL dimuatkan melalui HTTPS. tidak, , URL token ini mesti menggunakan keselamatan lapisan pengangkutan supaya borang kata laluan baharu tidak boleh diserang dan kata laluan yang dibuat oleh pengguna telah dihantar melalui sambungan selamat.
Juga untuk URL penetapan semula anda perlu menambah had masa token supaya proses penetapan semula dapat diselesaikan dalam selang waktu tertentu, katakan dalam masa sejam. Ini memastikan bahawa tetingkap masa set semula dikekalkan pada tahap minimum supaya penerima URL tetapan semula hanya boleh bertindak dalam tetingkap yang sangat kecil itu. Sudah tentu, penyerang boleh memulakan proses tetapan semula, tetapi mereka perlu mendapatkan URL tetapan semula unik yang lain.
Akhir sekali, kita perlu memastikan bahawa proses ini boleh guna. Setelah proses tetapan semula selesai, token mesti dialih keluar supaya URL tetapan semula tidak lagi sah. Titik sebelumnya diperlukan supaya penyerang mempunyai tetingkap yang sangat kecil di mana dia boleh memanipulasi URL tetapan semula. Selain itu, sudah tentu, selepas berjaya menyelesaikan tetapan semula, token tidak lagi diperlukan.
Beberapa langkah ini mungkin kelihatan berlebihan, tetapi ia tidak mengganggu kebolehgunaan dan sebenarnya meningkatkan keselamatan, walaupun dalam situasi yang kami harap jarang berlaku. Dalam 99% kes, pengguna akan mendayakan tetapan semula dalam tempoh masa yang sangat singkat dan tidak akan menetapkan semula kata laluan sekali lagi dalam masa terdekat.
Peranan CAPTCHA
Oh, CAPTCHA, langkah keselamatan yang kita semua suka benci! Sebenarnya, CAPTCHA bukanlah satu cara perlindungan seperti pengenalan - anda adalah seseorang atau robot (atau skrip automatik). Tujuannya adalah untuk mengelakkan penyerahan borang automatik, yang, sudah tentu, boleh digunakan sebagai percubaan untuk memecahkan perlindungan. Dalam konteks menetapkan semula kata laluan, CAPTCHA bermakna fungsi tetapan semula tidak boleh dipaksa sama ada untuk menghantar spam kepada pengguna atau cuba menentukan kewujudan akaun (yang, sudah tentu, tidak akan dapat dilakukan jika anda mengikuti petua dalam bahagian mengenai pengesahan identiti).
Sudah tentu, CAPTCHA sendiri tidak sempurna; terdapat banyak preseden untuk ia "digodam" secara program dan mencapai kadar kejayaan yang mencukupi (60-70%). Juga, terdapat penyelesaian yang ditunjukkan dalam siaran saya tentang , di mana anda boleh membayar orang pecahan sen untuk menyelesaikan setiap CAPTCHA dan mencapai kadar kejayaan 94%. Iaitu, ia terdedah, tetapi ia (sedikit) meningkatkan halangan untuk masuk.
Mari kita lihat contoh PayPal:
Dalam kes ini, proses tetapan semula tidak boleh bermula sehingga CAPTCHA diselesaikan, jadi secara teorinya adalah mustahil untuk mengautomasikan proses. Secara teori.
Walau bagaimanapun, untuk kebanyakan aplikasi web ini akan menjadi berlebihan dan betul sekali mewakili penurunan dalam kebolehgunaan - orang hanya tidak suka CAPTCHA! Selain itu, CAPTCHA ialah sesuatu yang anda boleh kembali dengan mudah jika perlu. Jika perkhidmatan mula diserang (di sinilah pembalakan berguna, tetapi lebih lanjut mengenainya kemudian), maka menambah CAPTCHA tidak boleh menjadi lebih mudah.
Soalan dan Jawapan Rahsia
Dengan semua kaedah yang kami lihat, kami dapat menetapkan semula kata laluan, hanya dengan mempunyai akses kepada akaun e-mel. Saya katakan "hanya", tetapi sudah tentu, secara haram mendapat akses ke akaun mel orang lain sepatutnya menjadi satu proses yang kompleks. Namun begitu .
Malah, pautan di atas mengenai penggodaman Yahoo! Sarah Palin! mempunyai dua tujuan; pertama, ia menggambarkan betapa mudahnya untuk menggodam (beberapa) akaun e-mel, dan kedua, ia menunjukkan bagaimana soalan keselamatan yang buruk boleh digunakan dengan niat jahat. Tetapi kita akan kembali kepada perkara ini kemudian.
Masalah dengan menetapkan semula kata laluan yang XNUMX% bergantung kepada e-mel ialah integriti akaun tapak yang anda cuba tetapkan semula menjadi XNUMX% bergantung pada integriti akaun e-mel. Sesiapa sahaja yang mempunyai akses kepada e-mel anda mempunyai akses kepada mana-mana akaun yang boleh ditetapkan semula dengan hanya menerima e-mel. Untuk akaun sedemikian, e-mel ialah "kunci kepada semua pintu" kehidupan dalam talian anda.
Satu cara untuk mengurangkan risiko ini adalah dengan melaksanakan corak soalan dan jawapan keselamatan. Tidak syak lagi anda telah melihatnya: pilih soalan yang hanya anda mempunyai tahu jawapannya, dan kemudian apabila anda menetapkan semula kata laluan anda, anda akan diminta untuknya. Ini menambah keyakinan bahawa orang yang cuba menetapkan semula sememangnya pemilik akaun.
Kembali kepada Sarah Palin: kesilapannya ialah jawapan kepada soalan/soalan keselamatannya boleh didapati dengan mudah. Terutama apabila anda seorang tokoh masyarakat yang begitu penting, maklumat tentang nama sulung ibu anda, sejarah pendidikan atau tempat tinggal seseorang pada masa lalu bukanlah rahsia. Malah, kebanyakannya boleh didapati oleh hampir semua orang. Inilah yang berlaku kepada Sarah:
Penggodam David Kernell mendapat akses ke akaun Palin dengan mencari butiran latar belakangnya, seperti sekolah menengah dan tarikh lahirnya, dan kemudian menggunakan ciri pemulihan kata laluan akaun Yahoo! yang hilang.
Pertama sekali, ini adalah ralat reka bentuk di pihak Yahoo! β dengan menyatakan soalan mudah sedemikian, syarikat itu pada dasarnya mensabotaj nilai soalan keselamatan, dan oleh itu perlindungan sistemnya. Sudah tentu, menetapkan semula kata laluan untuk akaun e-mel sentiasa lebih sukar kerana anda tidak dapat membuktikan pemilikan dengan menghantar e-mel kepada pemilik (tanpa mempunyai alamat kedua), tetapi mujurlah tidak banyak kegunaan untuk mencipta sistem sedemikian hari ini.
Mari kembali kepada soalan keselamatan - terdapat pilihan untuk membolehkan pengguna membuat soalan mereka sendiri. Masalahnya ialah ini akan menghasilkan soalan yang sangat jelas:
Apakah warna langit?
Soalan yang meletakkan orang dalam kedudukan yang tidak selesa apabila soalan keselamatan menggunakan soalan rahsia untuk mengenal pasti orang (contohnya, dalam pusat panggilan):
Dengan siapa saya tidur pada Krismas?
Atau soalan bodoh terus terang:
Bagaimana anda mengeja "kata laluan"?
Apabila ia datang kepada soalan keselamatan, pengguna perlu diselamatkan daripada diri mereka sendiri! Dalam erti kata lain, soalan keselamatan harus ditentukan oleh tapak itu sendiri, atau lebih baik lagi, ditanya seri soalan keselamatan yang boleh dipilih oleh pengguna. Dan jangan hanya memilih 1; sebaik-baiknya pengguna harus memilih dua atau lebih soalan keselamatan pada masa pendaftaran akaun, yang kemudiannya akan digunakan sebagai saluran pengenalan kedua. Mempunyai berbilang soalan meningkatkan tahap keyakinan dalam proses pengesahan, serta membenarkan rawak (tidak selalu menunjukkan soalan yang sama), serta memberikan sedikit redundansi sekiranya pengguna sebenar terlupa kata laluan.
Apakah soalan keselamatan yang baik? Ini dipengaruhi oleh beberapa faktor:
- Ia harus ringkas Soalan hendaklah jelas dan jelas.
- Jawapannya mestilah khusus β kita tidak memerlukan soalan yang boleh dijawab oleh seseorang dengan cara yang berbeza
- Jawapan yang mungkin sepatutnya pelbagai - bertanya warna kegemaran seseorang menghasilkan subset yang sangat kecil kemungkinan jawapan
- carian jawapannya mestilah kompleks - jika jawapannya mudah didapati mana-mana (ingat orang yang berjawatan tinggi), maka buruklah dia
- Jawapannya mestilah kekal dalam masa - jika anda bertanya filem kegemaran seseorang, maka setahun kemudian jawapannya mungkin berbeza
Seperti yang berlaku, terdapat laman web khusus untuk bertanya soalan yang baik dipanggil . Sesetengah soalan kelihatan agak bagus, yang lain tidak lulus beberapa ujian yang diterangkan di atas, terutamanya ujian "kemudahan carian".
Izinkan saya menunjukkan kepada anda cara soalan keselamatan dilaksanakan dalam PayPal dan, khususnya, berapa banyak usaha yang dilakukan tapak untuk mengenal pasti. Kami melihat halaman permulaan proses (dengan CAPTCHA) di atas, dan di sini kami menunjukkan perkara yang berlaku selepas anda memasukkan alamat e-mel anda dan menyelesaikan CAPTCHA:
Akibatnya, pengguna menerima e-mel berikut:
Setakat ini perkara biasa, tetapi inilah perkara di sebalik penetapan semula URL ini:
Jadi, persoalan keselamatan mula dimainkan. Malah, PayPal juga membenarkan anda menetapkan semula kata laluan anda dengan mengesahkan nombor kad kredit anda, jadi terdapat saluran tambahan yang banyak tapak tidak mempunyai akses. Saya tidak boleh menukar kata laluan saya tanpa menjawab kedua-duanya soalan keselamatan (atau tidak mengetahui nombor kad). Walaupun seseorang merampas e-mel saya, mereka tidak akan dapat menetapkan semula kata laluan akaun PayPal saya melainkan mereka mengetahui lebih sedikit maklumat peribadi tentang saya. Maklumat apa? Berikut ialah pilihan soalan keselamatan yang ditawarkan PayPal:
Soalan sekolah dan hospital mungkin agak sukar dari segi kemudahan pencarian, tetapi yang lain tidak terlalu teruk. Walau bagaimanapun, untuk meningkatkan keselamatan, PayPal memerlukan pengenalan tambahan untuk perubahan jawapan kepada soalan keselamatan:
PayPal ialah contoh yang agak utopia bagi tetapan semula kata laluan yang selamat: ia melaksanakan CAPTCHA untuk mengurangkan risiko kekerasan, memerlukan dua soalan keselamatan, dan kemudian memerlukan satu lagi jenis identiti yang berbeza sama sekali hanya untuk menukar jawapan - dan itu selepas pengguna telah melog masuk. Sudah tentu, ini adalah apa yang kita dijangka akan daripada PayPal; ia adalah institusi kewangan yang berurusan dengan jumlah wang yang besar. Ini tidak bermakna bahawa setiap penetapan semula kata laluan perlu mengikut langkah-langkah ini - ia berlebihan dalam kebanyakan kes - tetapi ini adalah contoh yang baik untuk kes di mana keselamatan adalah perniagaan yang serius.
Kemudahan sistem soalan keselamatan ialah jika anda tidak melaksanakannya dengan segera, anda boleh menambahkannya kemudian jika tahap perlindungan sumber memerlukannya. Satu contoh yang baik ialah Apple, yang baru-baru ini melaksanakan mekanisme ini [artikel ditulis pada 2012]. Sebaik sahaja saya mula mengemas kini aplikasi pada iPad, saya melihat permintaan berikut:
Kemudian saya melihat skrin di mana saya boleh memilih beberapa pasang soalan dan jawapan keselamatan, serta alamat e-mel penyelamat:
Bagi PayPal, soalan telah dipilih terlebih dahulu dan beberapa daripadanya sebenarnya cukup bagus:
Setiap satu daripada tiga pasang soalan dan jawapan mewakili set soalan yang mungkin berbeza, jadi terdapat banyak cara untuk mengkonfigurasi akaun.
Satu lagi aspek yang perlu dipertimbangkan mengenai menjawab soalan keselamatan anda ialah storan. Mempunyai pangkalan data teks biasa dalam pangkalan data menimbulkan ancaman yang hampir sama seperti kata laluan, iaitu mendedahkan pangkalan data serta-merta mendedahkan nilai dan meletakkan aplikasi bukan sahaja berisiko, tetapi aplikasi yang berpotensi sama sekali berbeza menggunakan soalan keselamatan yang sama (di sana sekali lagi ). Satu pilihan ialah pencincangan selamat (algoritma yang kuat dan garam rawak secara kriptografi), tetapi tidak seperti kebanyakan kes penyimpanan kata laluan, mungkin terdapat sebab yang baik untuk respons muncul sebagai teks biasa. Senario biasa ialah pengesahan identiti oleh pengendali telefon secara langsung. Sudah tentu, pencincangan juga boleh digunakan dalam kes ini (pengendali hanya boleh memasukkan jawapan yang dinamakan oleh pelanggan), tetapi dalam kes yang paling teruk, jawapan rahsia mestilah pada beberapa tahap storan kriptografi, walaupun ia hanya penyulitan simetri. ringkaskan: layan rahsia seperti rahsia!
Satu aspek terakhir soalan dan jawapan keselamatan ialah mereka lebih terdedah kepada kejuruteraan sosial. Cuba untuk mengekstrak terus kata laluan ke akaun orang lain adalah satu perkara, tetapi memulakan perbualan tentang pembentukannya (soalan keselamatan yang popular) adalah berbeza sama sekali. Malah, anda boleh berkomunikasi dengan baik dengan seseorang tentang banyak aspek kehidupan mereka yang mungkin menimbulkan persoalan rahsia tanpa menimbulkan syak wasangka. Sudah tentu, pokok persoalan keselamatan ialah ia berkaitan dengan pengalaman hidup seseorang, jadi ia tidak dapat dilupakan, dan di situlah masalahnya - orang suka bercakap tentang pengalaman hidup mereka! Terdapat sedikit yang boleh anda lakukan tentang perkara ini, hanya jika anda memilih pilihan soalan keselamatan sedemikian supaya ianya lebih rendah mungkin boleh ditarik keluar oleh kejuruteraan sosial.
[Akan bersambung.]Sebagai iklan
VDSina menawarkan boleh dipercayai , setiap pelayan disambungkan ke saluran Internet 500 Mbps dan dilindungi daripada serangan DDoS secara percuma!
Sumber: www.habr.com