Bagaimana jika klien membutuhkan kemampuan untuk mengambil kata sandi?

Saat ini saya mewarisi aplikasi di tempat kerja dan saya kecewa, saya menyadari bahwa kata sandi pengguna yang disimpan dalam database dienkripsi menggunakan fungsi enkripsi in-house, yang juga mencakup kemampuan untuk mendekripsi.

Jadi semua yang perlu dilakukan seseorang adalah menyalin tabel pengguna dan menyalin rakitan enkripsi (siapa pun yang memiliki akses produksi basis data) dan kemudian mereka akan memiliki akses ke 100.000 alamat email dan kata sandi potensial untuk mereka.

Saya mencoba menjelaskan kepada bisnis mengapa ini bukan ide yang baik, tetapi konsep keamanan tampaknya melampaui kepala mereka karena mereka tidak berpikiran teknis (ini untuk pemerintah). Plus sebenarnya ada fungsionalitas yang ada dalam aplikasi untuk pengguna admin untuk mengambil kata sandi pengguna untuk login sebagai mereka dan melakukan hal-hal (yang mereka katakan, mereka butuhkan).

Jadi mereka tidak mengerti implikasi keamanan. Dan untuk menerapkan kebijakan keamanan yang lebih kuat (kata sandi hashing sehingga tidak dapat dengan mudah diambil), saya harus menghapus fungsionalitas yang ada untuk mereka.

Apa yang harus saya lakukan? Saya tidak membangun sistem kata sandi sejak awal, jadi saya tidak bisa disalahkan kalau ada yang salah. Di sisi lain, saya merasa tidak enak dan saya juga tidak ingin memiliki akses ke 100.000 login email potensial.

Terapkan fungsi yang mereka butuhkan dengan cara yang aman. Administrator yang masuk sebagai pengguna lain dapat diimplementasikan tanpa mereka mengetahui kata sandi pengguna. Mereka dapat masuk sebagai diri mereka sendiri, dan kemudian memiliki fungsi 'perubahan-identitas' yang tersedia.

Mengamankan basis data kata sandi bukan masalah bisnis, ini masalah teknis. Tidak melakukannya adalah bug. Jika bisnis menganggap keamanan sebagai pertukaran fungsi, keamanan akan hilang. Anda seharusnya tidak memberi mereka alasan untuk memikirkannya dengan cara ini.

Anda perlu meyakinkan mereka bahwa mereka benar-benar tidak perlu bertanggung jawab secara sipil jika server mereka dibobol. Mereka juga tidak memerlukan reaksi dari basis pengguna yang mengetahui bahwa mereka lalai.

Kadang-kadang ada kasus yang jelas di mana salah satu pihak salah dan yang lain benar. Ini adalah salah satu dari saat-saat itu.

Lihatlah apa yang baru saja terjadi pada Sony. Selain itu, situs kami diretas baru-baru ini, dan salah satu hal yang mencegahnya menjadi bencana yang tidak dikurangi adalah bahwa kami menggunakan fungsi hashing satu arah (relatif) baik (SHA512). Kami telah beralih ke bcrypt untuk mencegah serangan brute force / dictionary (atau paling tidak membuatnya tidak bisa dilakukan). Saya sama sekali tidak menemukan hal lain yang masuk akal.

Fakta: orang menggunakan kata sandi yang sama di banyak situs

Bos Anda mungkin tidak menyadari bahwa orang sering menggunakan kata sandi tunggal (atau set yang sangat terbatas) untuk semua jenis layanan (termasuk perbankan atau Facebook dan sejenisnya). Jika pengguna dapat mengubah kata sandi mereka di sistem Anda, kemungkinan besar mereka menggunakan kata sandi yang sama seperti di tempat lain.

Jika bos Anda berpikir bahwa akses kata sandi ini bukan masalah, Anda juga harus memberi tahu mereka fakta ini dan mungkin mereka akan mulai berpikir berbeda. Sekalipun aplikasi Anda berada di belakang tembok dan tidak dapat diakses publik, itu dapat menimbulkan ancaman keamanan pada layanan online lainnya. Nama pengguna (terutama saat email) agak mudah ditebak. Saya tidak bisa membayangkan betapa lucunya login ke akun Facebook bos dan meletakkan sesuatu di dinding mereka.

Kata sandi pengguna harus selalu diperlakukan sebagai privasi tingkat atas / informasi rahasia yang hanya dapat diakses oleh sejumlah kecil orang. Yang terbaik adalah menghindari menyimpan informasi yang tidak stabil tersebut. Dan bahkan ketika Anda melakukannya, Anda harus diberikan setiap akses tunggal ke informasi ini. Seperti mendapatkan kertas rahasia dari brankas yang sangat aman yang hanya bisa dibuka dengan beberapa kunci. Jadi orang tahu siapa yang telah diberikan akses dan kapan.

Bagaimana cara menerapkan delegasi akun

Delegasi akun dalam aplikasi Anda harus dilakukan secara berbeda.

1. Admin harus login sebagai diri mereka sendiri dan kemudian
2. baik (karena mereka adalah pengguna istimewa)
   • masukkan hanya UserName atau
   • pilih pengguna tertentu dari daftar untuk login sebagai mereka

Ini pasti tidak boleh dilakukan dengan masuk ke kombinasi UserName + Password .

Memang benar bahwa layar baru harus dikembangkan untuk memungkinkan masuknya delegasi, tapi tetap saja.

Mengapa log masuk yang didelegasikan lebih baik?

Anda juga dapat memberikan fungsionalitas tambahan yang akan memperjelas bahwa beberapa tindakan telah dilakukan oleh Admin atas nama beberapa pengguna (yang tidak dapat Anda ketahui sekarang karena Admin bertindak sebagai Dewa dan masuk sebagai siapa pun dan mungkin melakukan hal-hal yang dapat merugikan reputasi karyawan sesungguhnya).

Anda harus setuju bahwa orang membuat kesalahan. Admin juga orang. Dan jika mereka melakukan kesalahan atas nama orang lain, mereka akan mencoba menyalahkan mereka. Saya 100% yakin tentang itu. Ini akan membuatnya lebih aman bagi pengguna non-admin sehingga reputasi dunia nyata mereka tidak akan menderita kesalahan orang lain.

Anda tidak menyebutkan apa yang dikerjakan aplikasi. Jika itu adalah aplikasi paspor, penuh dengan informasi pencurian identitas yang harus dilindungi, layak mendapatkan perlindungan maksimal. Tetapi jika itu "katakan padaku kecelakaan lalu lintas di rute pulang saya" apa konsekuensi dari pelanggaran kata sandi? Beberapa sistem yang saya tulis bahkan tidak memiliki kata sandi - Anda cukup memasukkan email atau nomor siswa Anda atau pengenal lain yang sering orang ketahui tentang satu sama lain, dan pemilik sistem menghargai kemudahan penggunaan dan ketidakmampuan untuk dikunci. mengetahui kemungkinan pelanggaran privasi jika orang saling menyamar. Saya juga tidak punya masalah dengan itu. Mengapa saya perlu kata sandi untuk mengatur jadwal sesi pilihan saya di konferensi, misalnya?

Jadi jika saya dibawa untuk ditinjau kode dan Anda mengangkat ini kepada saya, di situlah kita akan mulai. Apa yang kamu lindungi? Apa konsekuensi negatif dari satu orang yang berhasil masuk sebagai orang lain? Apa konsekuensi negatif dari data yang disimpan semua orang yang terpapar? Mungkin mereka mengerikan. Anda akan membuat daftar untuk saya. Lalu, apa konsekuensi dari orang-orang yang tidak dapat mengklik "email saya kata sandi saya" tetapi harus mengklik "setel ulang kata sandi saya"? Apakah mereka akan berhenti menggunakan situs ini? Dan bagaimana dengan staf yang masuk sebagai orangnya? Apakah itu menghemat waktu, uang, kehilangan penjualan atau apa?

Bagian terakhir dari kisah biaya / manfaat, dan yang Anda dapatkan hanya jika ada perbedaan yang sangat besar antara negatif yang Anda hadapi sekarang dan negatif yang akan Anda dapatkan ketika Anda menghapus fungsionalitas, adalah biaya untuk memperbaikinya. Apakah saya akan menghabiskan satu juta untuk menghindarkan saya dari kemungkinan mendapat seribu dolar? Tidak. Bagaimana sebaliknya? Tergantung pada kemungkinannya, saya kira, tetapi jawaban pertama saya adalah ya.

ps - pemerintah Kanada menyiarkan situs paspor Anda yang memiliki ID di URL: jika Anda mengedit URL dengan ID yang berbeda, Anda melihat formulir yang sudah setengah jadi dari beberapa warga negara acak lainnya. Dan saya memiliki klien yang masuk sebagai pelanggan mereka untuk tujuan layanan pelanggan untuk kebahagiaan umum, jadi saya melihat sisi baiknya, meskipun saya tidak akan setuju jika data di balik kata sandi itu sebenarnya penting bagi orang asing.

Itu mungkin melanggar hukum dan bisa membuka mereka untuk dituntut. Jika mereka menyimpan segala jenis informasi pribadi tentang pengguna, atau sistem berinteraksi dengan sistem lain sebagai pengguna, Anda mungkin perlu memeriksa untuk melihat apakah sistem berada di bawah Undang-undang atau undang-undang Privasi Negara atau Federal. yaitu. Sarbanes / Oxley, California OOPA, dll.

Selain potensi masalah hukum, Anda juga dapat menunjukkan bahwa admin mana pun dapat setiap saat membuang seluruh tabel ke stik data portabel dan meninggalkan kemampuan untuk masuk sebagai pengguna apa pun dan menyebabkan kekacauan, atau menjual data.

Bahkan jika Anda menganggap semua admin dapat dipercaya itu juga membuat kompromi dari kata sandi admin menghancurkan.

Anda juga tidak memerlukan kata sandi pengguna untuk melakukan operasi seperti mereka. Anda dapat menerapkan sudofitur -seperti.

Ini tidak mungkin merupakan sistem pemerintah federal karena persyaratan FIPS dan FISMA akan melarang enkripsi yang dapat dibalik untuk kata sandi, dan departemen induk akan menamparnya ke bulan.

Dan untuk menerapkan kebijakan keamanan yang lebih kuat (kata sandi hashing sehingga tidak dapat dengan mudah diambil), saya harus menghapus fungsionalitas yang ada untuk mereka.

Untuk perusahaan saya sebelumnya, saya terus memperjuangkan kemampuan untuk mengirim email pengaturan ulang kata sandi untuk mengatasi masalah ini. Dan saya terus ditolak. Pada akhirnya, saya bosan membuang kotoran ke arus, jadi saya pergi. Ini juga seorang bos berambut runcing yang berpikir bahwa pertanyaan bodoh yang diajukan beberapa situs web bank dianggap sebagai "otentikasi 2 faktor". Berdebat dengannya seperti kartun Dilbert (dia berbentuk seperti PHB).

Plus sebenarnya ada fungsionalitas yang ada dalam aplikasi untuk pengguna admin untuk mengambil kata sandi pengguna untuk login sebagai mereka dan melakukan hal-hal (yang mereka katakan, mereka butuhkan).

Saya telah melihat ini diterapkan di lembaga keuangan. Orang-orang di area dukungan pelanggan akan masuk dengan kredensial mereka sendiri, dan jika mereka memiliki hak untuk melakukannya, bisa berpura-pura masuk sebagai pelanggan. Ini tidak mencatat mereka sebagai pelanggan, hanya menyamar sebagai pelanggan . Dengan cara itu jika perwakilan layanan pelanggan memutuskan untuk menarik uang, itu tidak akan muncul ketika pelanggan melakukannya dalam log: itu akan menunjukkan perwakilan layanan pelanggan yang mencoba melakukannya (serta mengirimkan peringatan untuk memecat mereka segera setelah rentacop bisa sampai ke lantai mereka).

Jika dilakukan dengan buruk, itu akan membuat staf dukungan pelanggan dapat membuatnya tampak bahwa pengguna akhir terlibat dalam beberapa kegiatan yang dapat mengakibatkan kewajiban keuangan atau hukum yang serius.

Situs web federal terakhir yang saya kerjakan mengumpulkan 1/4 miliar dolar AS per tahun dari pengguna akhir (yang jumlahnya ada sekitar 400 pengguna), jadi pencatatannya harus sangat ketat, dan hanya pengguna akhir yang diizinkan yang boleh disentuh. halaman web tempat mereka melaporkan barang-barang tempat mereka membayar pajak cukai.

Sony adalah salah satu perusahaan dengan pelanggaran keamanan terbaru. Itu bukan hanya jaringan PS3, itu juga jaringan game MMORPG mereka, berjumlah lebih dari 25.000.000 nama, alamat, nomor kartu kredit, nama pengguna, dan kata sandi. Anda dapat percaya bahwa saya tidak bahagia sama sekali (saya ingin evercrack saya!).

Saya merujuk Kode Etik Teknik Perangkat Lunak tentang masalah seperti ini. Interpretasi saya, prioritas pertama Anda bukanlah untuk merongrong kepentingan publik (tidak seperti kemungkinan kata sandi yang dikompromikan lebih seperti contoh ini di sini di mana perusahaan memodifikasi laptop Dell sehingga perusahaan penyewaan dapat memata-matai penyewa mereka tanpa mereka sadari). Setelah itu, tanggung jawab Anda adalah untuk MENGINGAT klien Anda tentang risiko potensial dan membiarkan mereka mempertimbangkannya. Tentu saja itu baseline minimum. Anda harus menggunakan penilaian Anda sendiri apakah Anda merasa bahwa ini masih lebih dari yang dapat Anda biarkan dan biarkan.

Tentu saja ketika Anda menyebutkan proyek pemerintah, jika informasi pribadi warga negara berisiko karena praktik-praktik ini, maka itu merusak kepentingan publik.

Anda dapat mencetak daftar surel dan kata sandi yang didekripsi dan meletakkannya di meja bos Anda, dengan peringatan besar di halaman depan: "Rahasia"

Buat font kecil agar tidak membuang kertas.

Anda juga bisa menunjukkan kepada mereka bagaimana bugzilla memungkinkan admin untuk menyamar sebagai orang tanpa menggunakan kata sandi mereka.

Pertama-tama, saya setuju dengan jawaban lain yang menunjukkan bahwa jauh lebih aman untuk menghindari ini, dan hanya menyimpan hash kata sandi, bukan kata sandi itu sendiri, atau apa pun yang dapat diubah kembali menjadi kata sandi.

Namun, ada saat-saat ketika Anda lebih atau kurang perlu mengizinkan pemulihan. Dalam hal kata sandi, Anda biasanya ingin memulihkan dengan hanya mengizinkan administrator untuk mengubah kata sandi saat / jika diperlukan daripada memulihkan kata sandi yang ada.

Namun, kemungkinan lain adalah Anda memperbolehkan pengguna untuk menyimpan data di server yang dienkripsi dengan kata sandi mereka sendiri. Dalam hal ini, cukup memungkinkan administrator untuk mengubah kata sandi tidak cukup. Kata sandi baru tidak akan berfungsi untuk mendekripsi data, dan sebagian besar pengguna akan merasa tidak dapat diterima untuk semua data terenkripsi mereka menjadi tidak dapat diakses ketika / jika mereka lupa / kehilangan kata sandi. Untuk situasi ini, ada alternatif yang cukup aman, dan masih memungkinkan pemulihan ketika benar-benar dibutuhkan.

Alih-alih menggunakan kata sandi pengguna untuk mengenkripsi data, Anda membuat kunci acak untuk mengenkripsi data itu sendiri. Anda kemudian menyimpan kunci itu, di beberapa tempat: setelah dienkripsi dengan kata sandi pengguna, dan di tempat lain dienkripsi dengan kata sandi administrator. Kemudian ketika (tidak benar-benar jika) pengguna kehilangan kata sandi dan tidak dapat lagi mengakses data secara langsung, Anda dapat menggunakan kata sandi administrator untuk mendekripsi kunci nyata dan menggunakannya untuk memulihkan data dan / atau mengenkripsi ulang kunci dengan kata sandi baru pengguna.

Jika Anda tidak ingin sepenuhnya mempercayai satu administrator, Anda dapat mengelolanya juga. Misalnya, Anda dapat memutuskan bahwa 5 orang akan memiliki kunci administrator, dan Anda ingin setidaknya tiga dari mereka setuju sebelum kunci dapat dipulihkan. Dalam hal ini, ketika Anda menyimpan kata sandi terenkripsi untuk keperluan administrasi, Anda menyimpannya beberapa kali, masing-masing untuk setiap set tiga dari lima administrator (yang tidak memakan banyak ruang, karena Anda hanya menyimpan beberapa kunci , pada ~ 256 bit masing-masing, bukan beberapa salinan data). Setiap salinan tersebut dienkripsi berturut-turut dengan (hash) masing-masing kata sandi untuk ketiga administrator tersebut.

Untuk mendekripsi, Anda perlu mengidentifikasi tiga administrator yang memasukkan kata sandi mereka, dan memilih kunci terenkripsi yang tepat untuk set tiga, kemudian mendekripsi menggunakan masing-masing dari tiga kata sandi untuk akhirnya mendapatkan kunci asli. Anda kemudian dapat menggunakannya untuk memulihkan data itu sendiri, atau Anda bisa mengenkripsi ulang dengan (hash) kata sandi baru pengguna sehingga mereka masih dapat mengakses data mereka.

Ketika Anda melakukan ini, Anda benar - benar perlu menggunakan algoritma enkripsi standar, dan (dengan preferensi yang kuat) standar, yang terkenal, implementasi yang dipelajari secara menyeluruh.

Ini membuat saya khawatir, mengingat itu untuk proyek pemerintah. Mengambil kata sandi pengguna untuk melakukan tindakan berdasarkan ID mereka membuat omong kosong apa pun dari audit keamanan apa pun. Satu-satunya alasan saya bisa melihat ini adalah untuk membuat jejak audit palsu.

Benar-benar tidak perlu menggunakan enkripsi reversibel untuk kata sandi. Jika ada alasan sah untuk memalsukan ID pengguna, itu bisa dilakukan dengan:

• Simpan hash kata sandi saat ini
• Mengganti dengan nilai yang diketahui
• (Faked-audit-trail-activity, mis. Transfer dana ke rekening luar negeri)
• Ganti hash kata sandi asli

Saya akan merasa tidak nyaman dengan langkah terakhir - siapa pun yang ditiru di sistem harus tahu itu telah terjadi. Mungkin Anda dapat membujuk bisnis dengan mengatakan "Ini seperti bank Anda yang mengizinkan saya mengakses akun Anda tanpa sepengetahuan Anda, karena saya katakan saya benar-benar perlu"

Kepercayaan mereka pada sistem kata sandi yang lebih baik bukanlah masalahnya. Buat solusi untuk memungkinkan admin / dukungan untuk menyamar sebagai akun pengguna dan memberikan perbaikan Anda untuk kata sandi. Keamanan sering menderita karena kenyamanan. Jadikan nyaman dan aman.

Sunting: Mereka tidak akan pernah sepenuhnya memahami masalah keamanan kata sandi, tetapi mereka memahami kehilangan fungsionalitas. Buat proposal ini dan lihat apakah Anda bisa mendapatkan persetujuan untuk melakukan perubahan yang diperlukan. Mereka bahkan tidak tahu apakah itu akan memakan waktu satu jam atau satu tahun. Ini adalah perubahan fitur dan bukan pembangunan kembali yang lengkap.

Mempertimbangkan kejadian terkini (kebocoran data Epsilon dan kebocoran data Playstation Network), orang akan berharap masalah akan sangat jelas.

Namun, kadang-kadang, sebagai pengembang Anda tidak dapat memengaruhi kebijakan.

Saya akan melakukan yang terbaik untuk menunjukkan potensi skandal dan biaya, yang seharusnya mudah, sekali lagi mempertimbangkan kejadian saat ini. Tetapi jika itu tidak berhasil, apa yang dapat Anda lakukan. Tidak banyak. Berhentilah dalam protes, tunjukkan kerentanan untuk meningkatkan perhatian. Tidak terdengar seperti opsi hebat.

Saya menyarankan ini, tetapi jika Anda benar-benar harus memiliki kemampuan untuk mendekripsi kata sandi, Anda harus menggunakan enkripsi kunci publik. Dengan begitu, Anda dapat mengenkripsi semua kata sandi menggunakan kunci publik. Anda dapat memverifikasi kata sandi dengan mengenkripsi dengan kunci publik dan membandingkan, dan Anda dapat menyimpan kunci pribadi di tempat lain (bukan di komputer produksi).

Biasanya alasan Administrator untuk melihat kata sandi pengguna adalah jika mereka kehilangannya, mereka dapat memberikannya kepada pengguna. Sejauh yang saya tahu, Windows juga tidak membiarkan Administrator melihat kata sandi - jadi mengapa aplikasi Anda? Setiap perpustakaan enkripsi di rumah pasti akan rusak karena saya yakin siapa pun yang menulisnya tidak bekerja untuk NSA.