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


1344

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.


155
Saya pikir dia tahu itu tidak baik. Dia masih mencari solusi terbaik di bawah persyaratan yang dinyatakan.
stefanw

33
Pada akhirnya, yang akan Anda lakukan adalah menerapkan kerentanan yang dapat dihindari dengan hati-hati.
benteng

20
@Michael Brooks - Saya ingin Anda tahu bahwa saya benar-benar setuju dengan CWE-257 dan akan dengan senang hati mengutip setiap kata demi kata setiap kali saya diminta membuat kata sandi yang dapat dipulihkan sebagai plaintext. Namun, pada kenyataannya, klien dan pengguna jarang tertarik pada peraturan NIST dan hanya ingin saya tetap melakukannya. 90% dari waktu saya dapat meyakinkan mereka sebaliknya tetapi dalam 10% dari waktu ketika saya tidak dapat saya mencoba untuk menentukan tindakan terbaik - dalam kasus-kasus tersebut CWE-257 menjadi abu di tangan saya (sayangnya).
Shane

81
@Vivi: "Nilai rendah" dari sistem sama sekali tidak ada hubungannya dengan masalah ini karena orang menggunakan kembali kata sandi mereka . Mengapa orang tidak dapat memahami fakta sederhana ini? Jika Anda memecahkan kata sandi pada beberapa sistem "nilai rendah", Anda mungkin akan memiliki beberapa kata sandi yang valid untuk sistem "bernilai tinggi" lainnya.
Aaronaught

20
Hal lain juga telah disinggung, yang baru saja saya sebutkan dalam aliran komentar untuk jawaban saya: Bagaimana Anda tahu bahwa orang yang meminta persyaratan ini dapat dipercaya? Bagaimana jika alasan "kegunaan" hanyalah façade yang menutupi maksud sebenarnya untuk mencuri kata sandi di beberapa titik di masa depan? Kenaifan Anda mungkin hanya merugikan jutaan pelanggan dan pemegang saham. Berapa kali harus pakar keamanan mengulangi ini sebelum akhirnya tenggelam: Ancaman keamanan paling umum dan paling serius selalu INTERNAL.
Aaronaught

Jawaban:


1037

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.


93
+1 untuk frasa sandi, yang saat ini tampaknya menawarkan keseimbangan terbaik antara kekuatan kata sandi dan daya ingat pengguna.
Aaronaught

197
Anda juga dapat membuat kalimat lengkap mis. <adjective> <noun> adalah <verb> <adverb>. Kucing hijau itu melompat dengan liar. punya daftar untuk kategori. dengan 1024 pilihan untuk masing-masing Anda memiliki 40 bit entropi.
Dominik Weber

28
+1 untuk mempertimbangkan penggunaan kembali kata sandi sebagai masalah kritis untuk menghindarinya
lurscher

57
"Pikirkan itu - jika pengguna perlu mengambil kata sandi, itu karena mereka sudah lupa" - belum tentu benar! Saya sering ingin mendapatkan kata sandi karena saya menggunakan laptop, dan saya TAHU mesin saya di rumah menyimpan kata sandi saya, atau itu ditulis di suatu tempat yang aman, dan saya tidak ingin memecahkannya dengan dikeluarkan dengan yang baru .
joachim

5
Pertanyaan dengan skor tertinggi pada situs IT Security SE yang baru membahas validitas perhitungan entropi ini. (Ya, secara teknis, ini berhubungan dengan xkcd yang terhubung dengan @Pieter.)
Pops

592

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.


124
@Aaronaught - Saya pikir itu adalah poin yang adil dan valid, tapi izinkan saya memelintirnya. Anda sedang mengerjakan proyek untuk sebuah perusahaan sebagai karyawan dan bos Anda mengatakan 'ini adalah persyaratan sistem kami' (untuk alasan apa pun). Apakah Anda meninggalkan pekerjaan yang penuh dengan kemarahan yang benar? Saya tahu bahwa ada kewajiban ketika saya dalam kendali penuh untuk bertanggung jawab - tetapi jika perusahaan memilih untuk mengambil risiko kegagalan audit atau pertanggungjawaban maka apakah tugas saya untuk mengorbankan pekerjaan saya untuk membuktikan suatu poin, atau apakah saya mencari yang TERBAIK dan cara TERLAMBAT untuk melakukan apa yang mereka katakan? Hanya bermain sebagai pendukung iblis ..
Shane

44
Saya bukan pengacara, tetapi pertimbangkan ini. Jika penyelia Anda memerintahkan Anda untuk melakukan sesuatu yang bertentangan dengan kepentingan perusahaan, seperti dengan memaparkannya pada pertanggungjawaban yang mudah dihindari, apakah tugas Anda untuk mematuhi atau menolak dengan sopan? Ya, mereka bos Anda, tetapi mereka memiliki bos sendiri, bahkan jika itu adalah investor. Jika Anda tidak pergi ke atas kepala mereka, kepala siapa yang akan berguling ketika lubang keamanan Anda dieksploitasi? Hanya sesuatu yang perlu dipertimbangkan.
Steven Sudit

68
Pengembang selalu berusaha mengatakan bagaimana pekerjaan kami jauh lebih sulit daripada yang lain karena kami mendapatkan persyaratan sampah yang berubah setiap saat. Nah, ini adalah contoh sempurna mengapa; profesi kita sangat membutuhkan tulang punggung. Profesi kami sangat perlu untuk dapat mengatakan "tidak, ini bukan persyaratan yang dapat diterima, ini bukan sesuatu yang bisa saya kembangkan dengan itikad baik, Anda mungkin klien / majikan saya, tetapi saya memiliki tanggung jawab profesional terhadap pelanggan dan masyarakat Anda, dan jika Anda ingin ini dilakukan maka Anda harus mencari di tempat lain. "
Aaronaught

36
@ sfussenegger: Anda tidak perlu tahu latar belakangnya. Itu tidak bisa diterima. Anda berasumsi bahwa klien 100% dapat dipercaya - bagaimana jika dia meminta persyaratan ini secara khusus sehingga dia dapat kabur dengan kata sandi nanti? Keamanan adalah salah satu dari beberapa item dalam pembangunan yang sedang diukir di batu. Ada beberapa hal yang tidak Anda lakukan, dan menyimpan kata sandi yang dapat dipulihkan adalah sepuluh di antaranya.
Aaronaught

37
Oke, mari kita lakukan penilaian risiko, di sini dan sekarang. "Jika Anda menyimpan kata sandi dalam bentuk yang dapat dipulihkan, Anda membuat risiko kata sandi yang tidak sepele dicuri. Kemungkinan juga bahwa beberapa pengguna akan menggunakan kata sandi yang sama untuk email dan rekening bank mereka. Jika kata sandi dicuri dan rekening bank dikuras, mungkin akan menjadi berita utama, tidak ada yang akan melakukan bisnis lagi dengan Anda, dan Anda kemungkinan akan dituntut keluar dari keberadaan. " Bisakah kita memotong omong kosong sekarang? Fakta bahwa Anda membawa kata "Nazi" ke dalam ini dengan jelas menunjukkan bahwa Anda tidak memiliki akal sehat.
Aaronaught

206

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).

34
-1 kata sandi tidak boleh "dienkripsi". Ini adalah pelanggaran terhadap CWE-257 cwe.mitre.org/data/definitions/257.html
rook

100
1. Pertanyaan menyatakan bahwa kata sandi harus dapat dipulihkan ke plaintext, jadi ini adalah persyaratan. 2. Saya menggunakan enkripsi asimetris di sini dan bukan enkripsi simetris. Kunci untuk mendekripsi tidak diperlukan untuk operasi sehari-hari dan dapat disimpan di brankas bank. Argumen dalam tautan ini valid, tetapi tidak berlaku untuk situasi ini.
stefanw

57
Benar, tetapi bisakah Anda setuju bahwa dengan persyaratan ini adalah cara paling bertanggung jawab untuk melakukannya? Anda dapat memukul saya sepanjang hari dengan CWE-257 Anda, itu tidak akan mengubah masalah menarik menyimpan dan bekerja dengan kredensial dengan aman dan dapat memulihkannya ke bentuk aslinya jika diperlukan.
stefanw

10
Agen Pemulihan Windows juga merupakan contoh yang buruk di sini, karena berkaitan dengan enkripsi aktual, bukan manajemen kata sandi. Kunci enkripsi tidak sama dengan kata sandi; peraturan dan praktik sekitarnya masing-masing yang benar-benar berbeda. Enkripsi dan otentikasi tidak sama. Enkripsi adalah untuk privasi - kunci digunakan untuk melindungi data . Otentikasi adalah untuk identitas , di mana kuncinya adalah data (itu adalah salah satu faktor dalam proses otentikasi). Jadi saya ulangi, enkripsi dan otentikasi tidak sama. Anda tidak dapat secara sah menerapkan prinsip yang satu ke yang lain.
Aaronaught

16
+1 Di mana gunanya bersikeras bersikeras pada CWE-257? Ini kelemahan (CWE), bukan kerentanan (CVE). Membandingkan kata sandi yang dapat dipulihkan dengan buffer overflows membandingkan apel dan jeruk. Cukup pastikan klien memahami masalahnya (biarkan dia menandatangani sesuatu yang mengatakannya - jika tidak, dia mungkin tidak ingat apa pun jika dipertanyakan) dan lanjutkan. Selain itu, langkah-langkah keamanan yang diperlukan tergantung pada nilai sistem dan potensi risiko serangan. Jika penyerang yang berhasil hanya dapat membatalkan beberapa langganan buletin, tidak ada alasan untuk berdebat tentang masalah apa pun.
sfussenegger

133

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.


2
Log server web tidak dihitung di pengadilan? Atau dalam hal ini mereka akan dianggap palsu juga?
Vinko Vrsalovic

10
@ Vinko Vrsalovic, log server Web HARUS diperhitungkan di pengadilan, untuk melakukannya, Anda perlu membuktikan tidak ada penolakan, bukti keaslian, rantai bukti, dll. Yang mana log server web jelas tidak.
AviD

7
Persis. Pemasok harus membuktikan bahwa hanya klien yang dapat melakukan transaksi itu. Log server web tidak melakukan itu.
Marquis of Lorne

Tidak semua kata sandi sebenarnya diperlukan untuk "transaksi", jadi untuk berbicara. Katakanlah situs web ini untuk mengembangkan daftar bookmark halaman web. Dalam hal ini batas tanggung jawab (yang biasanya disebut dalam T&C ketika mendaftar ke situs web) adalah nol, karena tidak ada transaksi keuangan. Jika situs web tidak memiliki tindakan yang memengaruhi orang lain, paling banyak, data akan hilang bagi pengguna yang diretas. Perusahaan dilindungi oleh T&C.
Sablefoste

1
@Sablefoste Di situs web itu. Jika pengguna menggunakan kata sandi yang sama di tempat lain, Anda berisiko bocor kredensial pribadinya. Jika Anda tidak pernah terlibat dalam latihan, Anda tidak dapat menyebabkan masalah.
Marquis of Lorne

94

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:

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.


8
@jimmycakes - Ini adalah hal yang baik untuk dilakukan pada sistem keamanan rendah, tetapi jika Anda menyimpan data yang bernilai tinggi maka Anda harus berasumsi bahwa email orang tersebut sudah dikompromikan dan mengirimi mereka tautan masuk langsung membahayakan sistem Anda. 1 untuk menjawab pertanyaan saya dengan alternatif yang layak, tetapi menunjukkan cacat dalam logika secara keseluruhan. Saya tidak ingin Payppal mengirim tautan masuk langsung EVER. Mungkin terdengar paranoid tetapi saya selalu menganggap akun email saya rusak - itu membuat saya jujur. ;)
Shane

Tentu - Saya berharap bank saya paling tidak memberi saya panggilan telepon dan memverifikasi identitas saya sebelum membiarkan saya mengatur ulang ( tidak memulihkan) kata sandi saya. Apa yang saya uraikan di sini adalah standar minimum mutlak keamanan kata sandi yang saya harapkan dari situs web mana pun, di mana saja.
jammycakes

1
Mengabaikan bank atau paypal yang tidak akan memiliki batasan yang Anda tetapkan; Jika Anda menganggap email mereka dikompromikan, bagaimana mungkin ada metode online? Jika Anda mengirim email kata sandi yang dihasilkan, bagaimana itu lebih aman?
Peter Coulton

Saya tidak berbicara tentang mendapatkan kata sandi satu individu, saya berbicara tentang mendapatkan beberapa kata sandi dari database. Jika suatu sistem menyimpan kata sandi yang dapat dipulihkan ke teks biasa, peretas berpotensi menulis skrip untuk mengekstrak semua kata sandi dari basis data Anda.
jammycakes

Saya ingin tahu tentang mengirim tautan / kata sandi dalam email, melalui jaringan dalam bentuk biasa melalui simpul jaringan yang tidak dikenal ...
Jakub

55

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.


4
@ John - Saya pikir itu adalah solusi yang sangat layak. Bersiaplah untuk dinyalakan karena ancaman internal! Anda tahu, jika saya melakukan ini dengan reset kata sandi menengah (tech menetapkan kata sandi secara manual sebagai mesaure sementara dan memberitahu Mabel untuk mengetikkan 1234 sebagai kata sandinya) maka itu mungkin akan bekerja dengan baik pada sistem yang tidak berisi data penting. Jika itu adalah lingkungan dengan keamanan tinggi, maka kami memiliki masalah di mana layanan cust dapat mengatur kata sandi CEO menjadi 1234 dan masuk secara langsung. Tidak ada solusi yang sempurna tetapi yang ini berfungsi dalam banyak hal. (+1)
Shane

5
Saya hanya memperhatikan jawaban ini. @ Shane, saya tidak mengerti mengapa Anda meramalkan "ancaman internal". Kemampuan untuk mengubah kata sandi bukanlah kelemahan utama; masalahnya adalah kemampuan untuk menemukan kata sandi yang kemungkinan akan digunakan untuk layanan lain - surelnya, banknya, situs belanja daringnya yang menyimpan informasi CC-nya. Kelemahan itu tidak terwujud di sini; jika Bob menyetel ulang kata sandi Mabel dan memberitahukannya melalui telepon, itu tidak memberinya akses ke akun lainnya. Namun, saya akan memaksakan daripada "menyarankan" pengaturan ulang kata sandi saat masuk.
Aaronaught

@Aaronaught - Saya benar-benar mengerti maksud Anda, tetapi yang saya pikirkan adalah saat-saat bahkan orang-orang layanan pelanggan dikunci dari area tertentu dari suatu sistem (seperti penggajian, akuntansi, dll.) Dan memungkinkan mereka untuk secara langsung mengatur kata sandi adalah masalah keamanan dalam dan dari dirinya sendiri. Saya melihat maksud Anda bahwa jenis sistem yang saya ajukan pertanyaan tentang ini sebagian besar berbeda dari sistem akuntansi internal. Kami mungkin dapat melakukan diskusi yang sangat berbeda tentang sistem internal berpemilik dan keamanan kata sandi di dalamnya.
Shane

1
@ Shane: Maka pertanyaannya menjadi semakin tidak masuk akal. Saya berasumsi bahwa Anda ingin seseorang membacanya dengan kata sandi melalui telepon. Jika Anda ingin mengirim email kepada pengguna kata sandi mereka melalui beberapa sistem swalayan otomatis maka Anda mungkin juga membuang kata sandi sepenuhnya karena kata sandi itu "dilindungi" dengan sesuatu yang jauh lebih lemah. Mungkin Anda harus lebih spesifik tentang skenario kegunaan seperti apa yang ingin Anda dukung. Mungkin analisis itu selanjutnya akan menunjukkan kepada Anda bahwa kata sandi yang dapat dipulihkan bahkan tidak diperlukan.
Aaronaught

4
Kode yang disediakan oleh orang yang mendukung tidak harus berupa kata sandi baru. Itu bisa saja berupa kode satu kali yang membuka fungsi pengaturan ulang kata sandi.
kgilpin

42

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!


8
Dan, tentu saja, Anda dapat menggunakan teknik pemisahan rahasia untuk meminta beberapa orang dari perusahaan Anda untuk dekripsi. Tetapi tidak ada satupun yang memenuhi persyaratan asli untuk dapat mengirimkan kata sandi kepada pengguna atau meminta pendukung telepon tingkat pertama yang menjalankannya melalui proses masuk.
Christopher Creutzig

27

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.

Saya menanggapi komentar di sini, turun dalam tanggapan saya, karena itu cukup panjang - saya pikir penting untuk meninjau analisis dan diskusi masalah yang diangkat. stackoverflow.com/questions/2283937/…
AviD

Apakah pengguna mendapat manfaat dari ditampilkannya kata sandi di layar? Menurut pendapat saya - pasti ya! Setiap kali saya mendapatkan kata sandi tidak jelas dari internet yang disediakan, saya berterima kasih kepada Apple saya dapat membuatnya terlihat sehingga saya tidak perlu mengetik ulang 100 kali kesakitan. Saya bisa membayangkan bagaimana perasaan orang cacat.
Dmitri Zaitsev

1
Mengapa menampilkan kata sandi tidak jelas lebih baik daripada membiarkan Anda memilih kata sandi baru yang dapat Anda ingat?
Yakub

@ Jacob: Lebih banyak entropi?
Alexander Shcheblikin

25

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.


5
Kata sandi yang dibagikan antara situs bernilai rendah Anda dengan aset "tidak" mahal dan Facebook / GMail / bank Anda adalah aset mahal, bahkan di situs bernilai rendah.
jammycakes

3
Saya pikir masalahnya di sini adalah bahwa kelompok pengguna yang disebutkan di atas cenderung menggunakan kata sandi yang sama untuk semua aplikasi dari berbagai tingkat keamanan (dari perbankan hingga blog resep). Jadi pertanyaannya adalah, apakah itu tanggung jawab pengembang untuk melindungi pengguna bahkan dari diri mereka sendiri. Saya pasti akan mengatakan, ya!
ercan

7
Maaf, tapi identitas itu sendiri adalah aset bernilai tinggi, titik. Tidak ada pengecualian, tidak ada alasan. Tidak peduli seberapa kecil dan tidak penting menurut Anda situs Anda. Dan kata sandi yang dibagikan adalah identitas jika itu memungkinkan peretas masuk ke akun Facebook, akun Gmail, rekening bank, dll. Pengguna Anda tidak ada hubungannya dengan semantik, tetapi itu semua berkaitan dengan konsekuensi. Tanyakan saja kepada siapa saja yang terkena serangan hacker seperti ini: theregister.co.uk/2009/08/24/4chan_pwns_christians
jammycakes

2
@ Jacob, di dunia apa klien Anda akan dituntut karena akun Erma di sistem lain telah dikompromikan? Bahkan diberi kelalaian besar di pihak klien Anda (yang BUKAN diberikan, seperti yang saya uraikan), dan SELESAI fakta bahwa TIDAK ADA CARA untuk membuktikan bahwa sistem lain dilanggar karena Anda, tidak ada kedudukan hukum yang memungkinkan untuk klaim segala bentuk kerusakan dari satu sistem di sistem lain. Itu akan diusir dari pengadilan dengan prasangka, dan menemukan penggugat dalam penghinaan. Namun, Erma mungkin bersalah karena melanggar banyak Ketentuan Layanan ...
AviD

5
@ Jacob, itu sangat salah. Hanya karena kata sandinya sama (yang jelas-jelas akan melanggar ToS Anda dan kebijakan keamanan mereka), mereka tidak memiliki kedudukan hukum untuk melegalkan keduanya. Thats bahkan LUAR fakta bahwa MEMBERIKAN itu akan sangat mustahil. Selain itu, saya juga akan menunjukkan bahwa TIDAK ADA HUKUM yang mewajibkan perusahaan secara acak untuk tidak melakukan praktik keamanan yang lemah, kecuali jika peraturan tertentu relevan. Dan di atas semua itu, kata sandi dienkripsi (!), Sehingga kelemahannya jauh dari kesimpulan yang hilang.
AviD

21

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.


Anda tahu, saya telah menggunakannya dalam beberapa situasi (biasanya ini adalah jalan tengah saya), tetapi saya telah meminta orang mengatakan kepada saya bahwa pengguna akhir tidak akan mendapatkan interaksi dan bahwa dukungan harus dapat 'memberi tahu mereka kata sandi 'karena keadaan dalam model bisnis itu'. Saya setuju bahwa meskipun mungkin ini lebih disukai.
Shane

Anda dapat selalu memberi tahu klien Anda tentang risiko DB jatuh ke tangan jahat dan mereka mendapatkan publisitas kata sandi yang dicuri ... Ada banyak contoh di sekitar.
Oded

6
Minta mereka untuk keluar dari "desain", dengan klausul tambahan bahwa mereka tidak dapat menuntut Anda jika apa yang Anda peringatkan kepada mereka memang terjadi ... Setidaknya Anda menutupi diri Anda sendiri.
Oded

4
-1 password tidak boleh "dienkripsi" Ini adalah pelanggaran terhadap cwe-257 cwe.mitre.org/data/definitions/257.html
benteng

34
@Michael Brooks: Tidak perlu downvote dan salin-tempel komentar yang sama berulang kali; kita semua sadar bahwa ini adalah praktik buruk. Shane menyatakan bahwa ia tidak memiliki pengaruh dalam masalah ini, dan karenanya hal terbaik berikutnya sedang diusulkan.
Johannes Gorset

13

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.


5
Sebagian besar pengguna tidak memiliki kunci PGP (saya masih belum punya; setelah 20 tahun di industri, saya tidak pernah merasa perlu), dan itu bukan proses tanpa gesekan untuk mendapatkannya. Lebih lanjut, kunci pribadi sebenarnya hanyalah proxy untuk kata sandi yang sebenarnya. Dengan kata lain kata sandi untuk kata sandi; itu kura-kura sepanjang jalan.
Robert Harvey

1
@RobertHarvey Tujuannya adalah untuk memungkinkan pengguna untuk mengambil kata sandi mereka tanpa mengizinkan karyawan situs atau peretas untuk mendapatkannya. Dengan mengharuskan proses pengambilan terjadi di komputer pengguna sendiri, Anda memberlakukan ini. Mungkin ada alternatif untuk PGP yang bisa mencapai hal yang sama. Kura-kura sepanjang jalan mungkin (mungkin beberapa gajah di sepanjang jalan), tapi saya tidak melihat cara lain. Untuk populasi umum (tidak mungkin ditargetkan secara individual) memiliki kata sandi Anda di atas kertas, dan tidak dapat mengambilnya dari layanan, akan lebih aman daripada kita saat ini
Nicholas Shanks

Saya suka karena memaksa semua orang untuk memiliki kunci publik PGP, yang anehnya, hal yang sangat etis untuk dilakukan.
Lodewijk

Anda bisa menghasilkan satu dan memberikannya kepada pengguna.
My1

@RobertHarvey Anda mungkin benar bahwa ini "bukan proses tanpa gesekan", tetapi ini bisa menjadi layanan tambahan untuk pengguna listrik, yang dapat diabaikan oleh pengguna biasa. Adapun argumen tentang PK menjadi "kata sandi untuk kata sandi", ingatlah bahwa secara teori bisa demikian untuk banyak kata sandi; Anda mungkin menggunakan kata sandi yang berbeda untuk layanan yang berbeda, dan mengenkripsi semuanya menggunakan kunci yang sama. Maka PK akan lebih berharga daripada hanya satu kata sandi. Mungkin secara abstrak sebanding dengan pengelola kata sandi (?). Tidak segera jelas bagi saya apa konsekuensi ini mungkin terjadi ...
Kjartan

12

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


4
@sneg - Ya, saya orang yang sangat meyakinkan, tapi kadang-kadang itu bos dan kadang-kadang pelanggan jadi saya tidak selalu memiliki pengaruh yang saya butuhkan untuk meyakinkan mereka satu atau lain cara. Saya akan berlatih di cermin lagi ..;)
Shane

Untuk meyakinkan Anda tidak benar-benar membutuhkan pengaruh apa pun selain kompetensi dan keterampilan komunikasi Anda. Jika Anda tahu cara yang lebih baik dalam melakukan sesuatu tetapi orang tidak mendengarkan ... Pikirkan tentang hal ini.
z-boss

7
@ z-boss - Rupanya Anda belum pernah bekerja dengan / untuk beberapa orang yang pernah bekerja dengan saya. Terkadang tidak masalah jika lidah Anda berlapis emas dan Anda dapat memprogram ulang Google Chrome dalam sehari (yang bisa dibilang benar-benar membuatnya berguna) mereka masih tidak mau bergerak.
Shane

11

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)
  • 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).


9

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.


10
Jawaban Anda sepenuhnya mengabaikan bahwa kata sandi digunakan kembali di beberapa situs / layanan, yang merupakan inti dari topik ini dan alasan mengapa kata sandi yang dapat dipulihkan dianggap sebagai kelemahan serius. Seorang profesional keamanan tidak mendelegasikan keputusan keamanan kepada klien non-teknis; seorang profesional tahu bahwa tanggung jawabnya melampaui klien yang membayar dan tidak menawarkan opsi dengan risiko tinggi dan tanpa imbalan. -1 untuk kata-kata kasar yang berat pada retorika dan sangat ringan pada fakta - dan bahkan tidak benar-benar menjawab pertanyaan.
Aaronaught

4
Sekali lagi, Anda sepenuhnya mengabaikan penilaian risiko. Untuk menggunakan argumen Anda, Anda tidak bisa berhenti hanya pada hash 1 arah. Anda juga harus menyertakan persyaratan kompleksitas, panjang kata sandi, pembatasan penggunaan kembali kata sandi, dan sebagainya. Berargumen bahwa pengguna akan menggunakan kata sandi bodoh atau menggunakan kembali kata sandi bukanlah pembenaran bisnis yang memadai jika sistemnya tidak relevan dan terus terang, saya memang menjawab pertanyaan itu. Jawaban singkatnya: dorongan untuk menggunakan implementasi std, dokumentasikan keberatan Anda jika Anda ditolak dan lanjutkan.
Thomas

7
Dan lagi Anda mengulangi canard bahwa tidak ada yang penting untuk sistem bernilai rendah! Nilai kata sandi pengguna tidak ada hubungannya dengan nilai akun pengguna di sistem Anda. Ini rahasia , dan yang harus selalu Anda simpan. Saya berharap saya bisa memberi -1 lagi untuk komentar yang menunjukkan bahwa Anda masih tidak mengerti masalah di sini.
Aaronaught

5
Penilaian risiko adalah masalah inti. Penggunaan kembali kata sandi hanyalah salah satu masalah potensial dalam serangkaian masalah yang jauh lebih besar. Mengapa tidak meminta bantuan? Mengapa tidak mengharuskan orang tersebut mengemudi ke kantor Anda untuk masuk? Tanpa penilaian risiko yang masuk akal, tidak ada cara untuk menjawab pertanyaan-pertanyaan ini. Di dunia Anda, semuanya adalah risiko sehingga setiap sistem memerlukan keamanan login tingkat FBI. Itu sama sekali bukan cara dunia nyata bekerja.
Thomas

7
Satu-satunya hal yang jelas di sini adalah bahwa seluruh argumen Anda tidak lebih dari kesalahan Slippery Slope dan bahwa Anda mencoba untuk mengarahkan pembaca dengan kata kunci seperti "penilaian risiko" untuk menutupi fakta itu. Yakinlah sistem apa pun yang digunakan "FBI" akan jauh lebih aman daripada hash bcrypt dan panjang kata sandi minimum. Jika membutuhkan sistem otentikasi standar industri membuat saya "fanatik keamanan", maka saya kira saya seorang fanatik; secara pribadi, itu sakit aku tahu bahwa ada orang di luar sana yang bersedia mengorbankan MY keamanan untuk uang. Itu tidak etis .
Aaronaught

8

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


Pengguna juga dapat menjawab pertanyaan dengan cara yang berbeda. Beberapa pertanyaan meminta jawaban yang lebih panjang yang mudah diulang lagi nanti.
Monoman

5
Pertanyaan keamanan adalah ide yang buruk. Bagaimana Anda membuat ibu Anda mengubah nama gadisnya begitu informasi dilanggar? Juga lihat Keamanan Teknik Peter Gutmann .
jww

7

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.


Menghapus sementara faktor dari sistem otentikasi multi-faktor memang merupakan cara yang jauh lebih aman untuk mereset kata sandi daripada sistem "pertanyaan rahasia" yang terlihat di banyak situs. Tetapi untuk menyimpan kata sandi dalam format yang dapat dipulihkan, saya tidak yakin bagaimana ini membantu, kecuali jika Anda entah bagaimana menggunakan faktor kedua untuk mengenkripsi atau mengaburkan yang pertama, dan saya tidak yakin bagaimana itu mungkin dengan sesuatu seperti SecurID. Bisakah Anda jelaskan?
Aaronaught

@Aronaught Apa yang saya katakan adalah, jika Anda 'diharuskan' memiliki kata sandi yang dapat dipulihkan, risiko yang melekat lebih rendah jika bukan satu-satunya faktor otentikasi, dan juga lebih mudah bagi pengguna akhir, jika alur kerja menggunakan kembali faktor-faktor yang dia sudah memiliki dan memiliki akses saat ini ke, daripada mencoba mengingat mungkin juga lupa 'jawaban rahasia' atau menggunakan tautan yang dibatasi waktu atau kata sandi sementara, keduanya dikirim melalui saluran yang tidak aman (kecuali jika Anda menggunakan S-MIME dengan sertifikat klien, atau PGP, keduanya mengeluarkan biaya khusus untuk pengelolaan asosiasi yang benar dan kedaluwarsa / substitusi)
Monoman

1
Saya kira semua itu benar, tetapi risiko kompromi publik minimal untuk memulainya; masalah yang lebih serius dengan kata sandi yang dapat dipulihkan adalah keamanan internal dan berpotensi memungkinkan karyawan yang tidak puas untuk pergi dengan kata sandi email dari ribuan pelanggan, atau CEO yang bengkok untuk menjualnya kepada phisher dan spammer. Otentikasi dua faktor sangat bagus dalam memerangi pencurian identitas dan tebak kata sandi tetapi tidak benar-benar membawa banyak ke meja sejauh menjaga basis data kata sandi yang sebenarnya aman.
Aaronaught

5

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


5

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.


4

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.


GUID adalah ide yang buruk, hampir tidak cukup acak dan mudah di-bruteforce. ada masalah lain dengan ini, lihat stackoverflow.com/questions/664673/…
AviD

3

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.


Saya tidak akan menganggap bahwa email lebih aman daripada sistem lainnya. Meskipun ini tidak mengambil masalah hukum dari tangan saya, masih ada masalah seseorang kehilangan / menghapus email mereka dan sekarang saya kembali ke titik awal.
Shane

Berikan pengaturan ulang kata sandi dan emailkan kata sandi plaintext. Saya pikir itu yang paling bisa Anda lakukan pada subjek, tanpa menyimpan salinan kata sandi sendiri.
casraf

Ini ide yang sangat mengerikan. Keduanya tidak efektif (banyak pengguna benar-benar menghapus email setelah membaca) dan lebih buruk daripada apa yang Anda coba lindungi (karena email tidak terenkripsi secara default dan melewati jaringan yang tidak dapat dipercaya). Lebih baik menyarankan kepada pengguna bahwa mereka membuat catatan kata sandi sendiri, setidaknya mengirim sendiri email informasi tidak pernah berjalan lebih jauh dari server email, tidak di seluruh Internet!
Ben Voigt

3

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.


Selama Anda memiliki alamat email yang dikaitkan dengan kata sandi, dan kata sandi itu dapat dipulihkan, Anda berpotensi membocorkan kata sandi untuk alamat email itu karena penggunaan kembali kata sandi. Itu sebenarnya perhatian utama di sini. Tidak ada informasi pengidentifikasi pribadi lain yang penting.
Aaronaught

1
Anda benar-benar kehilangan maksud saya. Jika Anda tidak benar-benar membutuhkan kata sandi, jangan kumpulkan. Pengembang sering terjebak dalam mode berpikir "itulah yang kami lakukan". Kadang-kadang membantu untuk membuang gagasan yang sudah dikandung sebelumnya.
anopres

2

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?


Kunci master akan sangat berisiko, staf pendukung akan memiliki akses ke setiap akun - dan begitu Anda memberikan kunci itu kepada pengguna, mereka kemudian memiliki kunci utama dan akses ke semuanya.
Carson Myers

Kunci master adalah ide yang mengerikan, karena jika seseorang menemukannya (atau secara tidak sengaja diungkapkan kepada mereka), mereka dapat mengeksploitasinya. Karena mekanisme pengaturan ulang kata sandi per akun jauh lebih disukai.
Phil Miller

Saya ingin tahu, saya pikir Linux secara default memiliki akun pengguna super dengan akses tingkat root? Bukankah itu "kunci utama" untuk mengakses semua file di sistem?
JonnyBoats

@JonnyBoats Ya, benar. Itu sebabnya Unix modern seperti Mac OS X menonaktifkan akun root.
Nicholas Shanks

@NicholasShanks: Nonaktifkan akun root, atau nonaktifkan login interaktif pada akun root? Masih banyak kode berjalan dengan izin tidak terbatas.
Ben Voigt

2

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.


1

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.


3
Jika server aplikasi dapat mengaksesnya, maka siapa pun dapat mengakses server aplikasi (baik itu peretas atau orang jahat). Ini menawarkan nol keamanan tambahan.
Molf

1
Keamanan tambahan di sini adalah bahwa DB server aplikasi tidak menyimpan kata sandi (sehingga peretasan kedua diperlukan - ke kata sandi DB), dan kata sandi DB dapat terlindungi dengan lebih baik terhadap aktivitas tidak teratur, karena Anda mengontrol aksesibilitas layanan pengambilan kata sandi. sehingga Anda dapat mendeteksi pengambilan data massal, mengubah kunci pengambilan SSH setiap minggu, atau bahkan tidak mengizinkan pengambilan pass otomatis, dan melakukan semuanya secara manual. Solusi ini juga cocok dengan skema enkripsi internal lainnya (seperti kunci publik + privat, garam, dll.) Untuk kata sandi DB.
Amir Arad

1

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.


1

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".


Menurut Anda mengapa perlu membandingkan apa yang dimasukkan pengguna secara langsung dengan kata sandi hash yang disimpan dalam database? Fungsi apa yang memberi Anda? Juga, ketika melakukan ini, sangat penting untuk menerapkan fungsi perbandingan waktu-konstan antara kata sandi yang dimasukkan pengguna dan kata sandi hash dari database. Kalau tidak, hampir sepele mungkin untuk menentukan kata sandi hash berdasarkan perbedaan waktu.
Artjom B.

1
@ArtjomB. Pertanyaannya bertanya bagaimana melindungi kata sandi pengguna sementara juga memungkinkan dukungan pelanggan (CS) untuk berbicara / mengirim email kepada pengguna dengan memasukkan kata sandi yang dilupakan. Dengan membuat versi hash dapat digunakan sebagai kata sandi teks biasa, CS dapat membacanya dan meminta pengguna menggunakannya sebagai pengganti kata sandi yang dilupakan. CS juga dapat menggunakannya untuk masuk sebagai pengguna dan membantu mereka melalui tugas. Ini juga memungkinkan pengguna yang merasa nyaman dengan sistem kata sandi lupa otomatis untuk dilindungi, karena kata sandi yang mereka masukkan dan gunakan di-hash.
Eliott

Saya melihat. Saya belum membaca pertanyaan secara keseluruhan. Penggunaan perbandingan waktu-konstan masih diperlukan untuk mencegah kerusakan sepele dari keseluruhan sistem.
Artjom B.
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.