Mengapa kata sandi harus dienkripsi jika disimpan dalam database yang aman?

Saya punya layanan web. Saat ini, saya memiliki kata sandi yang disimpan dalam teks biasa di tabel MySQL di server saya. Saya tahu ini bukan praktik terbaik, dan itulah sebabnya saya mengusahakannya.

Mengapa kata sandi harus dienkripsi jika disimpan dalam database yang aman? Saya menyadari bahwa jika seseorang meretas ke dalam basis data saya, mereka akan mendapatkan kata sandi semua orang. Tapi saya punya masalah lain jika seseorang masuk ke database saya, misalnya menghapus data.

Skenario yang bisa saya pikirkan adalah Anda diretas. Anda mengembalikan database dari beberapa jam yang lalu dan semuanya baik-baik saja. Namun, jika kata sandi Anda adalah teks biasa ... Pencuri memiliki semua kata sandi dan Anda harus mengatur ulang semuanya. Kerumitan untuk pengguna Anda.

Jika kata sandi dienkripsi, Anda bisa mengembalikan ke database sebelumnya. Apakah ini pemikiran yang benar?

Pertama, Anda harus lebih bebas dengan hak akses baca-saja daripada baca-tulis. Mungkin saja peretas memiliki akses ke data Anda tetapi tidak dapat mengeditnya.

Tetapi, yang jauh lebih penting, ini bukan tentang Anda. Fakta bahwa Anda mungkin kacau jika seseorang memiliki akses penuh ke database Anda tidak relevan. Jauh lebih penting adalah data pengguna Anda .

Jika Anda memulihkan basis data Anda, peretas masih memiliki akses ke akun pengguna Anda.

Dan siapa yang tahu apa lagi? Bagaimana jika mereka menggunakan kata sandi yang sama di Google? Atau PayPal? Bagaimana jika itu memberikan akses hacker ke nama gadis ibu mereka, atau 4 digit terakhir dari kartu kredit mereka?

Bagaimana jika itu membuat mereka masuk ke akun lain? Jangan lewati peretas untuk melewati sistem dukungan pengguna dan mendapatkan info lebih lanjut .

Hanya saja ... jangan. Itu informasi pribadi pengguna Anda dan Anda tidak perlu melihatnya. Itu juga reputasi Anda. Enkripsi itu.

Sunting: Satu komentar ekstra, untuk menyelamatkan pembaca di masa depan dari membaca setiap jawaban dan komentar ...

Jika Anda akan mengenkripsi (dalam arti paling ketat) maka Anda perlu menggunakan pasangan kunci publik / pribadi , yang baik-baik saja tetapi membuat hidup sedikit lebih sulit bagi Anda dan pengguna Anda.

Sebuah sederhana, dan hanya sebagai efektif, solusinya adalah dengan acak-garam dan hash password. Hashing saja tidak cukup; jika pengguna Anda menggunakan kata sandi umum, kata itu akan muncul dalam tabel hash terbalik, yang sudah tersedia dengan pencarian internet sederhana.

Jika Anda diretas, Anda dapat memulihkan situs dari cadangan dan memperbaikinya. Tetapi hacker masih memiliki kata sandi untuk akun semua orang! Ada contoh dunia nyata yang terdokumentasi tentang kejadian ini (Sony, Linked-in), di mana jika tabel kata sandi telah di hash dengan benar dan diasinkan, mengamankan dan memulihkan sevice dengan cepat akan jauh lebih mudah.

Mungkin ide yang baik untuk mengasumsikan Anda akan diretas, dan merancang strategi cadangan Anda dan mengenkripsi data sensitif apa pun dengan asumsi ini. Dan bukan hanya peretas yang perlu Anda lindungi. Karyawan yang tidak puas, tidak jujur, atau tidak tahu apa-apa bisa memberikan kata sandi teks biasa.

Tanpa hashing Anda harus menonaktifkan akses untuk semua orang sampai mereka mengubah kata sandi mereka (yang, bahkan jika mungkin, akan sangat memusingkan semua orang). Jika kata sandi telah di-hash dan diasinkan, Anda dapat memulihkan layanan web dan akan jauh lebih sulit bagi penyerang untuk mendapatkan akses ke akun orang.

Kata sandi yang hash dan asin dengan benar pada dasarnya satu arah. Anda tidak dapat dengan mudah menebak kata sandi dari kata sandi hash. Bahkan Anda, karena penyedia layanan tidak dapat menebaknya, Anda hanya dapat mengatur ulang.

Juga, seperti kata Elin, jangan coba-coba menggulung hashing Anda sendiri (atau enkripsi). Gunakan perpustakaan standar.

Tapi saya punya masalah lain jika seseorang masuk ke database saya, yaitu menghapus data.

Ini bukan tentang masalah yang Anda miliki, ini tentang masalah yang mungkin ditimbulkan untuk semua pengguna Anda yang lain. Ini tentang menghapus godaan (atau bahkan lebih buruk, potensi pertanggungjawaban) bagi orang yang bekerja di situs untuk menyalahgunakan data yang disimpan di sana.

Lihat, meskipun orang harus menggunakan kata sandi yang berbeda pada sistem yang berbeda, kenyataannya tidak .

... dan karena kata sandi hash sangat mudah, Anda tidak memiliki alasan untuk tidak mengikuti praktik terbaik industri.

Serangan nyata seperti menghapus data biasanya merupakan hal yang amatir, dan paling tidak merupakan kekhawatiran Anda. Salah satu hal pertama yang akan dilakukan penyerang berpengalaman adalah upaya untuk mendapatkan akses yang sah, jadi bahkan jika Anda menambal kerentanan asli yang ia gunakan, ia akan tetap bisa masuk. Ia akan melakukan segala kemungkinan untuk menghindari menarik perhatian pada dirinya sendiri sampai ia mencapai apa yang dia inginkan. Dengan membiarkan kata sandi tidak rusak, Anda berpotensi membuat pekerjaannya jauh lebih mudah. Anda juga membuatnya lebih sulit untuk mendeteksi dan mengisolasi perilaku berbahaya masa depannya.

Juga, tidak semua kompromi memberi Anda akses shell penuh. Bagaimana jika kerentanan yang digunakan penyerang hanya injeksi SQL read-only di atas usersmeja? Meninggalkan kata sandi yang tidak rusak hanya memberinya akses penuh.

Itu di samping alasan yang diberikan oleh jawaban lain tentang tanggung jawab Anda untuk melindungi data pengguna Anda. Maksud saya adalah, bukan hanya pengguna Anda yang kehilangan sesuatu.

Saya harus mengirim jawaban di sini tentang kekeliruan dalam pertanyaan itu sendiri. Anda bertanya apakah kata sandi harus dienkripsi. Tidak ada yang mengenkripsi kata sandi; tidak ada, dengan pengecualian layanan dan program seperti Firefox Sync dan Roboform, yang tujuan utamanya adalah mengenkripsi kata sandi.

Mari kita lihat definisi:

Dalam kriptografi, enkripsi adalah proses penyandian pesan (atau informasi) sedemikian rupa sehingga hanya pihak yang berwenang yang dapat membacanya.

Dan hashing:

Fungsi hash adalah algoritma apa pun yang memetakan data dengan panjang sewenang-wenang ke data dengan panjang tetap.

Dengan kata lain, enkripsi adalah konversi dua arah dan hashing adalah konversi satu arah , jadi kecuali Anda mendekripsi untuk melihatnya nanti, ini bukan enkripsi.

Juga, jangan hanya hash, garam ! Baca seluruh halaman ini sebelum Anda memasukkan kata sandi.

Adapun algoritma hashing, yang OP sekarang melihat ke dalam, saya akan menyarankan salah satu dari varian SHA-2 high-end, seperti SHA-384 atau SHA-512.

Dan pastikan untuk menggunakan putaran hashing . Jangan hash sekali, hash beberapa kali.

Pertimbangkan membaca halaman ini untuk lebih mengamankan proses login Anda.

Kedua, basis data Anda tidak pernah cukup aman. Akan selalu ada celah keamanan dan risiko yang terus berkembang. Anda harus mengikuti Hukum Murphy dan selalu bersiap untuk kemungkinan terburuk.

The titik lain merek pdr yang persis apa lagi saya akan mengatakan: orang yang menggunakan password yang sama untuk setiap website, hacker menggunakan social engineering untuk mendapatkan informasi lebih lanjut, dll dll

Ada prinsip penting yang dipertaruhkan di sini. Hanya ada satu orang yang memiliki bisnis yang mengetahui kata sandi pengguna. Itu pengguna. Bukan istri / suami mereka, dokter mereka atau bahkan pendeta mereka.

Itu pasti tidak termasuk programmer, administrator database atau teknisi sistem yang bertanggung jawab atas layanan yang mereka gunakan. Itu menciptakan tantangan, karena programmer memang memiliki tanggung jawab untuk menerima membuktikan bahwa pengguna benar-benar mengetahui kata sandi, yang merupakan masalah non-sepele untuk dipecahkan dengan cara murni.

Solusi murni adalah memiliki mekanisme di mana pengguna ditantang dengan beberapa data baru dan tidak dapat diprediksi, dan kemudian harus mengembalikan respons yang didasarkan pada data ini dan kata sandi mereka. Salah satu implementasi dari ini adalah untuk meminta pengguna untuk menandatangani secara digital beberapa data yang baru dibuat dengan tanda tangan digital mereka, dan kami dapat membuktikan secara matematis bahwa mereka menggunakan pasangan kunci kriptografi yang sama dengan yang mereka gunakan untuk membuat akun.

Dalam praktiknya, solusi murni membutuhkan infrastruktur dan pemrosesan sisi klien yang substansial, dan bagi banyak situs web, ini seringkali tidak sesuai untuk data yang dilindungi.

Solusi yang lebih umum adalah:

Pada titik di mana kata sandi pertama kali diterima dalam aplikasi, kata sandi dilewatkan ke fungsi hashing, bersama dengan nilai 'garam' acak aplikasi Anda ke dalam fungsi hash.

String asli kemudian ditimpa dalam memori, dan sejak saat ini, hash asin disimpan dalam database atau dibandingkan dengan catatan database.

Aspek kunci yang memberikan keamanan di sini adalah:

1. Pengetahuan tentang hash tidak secara langsung memberikan otentikasi.
2. Membalikkan perhitungan kata sandi dari hash tidak praktis.
3. Penggunaan tabel pelangi (daftar panjang kata sandi dan hash yang dihitung) menjadi lebih menantang karena hash yang dihasilkan bergantung pada nama pengguna dan kata sandi.

Anda perlu "mengenkripsi" (sebenarnya, "hash", untuk gagasan hashing yang tepat) kata sandi sebagai lapisan pertahanan kedua : ini dimaksudkan untuk mencegah penyerang, yang hanya melihat sekilas dari basis data, agar tidak meningkat itu menjadi akses baca-tulis dan, tepatnya, mulai mengubah data. Pelanggaran parsial hanya baca terjadi di dunia nyata, misalnya melalui beberapa serangan injeksi SQL dari akun dengan akses hanya baca, atau dengan mengambil hard disk yang terbuang atau pita cadangan lama dari tempat sampah. Saya telah menulis panjang lebar tentang hal ini di sana .

Adapun cara yang tepat untuk hash kata sandi, lihat jawaban ini . Ini melibatkan garam, iterasi, dan, yang paling penting, tidak menemukan algoritma Anda sendiri (kriptografi buatan sendiri adalah resep pasti untuk bencana).

Saya tidak akan mengulangi apa yang dikatakan orang lain, tetapi dengan asumsi Anda memiliki PHP 5.3.8 atau lebih baik, Anda harus menggunakan PHP asli bcryptuntuk menyimpan kata sandi Anda. Ini dibangun ke dalam PHP. Jika Anda memiliki PHP 5.5, Anda dapat menggunakan kata sandi konstan terbaik yang tersedia. Anda juga dapat menggunakan perpustakaan untuk membuat 5.3.8 atau berperilaku lebih baik seperti 5.5.

Pertanyaan Stack Overflow Bagaimana Anda menggunakan bcrypt untuk mem-hashing password di PHP? menjelaskannya, dan balasan lain di sana menjelaskan lebih lanjut. Tolong jangan main-main mencoba melakukan ini sendiri.

Saya setuju dengan jawaban dari pdr, untuk alasan yang dinyatakan dalam jawaban itu.

Saya akan menambahkan yang berikut ini: Anda harus melakukannya karena mudah dilakukan dan diterima secara umum sebagai praktik terbaik untuk aplikasi apa pun. Lebih khusus lagi, kata sandi harus selalu asin dan hash sebelum menulis ke penyimpanan persisten. Berikut ini adalah referensi yang baik tentang pentingnya pengasinan dan memilih hash kriptografi yang baik (yang juga menyediakan kode sumber gratis dalam beberapa bahasa populer): https://crackstation.net/hashing-security.htm

Jumlah kecil waktu pengembangan tambahan sangat layak untuk perlindungan yang diberikannya kepada pengguna Anda, dan bagi reputasi Anda sebagai pengembang.

Skenario yang bisa saya pikirkan adalah Anda diretas.

Skenario lain yang perlu Anda pikirkan: seseorang menyelipkan DBA Anda (atau siapa pun yang dapat menjalankan kueri pemilihan pada DB Anda) $ 100, untuk memberi mereka kata sandi pengguna. Atau insinyur sosial magang untuk melakukan itu.

Kemudian mereka menggunakan kata sandi itu untuk masuk ke Gmail pengguna ... atau situs perdagangan ... (karena orang-orang ... kurang pintar menurut kami - dan menggunakan kata sandi yang sama di seluruh situs).

Kemudian pengguna yang marah menuntut perusahaan Anda untuk mengekspos kata sandi mereka.

NOBODY (termasuk orang-orang di perusahaan Anda) harus dapat membaca kata sandi teks biasa. Pernah. Tidak ada kebutuhan bisnis atau teknis yang sah untuk itu.

Untuk satu, bahkan administrator basis data tidak boleh melihat kata sandi pengguna. Hashing mereka akan mencegah hal ini jika administrator memutuskan untuk melihat kata sandi dan login ke akun pengguna mereka.

Yah, ini mengejutkan belum ada yang menyebutkan ini, tapi bagaimana dengan keamanan FISIK dari database Anda?

Anda mungkin mengatur keamanan TI terbaik di dunia, tetapi itu tidak menghentikan siapa pun yang dapat memperoleh akses fisik ke media penyimpanan Anda. Apa yang terjadi ketika tim Anda memenangkan Superbowl sore ini, dan kerusuhan kecil meletus di daerah pusat kota Anda di mana kantor / penyedia hosting Anda berada? (Mengingat bahwa itu Seattle vs Denver, dua area IT besar di AS, saya pikir itu tidak masuk akal). Massa menerobos masuk ke gedung Anda dan sementara pihak berwenang kewalahan, seseorang mengambil beberapa perangkat keras Anda dengan DB di atasnya yang berisi kata sandi teks-jelas?

Apa yang terjadi ketika FBI muncul dan menyita peralatan Anda karena beberapa eksekutif tingkat tinggi menggunakan posisinya di perusahaan untuk melakukan perdagangan saham ilegal? Kemudian FBI menggunakan kata sandi tersebut untuk menyelidiki pelanggan Anda, meskipun mereka tidak melakukan kesalahan. Kemudian mereka menyadari bahwa ANDA lah yang membuat mereka rentan.

Apa yang terjadi ketika departemen TI Anda lupa untuk menghapus drive RAID lama yang menahan DB Anda ketika mereka melakukan penggantian terjadwal sebelum "membagikan" drive lama ke tempat magang, dan kemudian teman sekamar asrama mereka menemukan apa yang tertinggal, dan mencari tahu mereka bisa " menjualnya dan tidak pernah melacaknya kembali kepada mereka?

Apa yang terjadi ketika DB Server Anda menghancurkan motherboard, TI mengembalikan gambar ke server baru Anda, dan "bangkai" dari server lama dilemparkan ke tumpukan daur ulang? Drive-drive itu masih bagus, dan data itu masih ada.

Setiap arsitek yang baik tahu bahwa keamanan bukanlah sesuatu yang Anda "sembunyikan" nanti dengan firewall dan kebijakan operasi. Keamanan harus menjadi bagian mendasar dari desain sejak awal, dan itu berarti kata sandi adalah hash satu arah, TIDAK PERNAH dikirim tanpa enkripsi (bahkan di dalam pusat data Anda sendiri), dan tidak pernah dapat dipulihkan. Apa pun yang dapat diambil dapat dikompromikan.

Mengesampingkan kasus database Anda diretas: Sebagai pelanggan saya tidak ingin ANDA tahu kata sandi saya. Saya tahu bahwa Anda dapat dengan mudah mendapatkan kata sandi saat masuk atas permintaan, tetapi saya merasa lebih baik ketika Anda tidak memilikinya untuk membantu permintaan kapan saja Anda mau.

Jika kata sandi disimpan dalam teks biasa, itu berarti bahwa kata sandi itu diketahui pengguna dan siapa pun yang memiliki akses ke tabel itu. Seluruh gagasan tentang menerapkan pengguna dan kata sandi adalah untuk memastikan bahwa sesi tertentu di sistem Anda adalah milik orang tersebut, baik untuk alasan privasi dan keamanan.

Jika username / password dikenal oleh sekelompok orang itu menjadi sia-sia untuk tegas mengidentifikasi seseorang, dan yang menciptakan banyak skenario yang mungkin untuk pencurian identitas, penipuan ...

Itu sebabnya kata sandi disimpan menggunakan protokol enkripsi asimetrik, untuk memastikan bahwa Anda dapat memvalidasinya tanpa mampu membacanya.

Saya pikir ada kelemahan mendasar dalam pertanyaan ini. Faktanya adalah, tidak ada yang namanya "database aman". Ini harus dianggap sebagai mengingat bahwa ada kekurangan di sistem Anda di suatu tempat yang dapat memungkinkan pengguna jahat mengakses data sewenang-wenang di server Anda. Heartbleed adalah contoh kasus yang sangat bagus, menjadi eksploitasi yang ada di alam liar selama lebih dari dua tahun sebelum diketahui oleh para peneliti. Anda mungkin telah melakukan semua yang Anda tahu harus dilakukan untuk melindungi data, tetapi Anda tidak dapat menjelaskan semua perangkat lunak lain yang Anda gunakan di server Anda dan cara rumit mereka berinteraksi.

Jika seseorang menaruh minat pada Anda, Anda akan diretas. Penting untuk melakukan yang terbaik untuk mencegah diretas sejak awal, tetapi juga untuk mengurangi kerusakan yang terjadi ketika itu terjadi dengan meletakkan sebanyak mungkin rintangan di tempat. Hash kata sandi Anda. Ini tidak sulit untuk diatur, dan Anda membuat pengguna Anda merasa tidak enak dengan tidak menganggap privasi mereka dengan serius. Ini adalah keangkuhan untuk berpikir Anda entah bagaimana lebih terlindungi dari serangan berbahaya daripada perusahaan seperti Yahoo , atau Sony , atau Target , yang semuanya telah diretas.