Pertanyaan Bagaimana seharusnya saya secara etis mendekati penyimpanan kata sandi pengguna untuk pencarian plaintext kemudian?


Saat saya terus membangun semakin banyak situs web dan aplikasi web, saya sering diminta untuk menyimpan kata sandi pengguna dengan cara yang dapat diambil jika / ketika pengguna memiliki masalah (baik untuk mengirim email ke tautan kata sandi yang terlupakan, menuntunnya melalui telepon, dll. Ketika saya dapat bertempur dengan pahit terhadap praktik ini dan saya melakukan banyak program 'ekstra' untuk membuat pengaturan ulang kata sandi dan bantuan administratif tanpa menyimpan kata sandi mereka yang sebenarnya.

Ketika saya tidak bisa melawannya (atau tidak bisa menang) maka saya selalu menyandikan kata sandi dengan cara tertentu sehingga setidaknya, tidak disimpan sebagai plaintext dalam database - meskipun saya sadar bahwa jika DB saya diretas itu tidak akan memakan banyak bagi pelakunya untuk memecahkan kata sandi, jadi itu membuatku tidak nyaman.

Di dunia yang sempurna, orang-orang akan sering memperbarui kata sandi dan tidak menggandakannya di banyak situs yang berbeda — sayangnya saya tahu banyak orang yang memiliki kata kerja / rumah / email / kata sandi bank yang sama, dan bahkan secara bebas memberikannya kepada saya ketika mereka membutuhkan bantuan. Saya tidak ingin menjadi orang yang bertanggung jawab atas kehancuran finansial mereka jika prosedur keamanan DB saya gagal karena suatu alasan.

Secara moral dan etis saya merasa bertanggung jawab untuk melindungi apa yang dapat, bagi sebagian pengguna, mata pencaharian mereka bahkan jika mereka memperlakukannya dengan sangat kurang hormat. Saya yakin bahwa ada banyak jalan untuk didekati dan argumen yang harus dibuat untuk hash penggaraman dan opsi penyandiaksaraan yang berbeda, tetapi apakah ada satu 'praktik terbaik' ketika Anda harus menyimpannya? Dalam hampir semua kasus saya menggunakan PHP dan MySQL jika itu membuat perbedaan dalam cara saya harus menangani secara spesifik.

Informasi Tambahan untuk Bounty

Saya ingin mengklarifikasi bahwa saya tahu ini bukan sesuatu yang ingin Anda lakukan dan dalam banyak kasus penolakan untuk melakukannya adalah yang terbaik. Namun, saya tidak mencari ceramah tentang manfaat mengambil pendekatan ini. Saya mencari langkah-langkah terbaik untuk diambil jika Anda mengambil pendekatan ini.

Dalam catatan di bawah ini saya membuat poin bahwa situs web sebagian besar ditujukan untuk orang tua, cacat mental, atau sangat muda dapat membingungkan bagi orang ketika mereka diminta untuk melakukan rutinitas pemulihan kata sandi yang aman. Meskipun kami mungkin menganggapnya sederhana dan biasa dalam beberapa kasus, beberapa pengguna memerlukan bantuan tambahan baik dengan memiliki teknologi layanan untuk membantu mereka masuk ke sistem atau mengirimkannya melalui email / ditampilkan langsung kepada mereka.

Dalam sistem semacam itu, tingkat erosi dari demografi ini dapat membuat aplikasi tidak berfungsi jika pengguna tidak diberikan tingkat bantuan akses ini, jadi harap dijawab dengan pengaturan seperti itu.

Terima kasih untuk semuanya

Ini adalah pertanyaan yang menyenangkan dengan banyak perdebatan dan saya menikmatinya. Pada akhirnya saya memilih jawaban yang mempertahankan keamanan kata sandi (saya tidak perlu menyimpan teks biasa atau kata sandi yang dapat dipulihkan), tetapi juga memungkinkan basis pengguna yang saya tetapkan untuk masuk ke sistem tanpa kekurangan utama yang saya temukan dari pemulihan kata sandi normal.

Seperti biasa ada sekitar 5 jawaban yang saya ingin tandai sebagai benar untuk alasan yang berbeda, tetapi saya harus memilih yang terbaik - semua sisanya mendapat +1. Terimakasih semuanya!

Juga, terima kasih kepada semua orang di komunitas Stack yang memilih pertanyaan ini dan / atau menandainya sebagai favorit. Saya mengambil 100 suara sebagai pujian dan berharap diskusi ini telah membantu orang lain dengan kekhawatiran yang sama seperti saya.


1346
2018-02-17 19:54


asal


Jawaban:


Bagaimana kalau mengambil pendekatan atau sudut lain untuk masalah ini? Tanyakan mengapa kata sandi diperlukan untuk menjadi plaintext: jika itu agar pengguna dapat mengambil kata sandi, maka secara tegas Anda tidak benar-benar perlu untuk mengambil kata sandi yang mereka tetapkan (mereka tidak ingat apa itu), Anda harus bisa memberi mereka kata sandi bisa menggunakan.

Pikirkan tentang itu: jika pengguna perlu mengambil kata sandi, itu karena mereka melupakannya. Dalam hal ini kata sandi baru sama bagusnya dengan kata sandi yang lama. Namun, salah satu kelemahan dari mekanisme pengaturan ulang sandi umum yang digunakan saat ini adalah bahwa kata sandi yang dihasilkan yang dihasilkan dalam operasi pengaturan ulang umumnya merupakan sekelompok karakter acak, sehingga sulit bagi pengguna untuk mengetik dengan benar kecuali jika mereka menyalin-n- pasta. Itu bisa menjadi masalah bagi pengguna komputer yang kurang cerdas.

Salah satu cara mengatasi masalah itu adalah dengan memberikan kata sandi yang dihasilkan secara otomatis yang lebih atau kurang teks bahasa alami. Sementara string bahasa alami mungkin tidak memiliki entropi yang memiliki string karakter acak dengan panjang yang sama, tidak ada yang mengatakan kata sandi Anda yang dihasilkan secara otomatis hanya memiliki 8 (atau 10 atau 12) karakter. Dapatkan frasa sandi yang dibuat otomatis dengan entropi tinggi dengan merangkai beberapa kata acak (sisakan spasi di antara mereka, sehingga mereka masih dapat dikenali dan dapat di-ketik oleh siapa saja yang dapat membaca). Enam kata acak dengan panjang bervariasi mungkin lebih mudah untuk diketik dengan benar dan dengan keyakinan dari 10 karakter acak, dan mereka dapat memiliki entropi yang lebih tinggi juga. Sebagai contoh, entropi dari 10 karakter kata sandi yang diambil secara acak dari huruf besar, huruf kecil, angka dan 10 simbol tanda baca (dengan total 72 simbol yang valid) akan memiliki entropi 61,7 bit. Menggunakan kamus dari 7776 kata (seperti yang Diceware gunakan) yang dapat dipilih secara acak untuk kata kunci enam kata, frasa sandi akan memiliki entropi 77,4 bit. Lihat FAQ Diceware untuk info lebih lanjut.

  • passphrase dengan sekitar 77 bit entropi: "akui prosa flare table akut flair"

  • kata sandi dengan sekitar 74 bit entropi: "K: & $ R ^ tt ~ qkD"

Saya tahu saya lebih suka mengetikkan frasa, dan dengan copy-n-paste, frasa ini tidak kurang mudah untuk menggunakan kata sandi itu, jadi tidak ada kerugian di sana. Tentu saja jika situs web Anda (atau apa pun aset yang dilindungi) tidak memerlukan 77 bit entropi untuk frasa sandi yang dibuat secara otomatis, menghasilkan lebih sedikit kata (yang saya yakin pengguna Anda akan menghargai).

Saya memahami argumen bahwa ada aset yang dilindungi kata sandi yang benar-benar tidak memiliki nilai tinggi, sehingga pelanggaran kata sandi mungkin bukan akhir dari dunia. Sebagai contoh, saya mungkin tidak akan peduli jika 80% dari kata sandi yang saya gunakan di berbagai situs web dilanggar: semua yang dapat terjadi adalah seseorang yang melakukan spam atau posting di bawah nama saya untuk sementara waktu. Itu tidak akan bagus, tapi itu tidak seperti mereka akan membobol rekening bank saya. Namun, mengingat fakta bahwa banyak orang menggunakan kata sandi yang sama untuk situs web forum mereka seperti yang mereka lakukan untuk rekening bank mereka (dan mungkin basis data keamanan nasional), saya pikir akan lebih baik untuk menangani bahkan kata kunci 'nilai rendah' ​​itu sebagai tidak -dipulihkan.


1039
2018-02-28 08:16



Bayangkan seseorang telah menugaskan sebuah gedung besar untuk dibangun - sebuah bar, katakanlah - dan percakapan berikut terjadi:

Arsitek:  Untuk bangunan dengan ukuran dan kapasitas ini, Anda perlu keluar dari sini, di sini, dan di sini.
Klien:  Tidak, itu terlalu rumit dan mahal untuk dirawat, saya tidak ingin ada pintu samping atau pintu belakang.
Arsitek:  Pak, pintu keluar api tidak opsional, mereka diminta sesuai dengan kode kebakaran kota.
Klien:  Saya tidak membayar Anda untuk berdebat. Lakukan saja apa yang saya minta.

Apakah arsitek kemudian bertanya bagaimana membangun gedung ini secara etis tanpa api?

Dalam industri bangunan dan teknik, percakapan kemungkinan besar akan berakhir seperti ini:

Arsitek:  Bangunan ini tidak dapat dibangun tanpa pintu keluar. Anda dapat pergi ke profesional berlisensi lainnya dan dia akan memberi tahu Anda hal yang sama. Saya pergi sekarang; hubungi saya kembali ketika Anda siap untuk bekerja sama.

Pemrograman komputer mungkin bukan a berlisensi profesi, tetapi orang sering tampak bertanya-tanya mengapa profesi kita tidak mendapatkan respek yang sama dengan insinyur sipil atau mekanik - baik, tidak terlihat lagi. Profesi-profesi itu, ketika menyerahkan persyaratan-persyaratan sampah (atau benar-benar berbahaya), hanya akan menolak. Mereka tahu itu bukan alasan untuk mengatakan, "Yah, saya melakukan yang terbaik, tetapi dia bersikeras, dan saya harus melakukan apa yang dia katakan." Mereka bisa kehilangan izin mereka untuk alasan itu.

Saya tidak tahu apakah Anda atau klien Anda adalah bagian dari perusahaan yang diperdagangkan secara publik, tetapi menyimpan kata sandi dalam bentuk apa pun yang dapat dipulihkan akan menyebabkan Anda gagal dalam beberapa jenis audit keamanan. Masalahnya bukan seberapa sulit bagi sebagian "peretas" yang mendapat akses ke basis data Anda untuk memulihkan kata sandi. Sebagian besar ancaman keamanan bersifat internal.  Yang perlu Anda lindungi adalah karyawan yang tidak puas berjalan dengan semua kata sandi dan menjualnya kepada penawar tertinggi. Menggunakan enkripsi asimetris dan menyimpan kunci privat dalam database terpisah tidak dapat mencegah skenario ini; akan selalu ada some one dengan akses ke basis data pribadi, dan itu risiko keamanan yang serius.

Tidak ada cara yang etis atau bertanggung jawab untuk menyimpan kata sandi dalam bentuk yang dapat dipulihkan. Periode.


593
2018-02-18 16:05



Anda bisa mengenkripsi kata sandi + garam dengan kunci publik. Untuk login hanya memeriksa apakah nilai yang disimpan sama dengan nilai yang dihitung dari input pengguna + garam. Jika ada saatnya, ketika kata sandi harus dikembalikan dalam bentuk teks, Anda dapat mendekripsi secara manual atau semi-otomatis dengan kunci privat. Kunci privat dapat disimpan di tempat lain dan dapat dienkripsi secara simetris (yang akan membutuhkan interaksi manusia untuk mendekripsi kata sandi).

Saya pikir ini sebenarnya agak mirip dengan cara Agen Pemulihan Windows bekerja.

  • Kata sandi disimpan terenkripsi
  • Orang dapat masuk tanpa mendekripsi ke plaintext
  • Kata sandi dapat dipulihkan ke plaintext, tetapi hanya dengan kunci pribadi, yang dapat disimpan di luar sistem (dalam brankas bank, jika Anda mau).

206
2018-02-17 20:07



Jangan menyerah. Senjata yang dapat Anda gunakan untuk meyakinkan klien Anda adalah non-repudiability. Jika Anda dapat merekonstruksi kata sandi pengguna melalui mekanisme apa pun, Anda telah memberikannya mereka klien mekanisme non-penolakan hukum dan mereka dapat menolak setiap transaksi yang bergantung pada kata sandi itu, karena tidak ada cara pemasok dapat membuktikan bahwa mereka tidak merekonstruksi kata sandi dan memasukkan transaksi melalui mereka sendiri. Jika kata sandi disimpan dengan benar sebagai pencirian daripada ciphertext, ini tidak mungkin, ergo baik klien akhir melakukan transaksi sendiri atau melanggar tugas perawatannya w.r.t. kata sandinya. Dalam kedua kasus itu, tanggung jawab itu diserahkan kepadanya. Saya telah menangani kasus-kasus yang jumlahnya mencapai ratusan juta dolar. Bukan sesuatu yang ingin Anda salah.


134
2018-02-18 09:59



Anda tidak dapat secara etis menyimpan kata sandi untuk pencarian plaintext kemudian. Sesederhana itu. Bahkan Jon Skeet tidak dapat secara etis menyimpan kata sandi untuk pencarian plaintext kemudian. Jika pengguna Anda dapat mengambil kata sandi dalam teks biasa entah bagaimana caranya, maka berpotensi demikian juga dapat seorang peretas yang menemukan kerentanan keamanan dalam kode Anda. Dan itu bukan hanya satu kata sandi pengguna yang disusupi, tapi mereka semua.

Jika klien Anda memiliki masalah dengan itu, beri tahu mereka bahwa menyimpan kata sandi dapat dipulihkan adalah melanggar hukum. Di sini, di Inggris, Undang-undang Perlindungan Data 1998 (khususnya, Jadwal 1, Bagian II, Ayat 9) mengharuskan pengontrol data untuk menggunakan langkah-langkah teknis yang tepat untuk menjaga keamanan data pribadi, dengan mempertimbangkan, antara lain, bahaya yang mungkin disebabkan jika data disusupi - yang mungkin cukup besar bagi pengguna yang berbagi kata sandi di antara situs. Jika mereka masih kesulitan mengelus fakta bahwa itu masalah, arahkan mereka ke beberapa contoh dunia nyata, seperti yang ini.

Cara termudah untuk memungkinkan pengguna memulihkan login adalah dengan mengirim email kepada mereka satu kali tautan yang secara otomatis memasukkannya dan membawa mereka langsung ke halaman di mana mereka dapat memilih kata sandi baru. Buat prototipe dan tunjukkan dalam aksi kepada mereka.

Berikut adalah beberapa posting blog yang saya tulis tentang masalah ini:

Memperbarui: kita sekarang mulai melihat tuntutan hukum dan penuntutan terhadap perusahaan yang gagal mengamankan kata sandi pengguna mereka dengan benar. Contoh: LinkedIn ditampar dengan gugatan class action senilai $ 5 juta; Sony didenda £ 250.000 melalui peretasan data PlayStation. Jika saya ingat dengan benar, LinkedIn sebenarnya mengenkripsi kata sandi penggunanya, tetapi enkripsi yang digunakannya terlalu lemah untuk menjadi efektif.


95
2018-02-23 15:20



Setelah membaca bagian ini:

Dalam catatan di bawah saya membuat poin itu   situs web sebagian besar diarahkan ke   tua, cacat mental, atau sangat   muda bisa menjadi membingungkan bagi orang-orang   ketika diminta untuk melakukan   pemulihan rutin kata sandi yang aman.   Meskipun kita mungkin menganggapnya sederhana dan   biasa dalam kasus-kasus yang dibutuhkan beberapa pengguna   bantuan tambahan dari memiliki   teknologi layanan membantu mereka masuk ke dalam   sistem atau mengirimkannya melalui email / ditampilkan   langsung kepada mereka.

Dalam sistem semacam itu tingkat erosi   dari demografi ini bisa berjalan pincang   aplikasi jika pengguna tidak   diberikan tingkat bantuan akses ini,   jadi tolong jawab dengan pengaturan seperti itu di   pikiran.

Saya bertanya-tanya apakah ada dari persyaratan ini yang mengharuskan sistem kata sandi yang dapat diambil. Contohnya: Bibi Mabel menelepon dan berkata, "Program internet Anda tidak berfungsi, saya tidak tahu kata sandi saya". "OK" kata drone layanan pelanggan "biarkan aku memeriksa beberapa detail dan kemudian aku akan memberi Anda kata sandi baru. Ketika Anda masuk berikutnya, Anda akan ditanya apakah Anda ingin menyimpan kata sandi itu atau mengubahnya menjadi sesuatu yang Anda ingat dengan lebih mudah. ​​"

Kemudian sistem diatur untuk mengetahui kapan reset kata sandi telah terjadi dan menampilkan pesan "Anda ingin menyimpan kata sandi baru atau memilih yang baru".

Bagaimana ini lebih buruk bagi yang kurang mengerti PC daripada diberi tahu kata sandi lama mereka? Dan sementara orang layanan pelanggan bisa bangun untuk merusak, database itu sendiri jauh lebih aman jika itu dilanggar.

Komentar apa yang buruk pada saran saya dan saya akan menyarankan solusi yang benar-benar melakukan apa yang awalnya Anda inginkan.


55
2018-02-25 11:27



Michael Brooks telah agak vokal tentang CWE-257 - fakta bahwa metode apa pun yang Anda gunakan, Anda (administrator) masih dapat memulihkan kata sandi. Jadi bagaimana dengan opsi ini:

  1. Enkripsikan kata sandi dengan Milik orang lain kunci publik - beberapa otoritas eksternal. Dengan cara itu Anda tidak dapat merekonstruksi secara pribadi, dan pengguna harus pergi ke otoritas eksternal itu dan meminta agar kata sandi mereka pulih.
  2. Enkripsikan kata sandi menggunakan kunci yang dihasilkan dari frasa sandi kedua. Lakukan enkripsi sisi-klien ini dan jangan pernah mengirimkannya secara jelas ke server. Kemudian, untuk memulihkan, lakukan sisi klien dekripsi lagi dengan menghasilkan kembali kunci dari masukan mereka. Diakui, pendekatan ini pada dasarnya menggunakan kata sandi kedua, tetapi Anda selalu dapat memberi tahu mereka untuk menuliskannya, atau menggunakan pendekatan pertanyaan keamanan lama.

Saya pikir 1. adalah pilihan yang lebih baik, karena memungkinkan Anda untuk menunjuk seseorang dalam perusahaan klien untuk memegang kunci privat. Pastikan mereka menghasilkan kunci itu sendiri, dan menyimpannya dengan instruksi dalam aman dll. Anda bahkan dapat menambahkan keamanan dengan memilih untuk hanya mengenkripsi dan menyediakan karakter tertentu dari kata sandi ke pihak ketiga internal sehingga mereka harus memecahkan kata sandi untuk menebak saya t. Memasukkan karakter-karakter ini ke pengguna, mereka mungkin akan mengingat apa itu!


42
2018-02-18 13:56