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

Ketika saya terus membangun situs web dan aplikasi web yang semakin banyak, saya sering diminta untuk menyimpan kata sandi pengguna dengan cara yang dapat diambil jika / ketika pengguna memiliki masalah (baik untuk mengirim email tautan kata sandi yang terlupakan, telusuri melalui telepon, dll.) Ketika saya dapat berjuang melawan praktik ini dan saya melakukan banyak pemrograman 'ekstra' untuk membuat pengaturan ulang kata sandi dan bantuan administrasi mungkin dilakukan 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 basis data — meskipun saya sadar jika DB saya diretas tidak akan butuh banyak bagi pelakunya untuk memecahkan kata sandi, sehingga membuat saya tidak nyaman.

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

Secara moral dan etis saya merasa bertanggung jawab untuk melindungi apa yang bisa menjadi, bagi sebagian pengguna, penghidupan mereka bahkan jika mereka memperlakukannya dengan rasa hormat yang jauh lebih sedikit. Saya yakin bahwa ada banyak cara untuk mendekati dan argumen yang harus dibuat untuk memberi garam hash dan opsi pengkodean 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 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 kuliah tentang manfaat mengambil pendekatan ini. Saya mencari langkah terbaik yang harus diambil jika Anda mengambil pendekatan ini.

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

Dalam sistem seperti itu, tingkat pengurangan dari demografi ini dapat membuat pincang aplikasi jika pengguna tidak diberi tingkat bantuan akses ini, jadi harap jawab dengan pengaturan seperti itu dalam pikiran.

Terima kasih semuanya

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

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

Juga, terima kasih kepada semua orang di komunitas Stack yang memberikan suara untuk pertanyaan ini dan / atau menandainya sebagai favorit. Saya menerima 100 suara sebagai pujian dan berharap diskusi ini telah membantu orang lain dengan kepedulian yang sama dengan yang saya miliki.

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

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

Salah satu cara mengatasi masalah itu adalah menyediakan kata sandi yang dibuat secara otomatis yang lebih atau kurang teks bahasa alami. Meskipun string bahasa alami mungkin tidak memiliki entropi yang dimiliki oleh serangkaian karakter acak dengan panjang yang sama, tidak ada yang mengatakan kata sandi yang dibuat secara otomatis hanya perlu memiliki 8 (atau 10 atau 12) karakter. Dapatkan passphrase yang dihasilkan secara otomatis dengan entropi tinggi dengan merangkai beberapa kata acak (sisakan spasi di antara mereka, sehingga mereka masih dapat dikenali dan diketik oleh siapa saja yang bisa membaca) Enam kata acak dengan panjang bervariasi mungkin lebih mudah untuk diketik dengan benar dan dengan keyakinan daripada 10 karakter acak, dan mereka dapat memiliki entropi yang lebih tinggi juga. Misalnya, entropi kata sandi 10 karakter diambil secara acak dari huruf besar, huruf kecil, digit dan 10 simbol tanda baca (untuk total 72 simbol yang valid) akan memiliki entropi 61,7 bit. Menggunakan kamus 7776 kata (seperti penggunaan Diceware) yang dapat dipilih secara acak untuk frasa sandi enam kata, frasa sandi akan memiliki entropi 77,4 bit. LihatFAQ Diceware untuk info lebih lanjut.

• frasa sandi 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 mengetik frasa, dan dengan copy-n-paste, frasa juga tidak 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, hasilkan 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 tingkat nilai yang tinggi, sehingga pelanggaran kata sandi mungkin bukan akhir dari dunia. Misalnya, saya mungkin tidak akan peduli jika 80% dari kata sandi yang saya gunakan di berbagai situs web dilanggar: yang dapat terjadi hanyalah seseorang yang mengirim spam atau mengeposkan dengan nama saya untuk sementara waktu. Itu tidak akan bagus, tetapi tidak seperti mereka membobol rekening bank saya. Namun, mengingat fakta bahwa banyak orang menggunakan kata sandi yang sama untuk situs forum web mereka seperti yang mereka lakukan untuk rekening bank mereka (dan mungkin database keamanan nasional), saya pikir akan lebih baik untuk menangani bahkan kata sandi yang 'bernilai rendah' ​​itu sebagai bukan -dapat dipulihkan.

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

Arsitek: Untuk bangunan dengan ukuran dan kapasitas ini, Anda perlu keluar api di sini, di sini, dan di sini.
Klien: Tidak, itu terlalu rumit dan mahal untuk dipertahankan, saya tidak ingin ada pintu samping atau pintu belakang.
Arsitek: Pak, pintu keluar tidak opsional, mereka diperlukan sesuai kode api 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 cenderung berakhir seperti ini:

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

Pemrograman komputer mungkin bukan profesi berlisensi , tetapi orang sering bertanya-tanya mengapa profesi kita tidak mendapatkan rasa hormat yang sama seperti insinyur sipil atau mekanik - yah, tidak perlu mencari lagi. Profesi-profesi itu, ketika menyerahkan persyaratan sampah (atau sangat berbahaya), hanya akan menolak. Mereka tahu itu bukan alasan untuk mengatakan, "Ya, saya melakukan yang terbaik, tetapi dia bersikeras, dan saya harus melakukan apa yang dia katakan." Mereka bisa kehilangan lisensi untuk alasan itu.

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

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

Anda dapat mengenkripsi kata sandi + garam dengan kunci publik. Untuk login cukup periksa apakah nilai yang disimpan sama dengan nilai yang dihitung dari input pengguna + garam. Jika ada saatnya, ketika kata sandi perlu dikembalikan dalam plaintext, Anda dapat mendekripsi secara manual atau semi-otomatis dengan kunci pribadi. Kunci pribadi dapat disimpan di tempat lain dan juga dapat dienkripsi secara simetris (yang membutuhkan interaksi manusia untuk mendekripsi kata sandi kemudian).

Saya pikir ini sebenarnya mirip dengan cara agen Pemulihan Windows bekerja.

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

Jangan menyerah. Senjata yang dapat Anda gunakan untuk meyakinkan klien Anda adalah tidak dapat disangkal. Jika Anda dapat merekonstruksi kata sandi pengguna melalui mekanisme apa pun, Anda telah memberi klien mereka mekanisme non-repudiasi yang sah dan mereka dapat menolak transaksi apa pun yang bergantung pada kata sandi itu, karena tidak ada cara pemasok dapat membuktikan bahwa mereka tidak merekonstruksi kata sandi tersebut. dan melakukan transaksi melalui diri mereka sendiri. Jika kata sandi disimpan dengan benar sebagai intisari alih-alih cipherteks, ini tidak mungkin, baik klien akhir melakukan transaksi sendiri atau melanggar kewajibannya untuk merawat kata sandi. Dalam kedua kasus itu, ia meninggalkan tanggung jawab secara langsung. Saya telah menangani kasus-kasus yang jumlahnya mencapai ratusan juta dolar. Bukan sesuatu yang Anda ingin salah.

Anda tidak dapat secara etis menyimpan kata sandi untuk pencarian plaintext nanti. Sesederhana itu. Bahkan Jon Skeet tidak dapat secara etis menyimpan kata sandi untuk pencarian plaintext nanti. Jika pengguna Anda dapat mengambil kata sandi dalam teks biasa atau lainnya, maka berpotensi juga seorang peretas yang menemukan kerentanan keamanan dalam kode Anda. Dan itu bukan hanya satu kata sandi pengguna yang dikompromikan, tetapi semuanya.

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

Cara termudah untuk memungkinkan pengguna memulihkan login adalah dengan mengirimi mereka email satu kali tautan yang mencatatnya secara otomatis dan mengarahkan 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:

• http://jamesmckay.net/2009/09/if-you-are-saving-passwords-in-clear-text-you-are-probably-breaking-the-law/
• http://jamesmckay.net/2008/06/easy-login-recovery-without-compromising-security/

Pembaruan: kami 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 $ 5 juta ; Sony didenda £ 250.000 karena peretasan data PlayStation . Jika saya ingat dengan benar, LinkedIn sebenarnya mengenkripsi kata sandi penggunanya, tetapi enkripsi yang digunakannya terlalu lemah untuk menjadi efektif.

Setelah membaca bagian ini:

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

Dalam sistem seperti itu, tingkat pengurangan dari demografi ini dapat membuat pincang aplikasi jika pengguna tidak diberi tingkat bantuan akses ini, jadi harap jawab dengan pengaturan seperti itu dalam pikiran.

Saya bertanya-tanya apakah ada di antara persyaratan ini yang mengharuskan sistem kata sandi yang dapat diambil. Misalnya: Bibi Mabel menelepon dan mengatakan "Program internet Anda tidak berfungsi, saya tidak tahu kata sandi saya". "OK" kata drone layanan pelanggan "biarkan saya memeriksa beberapa detail dan kemudian saya akan memberi Anda kata sandi baru . Ketika Anda masuk nanti akan menanyakan apakah Anda ingin menyimpan kata sandi itu atau mengubahnya menjadi sesuatu yang dapat Anda ingat lebih mudah."

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

Bagaimana ini lebih buruk bagi yang kurang melek PC daripada diberi tahu kata sandi lama mereka? Dan sementara orang layanan pelanggan dapat berbuat jahat, 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 Anda inginkan pada awalnya.

Michael Brooks 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. Enkripsi kata sandi dengan kunci publik orang lain - beberapa otoritas eksternal. Dengan begitu Anda tidak dapat merekonstruksi secara pribadi, dan pengguna harus pergi ke otoritas eksternal itu dan meminta agar kata sandi mereka dipulihkan.
2. Enkripsi kata sandi menggunakan kunci yang dihasilkan dari frasa sandi kedua. Lakukan enkripsi sisi klien ini dan jangan pernah mentransmisikannya secara jelas ke server. Kemudian, untuk memulihkan, lakukan dekripsi sisi klien lagi dengan menghasilkan kembali kunci dari input mereka. Memang, pendekatan ini pada dasarnya menggunakan kata sandi kedua, tetapi Anda selalu dapat meminta mereka untuk menuliskannya, atau menggunakan pendekatan pertanyaan keamanan lama.

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

Sudah ada banyak diskusi tentang masalah keamanan bagi pengguna dalam menanggapi pertanyaan ini, tetapi saya ingin menambahkan menyebutkan manfaat. Sejauh ini, saya belum melihat satu manfaat sah yang disebutkan karena kata sandi yang dapat dipulihkan disimpan di sistem. Pertimbangkan ini:

• Apakah pengguna mendapat manfaat dari kata sandi mereka diemail ke mereka? Tidak. Mereka menerima lebih banyak manfaat dari tautan reset kata sandi sekali pakai, yang diharapkan akan memungkinkan mereka memilih kata sandi yang akan mereka ingat.
• Apakah pengguna mendapat manfaat dari ditampilkannya kata sandi di layar? Tidak, dengan alasan yang sama seperti di atas; mereka harus memilih kata sandi baru.
• Apakah pengguna mendapat manfaat dari memiliki orang yang membantu mengucapkan kata sandi kepada pengguna? Tidak; sekali lagi, jika orang yang mendukung menganggap permintaan pengguna untuk kata sandi mereka telah diautentikasi dengan benar, lebih baik bagi pengguna untuk diberikan kata sandi baru dan kesempatan untuk mengubahnya. Plus, dukungan telepon lebih mahal daripada pengaturan ulang kata sandi otomatis, sehingga perusahaan juga tidak mendapat manfaat.

Tampaknya satu-satunya yang dapat mengambil manfaat dari kata sandi yang dapat dipulihkan adalah orang-orang dengan niat jahat atau pendukung API yang buruk yang memerlukan pertukaran kata sandi pihak ketiga (tolong jangan gunakan kata API sebelumnya!). Mungkin Anda dapat memenangkan argumen Anda dengan menyatakan dengan jujur ​​kepada klien Anda bahwa perusahaan tidak mendapatkan keuntungan dan hanya kewajiban dengan menyimpan kata sandi yang dapat dipulihkan .

Membaca di antara baris-baris jenis permintaan ini, Anda akan melihat bahwa klien Anda mungkin tidak mengerti atau bahkan benar-benar peduli sama sekali tentang bagaimana kata sandi dikelola. Yang benar-benar mereka inginkan adalah sistem otentikasi yang tidak terlalu sulit bagi penggunanya. Jadi, selain memberi tahu mereka bagaimana mereka sebenarnya tidak menginginkan kata sandi yang dapat dipulihkan, Anda harus menawarkan cara untuk membuat proses otentikasi tidak terlalu menyakitkan, terutama jika Anda tidak memerlukan tingkat keamanan yang tinggi, misalnya, sebuah bank:

• Izinkan pengguna menggunakan alamat email mereka untuk nama pengguna mereka. Saya telah melihat banyak kasus di mana pengguna lupa nama pengguna mereka, tetapi sedikit yang lupa alamat email mereka.
• Tawarkan OpenID dan biarkan pihak ketiga membayar biaya pelupa pengguna.
• Meringankan pembatasan kata sandi. Saya yakin kita semua sangat kesal ketika beberapa situs web tidak mengizinkan kata sandi pilihan Anda karena persyaratan yang tidak berguna seperti "Anda tidak dapat menggunakan karakter khusus" atau "kata sandi Anda terlalu panjang" atau "kata sandi Anda harus mulai dengan surat. " Juga, jika kemudahan penggunaan merupakan masalah yang lebih besar daripada kekuatan kata sandi, Anda dapat melonggarkan persyaratan yang bahkan tidak bodoh dengan mengizinkan kata sandi yang lebih pendek atau tidak memerlukan campuran kelas karakter. Dengan pembatasan yang longgar, pengguna akan lebih cenderung menggunakan kata sandi yang tidak akan mereka lupakan.
• Jangan kedaluwarsa kata sandi.
• Izinkan pengguna untuk menggunakan kembali kata sandi lama.
• Izinkan pengguna untuk memilih pertanyaan pengaturan ulang kata sandi mereka sendiri.

Tetapi jika Anda, untuk beberapa alasan (dan tolong beri tahu kami alasannya) benar-benar, benar - benar perlu untuk dapat memiliki kata sandi yang dapat dipulihkan, Anda dapat melindungi pengguna dari kemungkinan membahayakan akun online mereka yang lain dengan memberi mereka non-kata sandi- sistem otentikasi berbasis. Karena orang sudah terbiasa dengan sistem nama pengguna / kata sandi dan mereka adalah solusi yang dijalankan dengan baik, ini akan menjadi pilihan terakhir, tetapi pasti ada banyak alternatif kreatif untuk kata sandi:

• Biarkan pengguna memilih pin numerik, lebih disukai bukan 4 digit, dan lebih disukai hanya jika upaya kekerasan dilindungi.
• Mintalah pengguna memilih pertanyaan dengan jawaban singkat yang hanya mereka yang tahu jawabannya, tidak akan pernah berubah, mereka akan selalu ingat, dan mereka tidak keberatan orang lain mengetahuinya.
• Mintalah pengguna memasukkan nama pengguna dan kemudian menggambar bentuk yang mudah diingat dengan permutasi yang cukup untuk melindungi dari tebakan (lihat foto bagus tentang bagaimana G1 melakukan ini untuk membuka kunci ponsel).
• Untuk situs web anak-anak, Anda dapat membuat makhluk fuzzy secara otomatis berdasarkan nama pengguna (semacam identitas) dan meminta pengguna untuk memberikan nama rahasia kepada makhluk itu. Mereka kemudian dapat diminta untuk memasukkan nama rahasia makhluk itu untuk login.

Berdasarkan komentar yang saya buat pada pertanyaan:
Satu poin penting telah sangat disorot oleh hampir semua orang ... Reaksi awal saya sangat mirip dengan @Michael Brooks, sampai saya menyadari, seperti @stefanw, bahwa masalah di sini adalah persyaratan rusak , tetapi inilah mereka.
Tetapi kemudian, terlintas dalam benak saya bahwa itu mungkin bukan masalahnya! Titik hilang di sini, adalah tak terucapkan nilai aset aplikasi. Sederhananya, untuk sistem bernilai rendah, mekanisme otentikasi yang sepenuhnya aman, dengan semua proses yang terlibat, akan berlebihan, dan pilihan keamanan yang salah .
Jelas, bagi bank, "praktik terbaik" adalah suatu keharusan, dan tidak ada cara untuk melanggar etika CWE-257. Tetapi mudah untuk memikirkan sistem bernilai rendah yang tidak sepadan (tetapi kata sandi sederhana masih diperlukan).

Penting untuk diingat, keahlian keamanan sejati adalah dalam menemukan pengorbanan yang tepat, BUKAN dalam dogmatis menyemburkan "Praktik Terbaik" yang dapat dibaca siapa saja secara online.

Karena itu, saya menyarankan solusi lain:
Tergantung pada nilai sistem, dan HANYA JIKA sistem bernilai rendah dengan tepat tanpa aset "mahal" (identitas itu sendiri, termasuk), DAN ada persyaratan bisnis yang valid yang membuat proses yang tepat mustahil (atau cukup sulit / mahal), DAN klien dibuat sadar akan semua peringatan ...
Maka mungkin lebih tepat untuk hanya mengizinkan enkripsi yang dapat dibalik, tanpa rintangan khusus untuk dilewati.
Saya hanya berhenti mengatakan tidak perlu repot-repot dengan enkripsi sama sekali, karena sangat sederhana / murah untuk diterapkan (bahkan mempertimbangkan manajemen kunci yang mungkin), dan TIDAK memberikan beberapa perlindungan (lebih dari biaya pelaksanaannya). Juga, ada baiknya melihat bagaimana memberikan pengguna dengan kata sandi asli, baik melalui email, ditampilkan di layar, dll.
Karena asumsi di sini adalah bahwa nilai kata sandi yang dicuri (bahkan secara agregat) cukup rendah, solusi ini bisa valid.

Karena ada diskusi yang berlangsung, sebenarnya diskusi BEBERAPA hidup, di posting yang berbeda dan utas komentar yang terpisah, saya akan menambahkan beberapa klarifikasi, dan menanggapi beberapa poin yang sangat baik yang telah diajukan di tempat lain di sini.

Untuk memulai, saya pikir itu jelas bagi semua orang di sini bahwa memungkinkan kata sandi asli pengguna untuk diambil, adalah Praktek Buruk, dan umumnya Bukan Ide Yang Baik. Itu sama sekali tidak dalam perselisihan ...
Selanjutnya, saya akan menekankan bahwa dalam banyak situasi, bahkan PALING, - itu benar-benar salah, bahkan busuk, jahat, DAN jelek .

Namun, inti dari pertanyaan adalah sekitar prinsip , ADA situasi di mana mungkin tidak perlu untuk melarang ini, dan jika demikian, bagaimana melakukannya dengan cara yang paling benar sesuai dengan situasi .

Sekarang, seperti @Thomas, @sfussenegger dan beberapa orang lain yang disebutkan, satu-satunya cara yang tepat untuk menjawab pertanyaan itu, adalah dengan melakukan analisis risiko menyeluruh dari setiap situasi (atau hipotetis) yang diberikan, untuk memahami apa yang dipertaruhkan, berapa nilai yang perlu dilindungi. , dan mitigasi lain apa yang berperan untuk memberikan perlindungan itu.
Tidak, ini BUKAN kata kunci, ini adalah salah satu alat dasar yang paling penting bagi seorang profesional keamanan nyata. Praktik terbaik adalah baik sampai titik tertentu (biasanya sebagai pedoman untuk yang tidak berpengalaman dan peretasan), setelah itu analisis risiko yang bijaksana mengambil alih.

Kau tahu, itu lucu - aku selalu menganggap diriku salah satu fanatik keamanan, dan entah bagaimana aku berada di sisi berlawanan dari yang disebut "Pakar Keamanan" ... Yah, kebenaran adalah - karena aku seorang fanatik, dan seorang ahli keamanan kehidupan nyata yang sebenarnya - Saya tidak percaya pada semburan dogma "Praktek Terbaik" (atau CWE) TANPA analisis risiko yang sangat penting .
"Waspadalah pada fanatik keamanan yang cepat menerapkan segala sesuatu di sabuk alat mereka tanpa mengetahui apa masalah sebenarnya yang mereka lawan. Keamanan lebih tidak selalu berarti keamanan yang baik."
Analisis risiko, dan fanatik keamanan sejati, akan menunjuk pada tradeoff yang lebih cerdas, berdasarkan nilai / risiko, berdasarkan risiko, potensi kerugian, kemungkinan ancaman, mitigasi pelengkap, dll. Setiap "Pakar Keamanan" yang tidak dapat menunjukkan analisis risiko yang sehat sebagai dasar untuk rekomendasi mereka, atau mendukung pengorbanan logis, tetapi lebih memilih untuk menyemburkan dogma dan CWE tanpa memahami bagaimana melakukan analisis risiko, tidak lain hanyalah Security Hacks, dan Keahlian mereka tidak sebanding dengan kertas toilet tempat mereka mencetaknya.

Memang, itulah cara kami mendapatkan kekonyolan yaitu Keamanan Bandara.

Tetapi sebelum kita berbicara tentang pengorbanan yang tepat untuk dibuat dalam SITUASI INI, mari kita lihat risiko yang tampak (jelas, karena kita tidak memiliki semua informasi latar belakang tentang situasi ini, kita semua berhipotesis - karena pertanyaannya adalah hipotesis apa situasi mungkin ada ...)
Mari kita asumsikan sistem RENDAH-NILAI, namun tidak sepele itu adalah akses publik - pemilik sistem ingin mencegah peniruan biasa, namun keamanan "tinggi" tidak sepenting kemudahan penggunaan. (Ya, itu adalah tradeoff yang sah untuk MENERIMA risiko bahwa setiap script-kiddie yang mahir dapat meretas situs ... Tunggu, bukankah APT dalam mode sekarang ...?)
Sebagai contoh, katakanlah saya sedang mengatur situs sederhana untuk pertemuan keluarga besar, memungkinkan semua orang untuk bertukar pikiran tentang ke mana kami ingin pergi dalam perjalanan berkemah tahun ini. Saya kurang khawatir tentang beberapa hacker anonim, atau bahkan Sepupu Fred memeras saran berulang untuk kembali ke Danau Wantanamanabikiliki, karena saya tentang Bibi Erma tidak bisa masuk ketika dia perlu. Sekarang, Bibi Erma, menjadi fisikawan nuklir, tidak pandai mengingat kata sandi, atau bahkan dengan menggunakan komputer sama sekali ... Jadi saya ingin menghapus semua gesekan yang mungkin terjadi padanya. Sekali lagi, saya TIDAK khawatir tentang peretasan, saya hanya tidak ingin kesalahan masuk yang salah - saya ingin tahu siapa yang akan datang, dan apa yang mereka inginkan.

Bagaimanapun.
Jadi apa risiko utama kita di sini, jika kita mengenkripsi kata sandi secara simetris, daripada menggunakan hash satu arah?

• Meniru pengguna? Tidak, saya sudah menerima risiko itu, tidak menarik.
• Administrator jahat? Yah, mungkin ... Tapi sekali lagi, saya tidak peduli apakah seseorang dapat menyamar sebagai pengguna lain, INTERNAL atau tidak ... dan lagi pula admin jahat akan mendapatkan kata sandi Anda apa pun yang terjadi - jika admin Anda memburuk, permainannya sudah berakhir.
• Masalah lain yang telah diangkat, adalah identitas yang sebenarnya dibagi antara beberapa sistem. Ah! Ini adalah risiko yang sangat menarik, yang membutuhkan pandangan lebih dekat.
  Mari saya mulai dengan menyatakan bahwa itu bukan identitas aktual yang dibagikan, melainkan bukti , atau kredensial otentikasi. Oke, karena kata sandi bersama secara efektif akan memungkinkan saya masuk ke sistem lain (katakanlah, rekening bank saya, atau gmail), ini secara efektif identitas yang sama, jadi itu hanya semantik ... Kecuali itu tidak . Identitas dikelola secara terpisah oleh masing-masing sistem, dalam skenario ini (meskipun mungkin ada sistem id pihak ketiga, seperti OAuth - masih, yang terpisah dari identitas dalam sistem ini - lebih lanjut tentang ini nanti).
  Karena itu, titik risiko utama di sini, adalah bahwa pengguna akan dengan senang hati memasukkan kata sandi (yang sama) ke beberapa sistem yang berbeda - dan sekarang, saya (admin) atau peretas lain di situs saya akan memiliki akses ke kata sandi Bibi Erma untuk situs rudal nuklir.

Hmmm.

Apakah ada sesuatu di sini yang tampaknya tidak menyenangkan bagi Anda?

Itu harus.

Mari kita mulai dengan fakta bahwa melindungi sistem rudal nuklir bukan tanggung jawab saya , saya hanya membangun situs tamasya keluarga frakkin (untuk keluarga SAYA). Jadi, siapa yang bertanggung jawab? Umm ... Bagaimana dengan sistem rudal nuklir? Duh.
Kedua, Jika saya ingin mencuri kata sandi seseorang (seseorang yang diketahui berulang kali menggunakan kata sandi yang sama antara situs yang aman, dan yang tidak terlalu aman) - mengapa saya repot-repot meretas situs Anda? Atau berjuang dengan enkripsi simetris Anda? Goshdarnitall, saya bisa memasang situs web sederhana saya sendiri , meminta pengguna mendaftar untuk menerima BERITA SANGAT PENTING tentang apa pun yang mereka inginkan ... Puffo Presto, saya "mencuri" kata sandi mereka.

Ya, pendidikan pengguna selalu kembali menggigit kami di hienie, bukan?
Dan tidak ada yang dapat Anda lakukan tentang hal itu ... Bahkan jika Anda ingin memilah-milah kata sandi mereka di situs Anda, dan melakukan segala hal lain yang dapat dipikirkan TSA, Anda menambahkan perlindungan ke kata sandi mereka TIDAK SATU PUTIH , jika mereka akan menyimpannya Tanpa sengaja menempelkan kata sandi mereka ke setiap situs yang ditabraknya. Jangan BAHKAN repot-repot mencoba.

Dengan kata lain, Anda tidak memiliki kata sandi mereka , jadi berhentilah mencoba bertindak seperti Anda.

Jadi, Pakar Keamanan saya yang terhormat, seperti seorang wanita tua yang biasa meminta Wendy, "MANA risikonya?"

Beberapa poin lain, sebagai jawaban atas beberapa masalah yang diangkat di atas:

• CWE bukan hukum, atau peraturan, atau bahkan standar. Ini adalah kumpulan kelemahan umum , yaitu kebalikan dari "Praktik Terbaik".
• Masalah identitas bersama adalah masalah aktual, tetapi disalahpahami (atau disalahpahami) oleh orang-orang yang tidak bertanggung jawab di sini. Ini adalah masalah berbagi identitas di dalam dan dari dirinya sendiri (!), BUKAN tentang memecahkan kata sandi pada sistem bernilai rendah. Jika Anda membagikan kata sandi antara sistem bernilai rendah dan bernilai tinggi, masalahnya sudah ada!
• Pada akhirnya, poin sebelumnya akan benar-benar menunjuk TERHADAP menggunakan OAuth dan sejenisnya untuk kedua sistem bernilai rendah ini, dan sistem perbankan bernilai tinggi.
• Saya tahu itu hanya contoh, tetapi (sayangnya) sistem FBI sebenarnya bukan yang paling aman. Tidak seperti server blog kucing Anda, tetapi mereka juga tidak melampaui beberapa bank yang lebih aman.
• Berpisah pengetahuan, atau kontrol ganda, kunci enkripsi TIDAK terjadi hanya di militer, pada kenyataannya PCI-DSS sekarang memerlukan ini pada dasarnya semua pedagang, jadi itu tidak benar-benar begitu jauh di luar sana lagi (JIKA nilainya membenarkan itu).
• Kepada semua yang mengeluh bahwa pertanyaan seperti inilah yang membuat profesi pengembang terlihat sangat buruk: itu adalah jawaban seperti itu, yang membuat profesi keamanan terlihat lebih buruk. Sekali lagi, analisis risiko yang berfokus pada bisnis adalah apa yang diperlukan, jika tidak Anda menjadikan diri Anda tidak berguna. Selain salah.
• Saya kira inilah sebabnya bukan ide yang baik untuk hanya mengambil pengembang reguler dan melepaskan lebih banyak tanggung jawab keamanan padanya, tanpa pelatihan untuk berpikir secara berbeda, dan untuk mencari pengorbanan yang benar. Jangan tersinggung, bagi Anda di sini, saya semua untuk itu - tetapi pelatihan lebih banyak dalam rangka.

Wah. Sungguh posting yang panjang ...
Tetapi untuk menjawab pertanyaan awal Anda, @Shane:

• Jelaskan kepada pelanggan cara yang tepat untuk melakukan sesuatu.
• Jika dia masih bersikeras, jelaskan lebih banyak lagi, bersikeras, berdebat. Buat ulah, jika perlu.
• Jelaskan RISIKO BISNIS kepadanya. Detailnya bagus, angkanya lebih baik, demo langsung biasanya yang terbaik.
• JIKA DIA MASIH bersikeras, DAN menyajikan alasan bisnis yang valid - inilah saatnya bagi Anda untuk melakukan penilaian panggilan:
  Apakah situs ini bernilai rendah hingga tidak bernilai? Apakah ini benar-benar kasus bisnis yang valid? Apakah itu cukup baik untukmu? Apakah tidak ada risiko lain yang dapat Anda pertimbangkan, yang akan melebihi alasan bisnis yang valid? (Dan tentu saja, klien BUKAN situs berbahaya, tapi itu duh).
  Jika demikian, langsung saja. Tidak sepadan dengan usaha, gesekan, dan penggunaan yang hilang (dalam situasi hipotetis ini) untuk menerapkan proses yang diperlukan. Keputusan lain (sekali lagi, dalam situasi ini) merupakan tradeoff yang buruk.

Jadi, intinya, dan jawaban yang sebenarnya - mengenkripsi dengan algoritma simetris sederhana, melindungi kunci enkripsi dengan ACL yang kuat dan lebih disukai DPAPI atau sejenisnya, mendokumentasikannya dan meminta klien (seseorang yang cukup senior untuk membuat keputusan) keluar Itu.

Bagaimana dengan rumah singgah?

Simpan kata sandi dengan enkripsi yang kuat, dan jangan aktifkan pengaturan ulang.

Alih-alih mengatur ulang kata sandi, izinkan pengiriman kata sandi satu kali (yang harus diubah segera setelah masuk pertama kali). Biarkan pengguna kemudian mengubah kata sandi apa pun yang mereka inginkan (yang sebelumnya, jika mereka mau).

Anda dapat "menjual" ini sebagai mekanisme aman untuk mengatur ulang kata sandi.

Satu-satunya cara untuk memungkinkan pengguna untuk mengambil kata sandi asli mereka, adalah mengenkripsi dengan kunci publik pengguna sendiri. Hanya pengguna yang kemudian dapat mendekripsi kata sandi mereka.

Jadi langkah-langkahnya adalah:

1. Pengguna mendaftar di situs Anda (tentu saja melalui SSL) tanpa menetapkan kata sandi. Log in secara otomatis atau berikan kata sandi sementara.
2. Anda menawarkan untuk menyimpan kunci PGP publik mereka untuk pengambilan kata sandi di masa depan.
3. Mereka mengunggah kunci PGP publik mereka.
4. Anda meminta mereka untuk membuat kata sandi baru.
5. Mereka mengirimkan kata sandi mereka.
6. Anda hash kata sandi menggunakan algoritma hashing kata sandi terbaik yang tersedia (misalnya bcrypt). Gunakan ini saat memvalidasi login berikutnya.
7. Anda mengenkripsi kata sandi dengan kunci publik, dan menyimpannya secara terpisah.

Jika pengguna kemudian meminta kata sandi mereka, Anda merespons dengan kata sandi terenkripsi (bukan hash). Jika pengguna tidak ingin dapat mengambil kembali kata sandi mereka di masa mendatang (mereka hanya akan dapat mengatur ulang kata sandi itu menjadi yang dihasilkan oleh layanan), langkah 3 dan 7 dapat dilewati.

Saya pikir pertanyaan sebenarnya yang harus Anda tanyakan pada diri sendiri adalah: 'Bagaimana saya bisa lebih baik dalam meyakinkan orang?'

Saya memiliki masalah yang sama. Dan pada saat yang sama saya selalu berpikir bahwa seseorang meretas sistem saya itu bukan masalah "jika" tetapi "kapan".

Jadi, ketika saya harus melakukan situs web yang perlu menyimpan informasi rahasia yang dapat dipulihkan, seperti kartu kredit atau kata sandi, yang saya lakukan adalah:

• mengenkripsi dengan: openssl_encrypt (string $ data, string $ method, string $ password)
  • Manual PHP .
• data arg :
  • informasi sensitif (mis. kata sandi pengguna)
  • serialkan jika perlu, mis. jika informasi tersebut adalah larik data seperti informasi sensitif berganda
• kata sandi arg : gunakan informasi yang hanya diketahui pengguna seperti:
  • plat nomor pengguna
  • nomor keamanan sosial
  • nomor telepon pengguna
  • nama ibu pengguna
  • string acak yang dikirim melalui email dan / atau sms pada saat mendaftar
• metode arg :
  • pilih satu metode sandi, seperti "aes-256-cbc"
• JANGAN PERNAH menyimpan informasi yang digunakan dalam argumen "kata sandi" di basis data (atau tempat apa pun dalam sistem)

Bila perlu untuk retrive data ini cukup gunakan fungsi "openssl_decrypt ()" dan tanyakan jawabannya pada pengguna. Misalnya: "Untuk menerima kata sandi Anda, jawab pertanyaan: Berapa nomor ponsel Anda?"

PS 1 : jangan pernah gunakan sebagai kata sandi data disimpan dalam database. Jika Anda perlu menyimpan nomor ponsel pengguna, maka jangan pernah menggunakan informasi ini untuk menyandikan data. Selalu gunakan informasi yang hanya diketahui pengguna atau sulit diketahui oleh orang yang bukan kerabat.

PS 2 : untuk informasi kartu kredit, seperti "pembelian satu klik", yang saya lakukan adalah menggunakan kata sandi login. Kata sandi ini di-hash dalam database (sha1, md5, dll), tetapi pada saat login saya menyimpan kata sandi teks biasa dalam sesi atau dalam cookie aman yang tidak persisten (yaitu di memori). Kata sandi polos ini tidak pernah tersimpan di database, memang selalu tersimpan di memori, dihancurkan di akhir bagian. Ketika pengguna mengklik tombol "pembelian satu klik" sistem menggunakan kata sandi ini. Jika pengguna masuk dengan layanan seperti facebook, twitter, dll, maka saya meminta kata sandi lagi saat membeli (ok, itu bukan sepenuhnya "saat klik") atau kemudian menggunakan beberapa data dari layanan yang digunakan pengguna untuk login (seperti id facebook).

Mengamankan kredensial bukanlah operasi biner: aman / tidak aman. Keamanan adalah semua tentang penilaian risiko dan diukur pada sebuah kontinum. Para fanatik keamanan tidak suka berpikir seperti ini, tetapi kebenaran yang buruk adalah bahwa tidak ada yang sepenuhnya aman. Kata sandi hash dengan persyaratan kata sandi ketat, sampel DNA, dan pindaian retina lebih aman tetapi dengan biaya pengembangan dan pengalaman pengguna. Kata sandi Plaintext jauh lebih tidak aman tetapi lebih murah untuk diterapkan (tetapi harus dihindari). Pada akhirnya, analisis biaya / manfaat dari pelanggaran. Anda menerapkan keamanan berdasarkan nilai data yang diamankan dan nilai waktunya.

Berapa biaya kata sandi seseorang untuk keluar ke alam liar? Berapa biaya peniruan dalam sistem yang diberikan? Untuk komputer FBI, biayanya bisa sangat besar. Bagi situs web Bob yang hanya terdiri atas satu halaman, satu halaman, biayanya bisa diabaikan. Seorang profesional memberikan opsi kepada pelanggan mereka dan, ketika menyangkut keamanan, menjabarkan keuntungan dan risiko implementasi apa pun. Ini ganda jadi jika klien meminta sesuatu yang dapat menempatkan mereka dalam risiko karena gagal mengindahkan standar industri. Jika klien secara khusus meminta enkripsi dua arah, saya akan memastikan Anda mendokumentasikan keberatan Anda, tetapi itu tidak akan menghentikan Anda dari penerapan dengan cara terbaik yang Anda tahu. Pada akhirnya, itu adalah uang klien. Iya,

Jika Anda menyimpan kata sandi dengan enkripsi dua arah, keamanan semua tergantung pada manajemen kunci. Windows menyediakan mekanisme untuk membatasi akses ke kunci pribadi sertifikat ke akun administratif dan dengan kata sandi. Jika Anda hosting di platform lain, Anda perlu melihat opsi apa yang tersedia di sana. Seperti yang disarankan orang lain, Anda dapat menggunakan enkripsi asimetris.

Tidak ada hukum (baik UU Perlindungan Data di Inggris) yang saya ketahui menyatakan secara khusus bahwa kata sandi harus disimpan menggunakan hash satu arah. Satu-satunya persyaratan dalam undang-undang ini hanyalah bahwa langkah-langkah yang wajar diambil untuk keamanan. Jika akses ke database dibatasi, bahkan kata sandi plaintext dapat memenuhi syarat secara hukum di bawah pembatasan tersebut.

Namun, ini membawa satu aspek lagi: prioritas hukum. Jika didahulukan secara hukum menyarankan bahwa Anda harus menggunakan hash satu arah mengingat industri di mana sistem Anda sedang dibangun, maka itu sama sekali berbeda. Itu adalah amunisi yang Anda gunakan untuk meyakinkan pelanggan Anda. Kecuali itu, saran terbaik untuk memberikan penilaian risiko yang masuk akal, mendokumentasikan keberatan Anda dan mengimplementasikan sistem dengan cara yang paling aman yang Anda bisa berikan pada persyaratan pelanggan.

Jadikan jawaban pertanyaan keamanan pengguna sebagai bagian dari kunci enkripsi, dan jangan simpan jawaban pertanyaan keamanan sebagai teks biasa (bukan itu saja)

Saya menerapkan sistem otentikasi multi-faktor untuk mencari nafkah, jadi bagi saya wajar untuk berpikir bahwa Anda dapat mengatur ulang atau merekonstruksi kata sandi, sementara untuk sementara menggunakan satu faktor yang lebih sedikit untuk mengautentikasi pengguna hanya untuk mengatur ulang / alur kerja rekreasi. Terutama penggunaan OTP (kata sandi satu kali) sebagai beberapa faktor tambahan, mengurangi banyak risiko jika jendela waktu singkat untuk alur kerja yang disarankan. Kami telah mengimplementasikan generator OTP perangkat lunak untuk ponsel cerdas (yang sebagian besar pengguna sudah bawa sendiri sepanjang hari) dengan sangat sukses. Sebelum keluhan tentang plug komersial muncul, apa yang saya katakan adalah bahwa kita dapat menurunkan risiko yang melekat pada menjaga kata sandi mudah diambil atau direset ketika itu bukan satu-satunya faktor yang digunakan untuk mengotentikasi pengguna.

Maaf, tetapi selama Anda memiliki beberapa cara untuk memecahkan sandi, tidak mungkin aman. Berjuanglah dengan sengit, dan jika Anda kalah, CYA.

Baru saja menemukan diskusi yang menarik dan memanas ini. Yang paling mengejutkan saya adalah, betapa sedikit perhatian diberikan pada pertanyaan dasar berikut:

• Q1. Apa alasan sebenarnya pengguna bersikeras memiliki akses ke kata sandi tersimpan teks biasa? Mengapa begitu berharga?

Informasi yang pengguna lebih tua atau muda tidak benar-benar menjawab pertanyaan itu. Tetapi bagaimana keputusan bisnis dapat dibuat tanpa memahami kekhawatiran pelanggan dengan benar?

Sekarang mengapa itu penting? Karena jika penyebab sebenarnya dari permintaan pelanggan adalah sistem yang sangat sulit digunakan, maka mungkin menangani penyebab pasti akan menyelesaikan masalah yang sebenarnya?

Karena saya tidak memiliki informasi ini dan tidak dapat berbicara dengan pelanggan tersebut, saya hanya bisa menebak: Ini tentang kegunaan, lihat di atas.

Pertanyaan lain yang pernah saya tanyakan:

• Q2. Jika pengguna tidak mengingat kata sandi sejak awal, mengapa kata sandi lama itu penting?

Dan inilah jawaban yang mungkin. Jika Anda memiliki kucing bernama "miaumiau" dan menggunakan namanya sebagai kata sandi tetapi lupa Anda melakukannya, apakah Anda lebih suka diingatkan apa itu atau lebih tepatnya dikirim sesuatu seperti "# zy * RW (ew"?

Alasan lain yang mungkin adalah bahwa pengguna menganggapnya sebagai kerja keras untuk membuat kata sandi baru! Jadi, mengirim kata sandi lama kembali memberikan ilusi menyelamatkannya dari pekerjaan yang menyakitkan itu lagi.

Saya hanya mencoba memahami alasannya. Tapi apa pun alasannya, itu bukan alasan yang harus ditangani.

Sebagai pengguna, saya ingin hal-hal sederhana! Saya tidak ingin bekerja keras!

Jika saya masuk ke situs berita untuk membaca koran, saya ingin mengetikkan 1111 sebagai kata sandi dan melalui !!!

Saya tahu itu tidak aman tetapi apa yang saya pedulikan tentang seseorang yang mendapatkan akses ke "akun" saya? Ya, dia juga bisa membaca beritanya!

Apakah situs menyimpan informasi "pribadi" saya? Berita yang saya baca hari ini? Maka itu adalah masalah situs, bukan milikku! Apakah situs menampilkan informasi pribadi kepada pengguna yang diautentikasi? Maka jangan tunjukkan itu di tempat pertama!

Ini hanya untuk menunjukkan sikap pengguna terhadap masalah tersebut.

Jadi untuk meringkas, saya tidak merasa itu adalah masalah bagaimana "aman" menyimpan kata sandi teks biasa (yang kita tahu tidak mungkin) tetapi bagaimana mengatasi masalah pelanggan yang sebenarnya.

Menangani kata sandi yang hilang / terlupakan:

Tidak ada yang bisa memulihkan kata sandi.

Jika pengguna lupa kata sandi, setidaknya mereka harus tahu nama pengguna atau alamat email mereka. Atas permintaan, buat GUID di tabel Pengguna dan mengirim email yang berisi tautan berisi panduan sebagai parameter ke alamat email pengguna.

Halaman di belakang tautan memverifikasi bahwa panduan parameter benar-benar ada (mungkin dengan logika batas waktu), dan meminta kata sandi baru kepada pengguna.

Jika Anda perlu memiliki pengguna bantuan hotline, tambahkan beberapa peran ke model hibah Anda dan biarkan peran hotline untuk sementara masuk sebagai pengguna yang diidentifikasi. Catat semua login hotline tersebut. Sebagai contoh, Bugzilla menawarkan fitur peniruan seperti itu kepada admin.

Bagaimana dengan mengirim email kata sandi plaintext setelah pendaftaran, sebelum dienkripsi dan hilang? Saya telah melihat banyak situs web melakukannya, dan mendapatkan kata sandi itu dari email pengguna lebih aman daripada meninggalkannya di server / comp Anda.

Jika Anda tidak bisa menolak persyaratan untuk menyimpan kata sandi yang dapat dipulihkan, bagaimana ini sebagai argumen balasan Anda.

Kami dapat menggunakan kata sandi hash dengan benar dan membangun mekanisme reset untuk pengguna, atau kami dapat menghapus semua informasi yang dapat diidentifikasi secara pribadi dari sistem. Anda dapat menggunakan alamat email untuk mengatur preferensi pengguna, tetapi hanya itu saja. Gunakan cookie untuk secara otomatis menarik preferensi pada kunjungan mendatang dan membuang data setelah periode yang masuk akal.

Satu opsi yang sering diabaikan dengan kebijakan kata sandi adalah apakah kata sandi benar-benar dibutuhkan. Jika satu-satunya kebijakan password Anda lakukan adalah menyebabkan panggilan layanan pelanggan, mungkin Anda bisa menghilangkannya.

Apakah pengguna benar-benar - perlu memulihkan (misalnya diberi tahu) apa kata sandi yang mereka lupa itu, atau apakah mereka hanya perlu untuk bisa masuk ke sistem? Jika yang benar-benar mereka inginkan adalah kata sandi untuk masuk, mengapa tidak memiliki rutinitas yang hanya mengubah kata sandi lama (apa pun itu) menjadi kata sandi baru yang dapat diberikan oleh orang yang mendukung kepada orang yang kehilangan kata sandinya?

Saya telah bekerja dengan sistem yang melakukan ini. Orang yang mendukung tidak memiliki cara untuk mengetahui apa kata sandi saat ini, tetapi dapat mengatur ulang ke nilai baru. Tentu saja semua pengaturan ulang seperti itu harus dicatat di suatu tempat dan praktik yang baik adalah membuat email kepada pengguna yang mengatakan kepadanya bahwa kata sandi telah disetel ulang.

Kemungkinan lain adalah memiliki dua kata sandi simultan yang memungkinkan akses ke akun. Salah satunya adalah kata sandi "normal" yang dikelola pengguna dan yang lainnya seperti kerangka / kunci master yang hanya diketahui oleh staf pendukung dan sama untuk semua pengguna. Dengan begitu ketika pengguna memiliki masalah, orang yang mendukung dapat login ke akun dengan kunci master dan membantu pengguna mengubah kata sandi untuk apa pun. Tidak perlu dikatakan, semua login dengan kunci master harus dicatat oleh sistem juga. Sebagai tindakan tambahan, setiap kali kunci master digunakan, Anda juga dapat memvalidasi kredensial orang yang mendukung.

-EDIT- Menanggapi komentar tentang tidak memiliki kunci utama: Saya setuju bahwa itu buruk karena saya percaya itu buruk untuk mengizinkan orang lain selain pengguna untuk memiliki akses ke akun pengguna. Jika Anda melihat pertanyaannya, seluruh premisnya adalah bahwa pelanggan mengamanatkan lingkungan keamanan yang sangat berbahaya.

Kunci master tidak harus seburuk yang terlihat pertama kali. Saya dulu bekerja di pabrik pertahanan di mana mereka merasa perlu operator komputer mainframe untuk memiliki "akses khusus" pada kesempatan tertentu. Mereka hanya memasukkan kata sandi khusus dalam amplop tertutup dan menempelkannya ke meja operator. Untuk menggunakan kata sandi (yang tidak diketahui operator) ia harus membuka amplop. Pada setiap perubahan shift, salah satu tugas supervisor shift adalah untuk melihat apakah amplop telah dibuka dan jika segera, kata sandi diganti (oleh departemen lain) dan kata sandi baru dimasukkan ke dalam amplop baru dan proses memulai semua lagi. Operator akan ditanyai mengapa ia membukanya dan insiden itu akan didokumentasikan sebagai catatan.

Meskipun ini bukan prosedur yang akan saya rancang, itu berhasil dan memberikan akuntabilitas yang sangat baik. Semuanya dicatat dan ditinjau, ditambah semua operator memiliki izin rahasia DOD dan kami tidak pernah melakukan pelanggaran.

Karena peninjauan dan pengawasan, semua operator tahu bahwa jika mereka menyalahgunakan hak istimewa untuk membuka amplop, mereka dapat segera diberhentikan dan kemungkinan penuntutan pidana.

Jadi saya kira jawaban sebenarnya adalah jika seseorang ingin melakukan hal yang benar, ia mempekerjakan orang yang dapat mereka percayai, melakukan pemeriksaan latar belakang dan melakukan pengawasan dan pertanggungjawaban manajemen yang tepat.

Tetapi sekali lagi jika klien orang miskin ini memiliki manajemen yang baik, mereka tidak akan meminta solusi keamanan yang dikompromikan di tempat pertama, sekarang akankah mereka?

Dari sedikit yang saya mengerti tentang hal ini, saya percaya bahwa jika Anda membangun situs web dengan signon / kata sandi, maka Anda tidak akan melihat kata sandi plaintext di server Anda sama sekali. Kata sandi harus diacak, dan mungkin digarami, bahkan sebelum meninggalkan klien.

Jika Anda tidak pernah melihat kata sandi plaintext, maka pertanyaan tentang pengambilan tidak muncul.

Saya juga mengumpulkan (dari web) bahwa (diduga) beberapa algoritma seperti MD5 tidak lagi dianggap aman. Saya tidak punya cara untuk menilai itu sendiri, tetapi itu adalah sesuatu untuk dipertimbangkan.

buka DB pada server mandiri dan berikan koneksi jarak jauh terenkripsi ke setiap server web yang membutuhkan fitur ini.
itu tidak harus menjadi DB relasional, itu bisa menjadi sistem file dengan akses FTP, menggunakan folder dan file, bukan tabel dan baris.
berikan izin hanya untuk server web jika Anda bisa.

Menyimpan enkripsi kata sandi yang tidak dapat diambil kembali dalam DB situs (sebut saja "pass-a") seperti yang dilakukan orang normal :)
pada setiap pengguna baru (atau perubahan kata sandi) simpan salinan kata sandi yang sederhana dalam DB jarak jauh. gunakan id server, ID pengguna dan "pass-a" sebagai kunci komposit untuk kata sandi ini. Anda bahkan dapat menggunakan enkripsi dua arah pada kata sandi untuk tidur lebih nyenyak di malam hari.

sekarang agar seseorang mendapatkan kata sandi dan konteksnya (id situs + id pengguna + "pass-a"), ia harus:

1. retas DB situs web untuk mendapatkan pasangan atau pasangan ("pass-a", id pengguna).
2. dapatkan id situs web dari beberapa file konfigurasi
3. menemukan dan meretas DB kata sandi jarak jauh.

Anda dapat mengontrol aksesibilitas layanan pencarian kata sandi (mengeksposnya hanya sebagai layanan web yang diamankan, hanya memperbolehkan pengambilan kata sandi dalam jumlah tertentu per hari, melakukannya secara manual, dll.), dan bahkan mengenakan biaya tambahan untuk "pengaturan keamanan khusus" ini.
Server pengambilan kata sandi DB sangat tersembunyi karena tidak melayani banyak fungsi dan dapat diamankan dengan lebih baik (Anda dapat menyesuaikan izin, proses, dan layanan dengan ketat).

Singkatnya, Anda membuat pekerjaan lebih sulit bagi peretas. kemungkinan pelanggaran keamanan pada server tunggal masih sama, tetapi data yang bermakna (kecocokan akun dan kata sandi) akan sulit untuk dikumpulkan.

Opsi lain yang mungkin tidak Anda pertimbangkan adalah mengizinkan tindakan melalui email. Agak rumit, tetapi saya menerapkan ini untuk klien yang membutuhkan pengguna "di luar" sistem mereka untuk melihat (hanya baca) bagian-bagian tertentu dari sistem. Sebagai contoh:

1. Setelah pengguna terdaftar, mereka memiliki akses penuh (seperti situs web biasa). Registrasi harus menyertakan email.
2. Jika data atau tindakan diperlukan dan pengguna tidak mengingat kata sandi mereka, mereka masih dapat melakukan tindakan dengan mengklik tombol " email saya untuk izin ", tepat di sebelah tombol " kirim " biasa.
3. Permintaan kemudian dikirim ke email dengan hyperlink yang menanyakan apakah mereka ingin tindakan itu dilakukan. Ini mirip dengan tautan email atur ulang kata sandi, tetapi alih-alih mengatur ulang kata sandi, ia melakukan tindakan satu kali .
4. Pengguna kemudian mengklik "Ya", dan itu menegaskan bahwa data harus ditampilkan, atau tindakan harus dilakukan, data terungkap, dll.

Seperti yang Anda sebutkan di komentar, ini tidak akan berfungsi jika email dikompromikan, tetapi alamat @joachim menjawab tidak ingin mengatur ulang kata sandi. Akhirnya, mereka harus menggunakan pengaturan ulang kata sandi, tetapi mereka dapat melakukannya pada waktu yang lebih nyaman, atau dengan bantuan administrator atau teman, sesuai kebutuhan.

Sebuah twist pada solusi ini adalah mengirimkan permintaan tindakan ke administrator tepercaya pihak ketiga. Ini akan bekerja paling baik dalam kasus-kasus dengan para lansia, yang cacat mental, sangat muda atau pengguna yang bingung. Tentu saja ini membutuhkan administrator tepercaya bagi orang-orang ini untuk mendukung tindakan mereka.

Salt-and-hash kata sandi pengguna seperti biasa. Saat masuk pengguna, izinkan kata sandi pengguna (setelah salting / hashing), tetapi juga mengizinkan apa yang dimasukkan oleh pengguna juga.

Hal ini memungkinkan pengguna untuk memasukkan kata sandi rahasia mereka, tetapi juga memungkinkan mereka untuk memasukkan versi kata sandi yang diasinkan / hash, yang akan dibaca oleh seseorang dari basis data.

Pada dasarnya, buat kata sandi asin / hash juga menjadi kata sandi "teks biasa".