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


78

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?


124
Saya akan melangkah lebih jauh. Tidak cukup untuk mengenkripsi itu. Anda ingin hash itu. Dengan begitu, bahkan Anda pun tidak bisa mengetahui kata sandi plaintext pengguna Anda.
Santa

67
@Santa Hashing kata sandi tidak cukup. Anda harus menambahkan garam untuk membuat resepnya cukup baik ...
Bakuriu

16
Silakan lihat posting Security.StackExchange yang relevan ini: Bagaimana cara mengamankan kata sandi hash dengan aman?
Adi

10
DBA yang kecewa mengatakan ... pilih * dari pengguna, dan kemudian menjual daftar itu untuk pembayaran pesangon. Tidak ada yang pernah aman.
Jon Raynor

Jawaban:


194

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.


89
Atau lebih baik, hash itu!
Blorgbeard

29
Ini. "Saya memiliki masalah lain jika seseorang masuk ke database saya". Itu adalah basis data Anda, Anda berharap memiliki masalah jika diretas. Tetapi dengan menyimpan kata sandi plaintext Anda memberikan semua masalah kepada pengguna Anda dengan, berpotensi, semua akun mereka yang lain. Menurut Anda, berapa banyak orang yang benar-benar menggunakan kata sandi berbeda di setiap situs web?
Carson63000

13
Harap ikuti saran Blorgbeard, mungkin baca ini . Mengenkripsi kata sandi tidak memberikan perlindungan ketika server web Anda telah disusupi. Kunci untuk mendekripsi kata sandi harus disimpan di suatu tempat di server. Hashing kata sandi berarti bahwa bahkan jika seseorang memiliki akses penuh ke mesin, mereka tidak dapat memulihkan kata sandi dengan mudah.
Slicedpan

7
Mengapa Anda perlu mengenkripsi kata sandi jika tidak memberikan nilai pada sistem Anda? Kapan Anda harus mendekripsi kata sandi, selain untuk perbandingan? @ pdr, Anda seharusnya tidak memberi tahu OP untuk mengenkripsi, Anda harus memberi tahu dia tentang garam dan hash.
NobleUplift

4
Anda juga ingin mengaitkan jawaban atas pertanyaan pemulihan kata sandi mereka. Kalau tidak, itu dapat digunakan untuk masuk ke situs lain juga, seperti kata sandi.
Zan Lynx

64

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.



13
+1 untuk menyebut karyawan yang tidak puas. Sangat mudah untuk diabaikan ketika Anda adalah seorang pria atau perusahaan kecil, tetapi pada akhirnya Anda akan memiliki orang-orang yang bekerja dengan data yang belum Anda periksa secara pribadi.

2
Menulis pendahuluan untuk mengulang daftar pengguna dan kemudian hash password mereka adalah pekerjaan beberapa menit dan terus terang 4000 hampir tidak ada apa-apanya. php.net/manual/en/function.hash.php
Elin

3
Anda terus beralih di antara istilah "mengenkripsi" dengan "hash dan garam" @ david25272. Jangan bingung keduanya, yang sama sekali berbeda. Sekarang OP sedang mencari algoritma enkripsi, dan bukan algoritma hash. Juga, itu "garam dan hash", bukan "hash dan garam". Anda tidak bisa garam setelah hash.
NobleUplift

1
Juga @phpmysqlguy, baca jawaban saya untuk saran tentang penggaraman dan algoritma hash .
NobleUplift

36

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.


9
Anda membuat apa yang saya yakini sebagai poin paling penting: ANDA dan pekerja Anda seharusnya tidak memiliki akses ke kata sandi pengguna. Siapa yang peduli dengan peretas, orang-orang yang memegang data yang menjadi perhatian pengguna.
Adam Davis

1
Memberi +1 untuk fakta bahwa sebagai pengembang / admin Anda seharusnya tidak memiliki akses ke kata sandi pengguna Anda. Itu sendiri sudah cukup beralasan.
Matt

21

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.


18

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


+1 untuk hash plus garam. Retak hash tanpa garam adalah sooo mudah.
Code Maverick

3
Anda tahu apa yang ada di sisi lain meja pelangi @CodeMaverick? Panci emas.
NobleUplift

Dalam konteks hashing kata sandi MD5 tidak memiliki kerentanan yang diketahui selain kecepatan, dan itu berlaku juga untuk SHA-2. Menggunakan konstruksi yang lambat dan iterasi jauh lebih penting daripada memilih SHA-2 dibandingkan MD5.
CodesInChaos

4
"Baca seluruh halaman ini sebelum kata sandi Anda hash" - halaman itu menyebutkan bahwa Anda tidak boleh menggunakan putaran hashing, tetapi metode hashing yang telah dirancang secara khusus agar selambat yang diperlukan, seperti PBKDF2.
jhominal

2
Gunakan SCrypt atau PBKDF2, keduanya dirancang untuk menjadi sangat mahal untuk dilakukan dalam hal memori atau CPU. Gunakan Garam yang dihasilkan secara acak yang Anda simpan pada catatan pengguna. Jangan melakukan beberapa putaran hashing, yang hanya mengarah pada masalah tabrakan.
tom.dietrich

14

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.

6
Secara umum lebih disukai menggunakan garam acak daripada nama pengguna.
CodesInChaos

Wow, tangkapan hebat @CodesInChaos. Saya tidak memperhatikan hal itu pada pertanyaan pertama yang saya baca. Ya, garam Anda harus dibuat secara acak. Tidak harus ada gumpalan gila yang disimpan di MySQL (dan itu akan buruk karena dengan begitu tidak akan portabel). Jika tidak, +1 untuk mengatakan bahwa hanya pengguna yang harus mengetahui kata sandi pengguna.
NobleUplift

Oke, jawaban yang diperbarui untuk menyarankan aplikasi memiliki nilai garam acak sendiri.
Michael Shaw

4
Tidak, aplikasi tidak memiliki sebuah nilai garam baik. Harus ada nilai garam yang berbeda, sangat acak, untuk setiap hash yang disimpan. (Anda menyimpan garam bersama hash itu.) Itulah yang melindungi terhadap serangan statistik. Jika Anda menggunakan hash yang sama untuk seluruh aplikasi, maka hash plaintext yang sama memiliki nilai yang sama. Itu jauh lebih buruk daripada menggunakan nama pengguna sebagai hash.
Ben Voigt

Ini bukan layanan web, tetapi otentikasi keypair SSH memang menggunakan solusi 'murni', di mana server menyimpan kunci publik dan pengguna mengautentikasi dengan kunci pribadi.
cpast

10

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


+1 untuk mengetahui perbedaan antara enkripsi dan hashing.
NobleUplift

8

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.


2
Sayangnya, saya menggunakan PHP 5.3.3 sehingga saran Anda tidak akan berlaku
phpmysqlguy

4
Apakah 5.3.3 hingga 5.3.8 banyak yang di-upgrade?
gbjbaanb

Adakah kemungkinan Anda berada di Red Hat? Karena mereka telah meng-backport perbaikan ke bcrypt. Jika tidak, gunakan SHA256 bukan brcypt.
Elin

1
Enkripsi dan hashing adalah hal yang berbeda. Hash kata sandi, jangan mengenkripsi mereka. Anda tidak perlu tahu mereka. Anda hanya perlu pengguna untuk dapat menggunakan kata sandi untuk membuktikan siapa dia. Hashing (dengan garam) memungkinkan ini. Enkripsi, khususnya. enkripsi simetris salah karena memungkinkan kata sandi dipulihkan.
Paul de Vrieze

Satu hal yang akan saya tambahkan adalah bahwa hal yang baik tentang fungsi password_hash () di php 5.5+ adalah bahwa ia menangani penggaraman dan secara normal dengan normal. Sebelumnya, Anda perlu melanjutkan dan menggunakan sesuatu seperti pustaka ircmaxell yang mendukungnya (ia menulis implementasi 5.5). Jangan berasumsi bahwa Anda dapat menghasilkan garam acak sendiri. Ini sangat sangat sulit dan sebaiknya diserahkan kepada para ahli; sangat mudah untuk mendapatkan hasil acak tetapi tidak seragam yang dapat dieksploitasi.
Elin

7

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.


+1 untuk menyebutkan pengasinan, dan hashing, serta tidak menyebutkan enkripsi, yang bahkan tidak termasuk dalam pertanyaan ini.
NobleUplift

2

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.


2

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.


1
ini tidak menambahkan apa pun yang layak untuk apa yang sudah diposting di jawaban sebelumnya
nyamuk

3
+1. Dia benar-benar mengatakan "hashing", bukannya enkripsi seperti banyak lainnya. Juga, dia langsung menentang OP yang mengatakan dia ingin plaintext kata sandi untuk masuk ke akun pengguna lain.
NobleUplift

0

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.


-1

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.


1
Sebenarnya, jika OP mengambil satu langkah lebih jauh dan dienkripsi dalam JavaScript, maka hash akan dikirim melalui kawat dan tidak pernah terlihat dalam permintaan.
NobleUplift

1
Dalam hal ini seorang penyerang hanya perlu mengirim hash melewati kawat juga. Hash hanya akan berfungsi sebagai sandi yang mewah tetapi tidak dienkripsi, bukan? (Sunting: tidak jika harus digarami dengan garam yang berbeda setiap kali, dan garam tersebut berasal dari server. Saya pikir)
RemcoGerlich

1
@RemcoGerlich Konsep utama dikenal sebagai nonce yang digunakan untuk menghindari serangan replay .

-1

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.


2
Siapa yang menyimpan kata sandi menggunakan enkripsi asimetris? Itu kriptografi kunci publik, yang berarti bahkan setelah saya mengenkripsi kata sandi saya, itu dapat didekripsi dan dibaca jika seseorang pernah mendapatkan kunci pribadi saya. Dengan hashing, saya dan hanya saya yang tahu kata sandi saya (kecuali saya menuliskannya atau menaruhnya di manajer kata sandi, di mana sebenarnya adalah enkripsi asimetris).
NobleUplift

Silakan, periksa halaman wikipedia untuk kriptografi kunci-publik: en.wikipedia.org/wiki/Public-key_cryptography "Kriptografi kunci-publik, juga dikenal sebagai kriptografi asimetris,"
Alpha1983

2
... ya, saya mengatakan itu using asymmetric encryption? That's public-key cryptography. Apa maksudmu
NobleUplift

-1

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.


1
ini tampaknya tidak menawarkan sesuatu yang substansial lebih dari 14 jawaban sebelumnya
nyamuk

Saya tidak setuju kalau tidak saya tidak akan mempostingnya. Saya tidak yakin saya melihat bagaimana pendapat Anda tentang membuat komentar negatif menambah percakapan, selain membuat orang tidak bersemangat untuk berpartisipasi.
lobati

Saya tidak tahu apakah Anda telah membaca jawaban lain sebelum memposting jawaban Anda, tetapi per bacaan saya semua poin di sini sudah dibuat (dan per bacaan saya disajikan lebih baik) di tempat lain. Misalnya, titik tentang cacat dalam pertanyaan telah membuat lebih dari 2 bulan yang lalu di ini dan ini jawabannya. Poin tentang hashing password dibuat setidaknya dalam 7 jawaban lain. Poin tentang membuat cadangan dan menghitung kemungkinan masalah di bagian lain dari sistem juga dibuat sejak lama. Dll dll
Agak

Titik kesalahan yang dikaitkan berbeda dari milikku. Mereka menyatakan perbedaan makna antara hashing vs enkripsi, sedangkan saya mengatakan bahwa itu adalah kesalahan untuk berpikir bahwa database dapat dianggap "aman". Saya masih tidak melihat jawaban lain yang membahas bagian-bagian lain dari perangkat lunak dan interaksinya tidak aman, dan saya tidak membuat poin tentang cadangan.
lobati

"anggap kamu akan diretas" - begitulah cara itu dieja dalam jawaban yang diposting lebih dari 2 bulan lalu
agas
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.