Apakah hashing password dua kali sebelum penyimpanan lebih atau kurang aman daripada hanya hashing sekali saja?
Yang saya bicarakan adalah melakukan ini:
$hashed_password = hash(hash($plaintext_password));
bukan hanya ini:
$hashed_password = hash($plaintext_password);
Jika kurang aman, dapatkah Anda memberikan penjelasan yang baik (atau tautan ke satu)?
Juga, apakah fungsi hash yang digunakan membuat perbedaan? Apakah ada bedanya jika Anda mencampur md5 dan sha1 (misalnya) alih-alih mengulangi fungsi hash yang sama?
Catatan 1: Ketika saya mengatakan "hashing ganda" saya berbicara tentang hashing kata sandi dua kali dalam upaya untuk membuatnya lebih jelas. Saya tidak berbicara tentang teknik untuk menyelesaikan tabrakan .
Catatan 2: Saya tahu saya perlu menambahkan garam acak untuk benar-benar membuatnya aman. Pertanyaannya adalah apakah hashing dua kali dengan algoritma yang sama membantu atau menyakiti hash.
sumber
Hash(password)
danHash(Hash(password))
sama-sama tidak aman. Keduanya tidak memiliki pengertian tentang Keamanan Semantik . Artinya, output dapat dibedakan dari acak. Sebagai contoh,MD5("password")
adalah5f4dcc3b5aa765d61d8327deb882cf99
. Saya tahu itu hash MD5password
, dan dapat dibedakan dari acak. Sebagai gantinya, Anda harus menggunakan HMAC. Terbukti aman dan merupakan PRF.Jawaban:
Sekali kata sandi tidak aman
Tidak, banyak hash tidak kurang aman; mereka adalah bagian penting dari penggunaan kata sandi yang aman.
Iterasi hash meningkatkan waktu yang diperlukan bagi penyerang untuk mencoba setiap kata sandi dalam daftar kandidat mereka. Anda dapat dengan mudah meningkatkan waktu yang diperlukan untuk menyerang kata sandi dari jam ke tahun.
Iterasi sederhana tidak cukup
Hanya menghubungkan output hash ke input tidak cukup untuk keamanan. Iterasi harus dilakukan dalam konteks algoritma yang mempertahankan entropi kata sandi. Untungnya, ada beberapa algoritma yang dipublikasikan yang telah memiliki cukup pengawasan untuk memberikan kepercayaan pada desain mereka.
Algoritma derivasi kunci yang baik seperti PBKDF2 menyuntikkan kata sandi ke setiap putaran hashing, mengurangi kekhawatiran tentang tabrakan dalam hash output. PBKDF2 dapat digunakan untuk otentikasi kata sandi apa adanya. Bcrypt mengikuti derivasi kunci dengan langkah enkripsi; dengan begitu, jika cara cepat untuk membalikkan derivasi kunci ditemukan, penyerang masih harus menyelesaikan serangan plaintext yang dikenal.
Cara memecahkan kata sandi
Kata sandi yang disimpan membutuhkan perlindungan dari serangan offline. Jika kata sandi tidak diasinkan, kata sandi tersebut dapat dipecah dengan serangan kamus yang sudah dihitung sebelumnya (misalnya, menggunakan Tabel Pelangi). Jika tidak, penyerang harus menghabiskan waktu untuk menghitung hash untuk setiap kata sandi dan melihat apakah itu cocok dengan hash yang disimpan.
Semua kata sandi kemungkinan tidak sama. Penyerang mungkin mencari semua kata sandi pendek secara mendalam, tetapi mereka tahu bahwa peluang mereka untuk sukses dengan kekerasan menurun tajam dengan setiap karakter tambahan. Sebagai gantinya, mereka menggunakan daftar kata sandi yang paling mungkin dipesan. Mereka mulai dengan "kata sandi123" dan berlanjut ke kata sandi yang jarang digunakan.
Katakanlah daftar penyerang panjang, dengan 10 miliar kandidat; Andaikan juga sistem desktop dapat menghitung 1 juta hash per detik. Penyerang dapat menguji seluruh daftar kurang dari tiga jam jika hanya satu iterasi yang digunakan. Tetapi jika hanya 2000 iterasi digunakan, waktu itu meluas hingga hampir 8 bulan. Untuk mengalahkan penyerang yang lebih canggih — yang mampu mengunduh program yang dapat memanfaatkan kekuatan GPU mereka, misalnya — Anda membutuhkan lebih banyak iterasi.
Berapa cukup?
Jumlah iterasi yang digunakan adalah trade-off antara keamanan dan pengalaman pengguna. Perangkat keras khusus yang dapat digunakan oleh penyerang memang murah, tetapi masih bisa melakukan ratusan juta iterasi per detik. Kinerja sistem penyerang menentukan berapa lama waktu yang diperlukan untuk memecahkan kata sandi yang diberikan sejumlah iterasi. Tetapi aplikasi Anda sepertinya tidak akan menggunakan perangkat keras khusus ini. Berapa banyak iterasi yang dapat Anda lakukan tanpa memperburuk pengguna tergantung pada sistem Anda .
Anda mungkin dapat membiarkan pengguna menunggu sekitar extra detik atau lebih selama otentikasi. Profil platform target Anda, dan gunakan sebanyak mungkin iterasi yang Anda mampu. Platform yang telah saya uji (satu pengguna pada perangkat seluler, atau banyak pengguna pada platform server) dapat dengan nyaman mendukung PBKDF2 dengan antara 60.000 dan 120.000 iterasi, atau bcrypt dengan faktor biaya 12 atau 13.
Lebih banyak latar belakang
Baca PKCS # 5 untuk informasi otoritatif tentang peran garam dan iterasi dalam hashing. Meskipun PBKDF2 dimaksudkan untuk menghasilkan kunci enkripsi dari kata sandi, ini berfungsi dengan baik sebagai hash satu arah untuk otentikasi kata sandi. Setiap iterasi bcrypt lebih mahal daripada hash SHA-2, jadi Anda bisa menggunakan iterasi yang lebih sedikit, tetapi idenya sama. Bcrypt juga melangkah melampaui sebagian besar solusi berbasis PBKDF2 dengan menggunakan kunci turunan untuk mengenkripsi teks biasa yang terkenal. Teks sandi yang dihasilkan disimpan sebagai "hash," bersama dengan beberapa meta-data. Namun, tidak ada yang menghentikan Anda dari melakukan hal yang sama dengan PBKDF2.
Berikut jawaban lain yang saya tulis tentang topik ini:
sumber
Bagi mereka yang mengatakan itu aman, mereka secara umum benar . Hashing "ganda" (atau ekspansi logis dari itu, iterasi fungsi hash) benar-benar aman jika dilakukan dengan benar , untuk masalah tertentu.
Bagi mereka yang mengatakan itu tidak aman, mereka benar dalam hal ini . Kode yang diposting dalam pertanyaan adalah tidak aman. Mari kita bicarakan mengapa:
Ada dua sifat dasar fungsi hash yang kami khawatirkan:
Pre-Image Resistance - Diberi hash
$h
, seharusnya sulit menemukan pesan$m
seperti itu$h === hash($m)
Perlawanan Pra-Gambar Kedua - Diberikan pesan
$m1
, seharusnya sulit untuk menemukan pesan yang berbeda$m2
sehinggahash($m1) === hash($m2)
Resistensi Tumbukan - Seharusnya sulit untuk menemukan sepasang pesan
($m1, $m2)
sedemikian rupahash($m1) === hash($m2)
(perhatikan bahwa ini mirip dengan resistansi Pra-Gambar Kedua, tetapi berbeda karena penyerang memiliki kendali atas kedua pesan) ...Untuk penyimpanan kata sandi , yang benar-benar kami pedulikan adalah Pre-Image Resistance . Dua lainnya akan diperdebatkan, karena
$m1
kata sandi pengguna yang kami coba jaga tetap aman. Jadi jika penyerang sudah memilikinya, hash tidak memiliki apa pun untuk dilindungi ...PENOLAKAN
Segala sesuatu yang mengikuti didasarkan pada premis bahwa semua yang kita pedulikan adalah Pre-Image Resistance . Dua sifat dasar lainnya dari fungsi hash mungkin tidak (dan biasanya tidak) bertahan dengan cara yang sama. Jadi kesimpulan dalam posting ini adalah hanya berlaku ketika menggunakan fungsi hash untuk penyimpanan kata sandi. Mereka tidak berlaku secara umum ...
Mari Memulai
Demi diskusi ini, mari kita ciptakan fungsi hash kita sendiri:
Sekarang seharusnya sudah cukup jelas apa fungsi hash ini. Ini menjumlahkan nilai-nilai ASCII dari setiap karakter input, dan kemudian mengambil modulo hasil itu dengan 256.
Jadi mari kita mengujinya:
Sekarang, mari kita lihat apa yang terjadi jika kita menjalankannya beberapa kali di sekitar fungsi:
Keluaran itu:
Hrm, wow. Kami telah menghasilkan tabrakan !!! Mari kita coba lihat alasannya:
Berikut ini adalah hasil hashing string dari masing-masing dan setiap kemungkinan hasil hash:
Perhatikan kecenderungan angka yang lebih tinggi. Itu ternyata adalah kematian kita. Menjalankan hash 4 kali ($ hash = ourHash ($ hash) `, untuk setiap elemen) akhirnya memberi kita:
Kami sudah dipersempit diri ke 8 nilai-nilai ... Itu buruk ... fungsi asli kami dipetakan
S(∞)
keS(256)
. Itulah yang kami buat pemetaan Fungsi Surjektif$input
ke$output
.Karena kami memiliki fungsi Surjective, kami tidak memiliki jaminan pemetaan untuk setiap subset dari input tidak akan memiliki tabrakan (pada kenyataannya, mereka akan melakukan tabrakan).
Itulah yang terjadi di sini! Fungsi kami buruk, tapi bukan karena ini berhasil (itu sebabnya ia bekerja sangat cepat dan sangat lengkap).
Hal yang sama terjadi dengan
MD5
. Itu petaS(∞)
keS(2^128)
. Karena tidak ada jaminan bahwa menjalankanMD5(S(output))
akan menjadi Injective , artinya tidak akan ada tabrakan.Bagian TL / DR
Oleh karena itu, karena mengumpankan output kembali ke
md5
langsung dapat menghasilkan collision, setiap iterasi akan meningkatkan kemungkinan collision. Namun ini adalah peningkatan linier, yang berarti bahwa sementara set hasil2^128
berkurang, itu tidak berkurang secara signifikan cukup cepat menjadi cacat kritis.Begitu,
Semakin sering Anda mengulangi, semakin jauh pengurangannya terjadi.
Cara Mengatasinya
Untungnya bagi kami, ada cara sepele untuk memperbaikinya: Umpan balik sesuatu ke iterasi lebih lanjut:
Perhatikan bahwa iterasi lebih lanjut bukan 2 ^ 128 untuk setiap nilai individu
$input
. Berarti bahwa kita mungkin dapat menghasilkan$input
nilai yang masih bertabrakan di garis (dan karenanya akan menetap atau beresonansi pada jauh lebih sedikit dari2^128
kemungkinan keluaran). Tetapi kasus umum untuk$input
masih sekuat itu untuk satu putaran.Tunggu, kan? Mari kita uji ini dengan
ourHash()
fungsi kita . Beralih ke$hash = ourHash($input . $hash);
, untuk 100 iterasi:Masih ada pola kasar di sana, tetapi perhatikan bahwa tidak ada lagi dari pola daripada fungsi dasar kami (yang sudah cukup lemah).
Namun perhatikan itu
0
dan3
menjadi tabrakan, meskipun mereka tidak dalam menjalankan tunggal. Itu adalah aplikasi dari apa yang saya katakan sebelumnya (bahwa resistensi tabrakan tetap sama untuk set semua input, tetapi rute tabrakan tertentu mungkin terbuka karena kelemahan dalam algoritma yang mendasarinya).Bagian TL / DR
Dengan memasukkan kembali input ke setiap iterasi, kami secara efektif memecah setiap tabrakan yang mungkin terjadi pada iterasi sebelumnya.
Karena itu,
md5($input . md5($input));
harus ( setidaknya secara teoritis ) sekuatmd5($input)
.Apakah Ini Penting?
Iya. Ini adalah salah satu alasan PBKDF2 menggantikan PBKDF1 di RFC 2898 . Pertimbangkan loop bagian dalam dari keduanya ::
PBKDF1:
Di mana
c
jumlah iterasi,P
adalah kata sandi danS
garamPBKDF2:
Di mana PRF benar-benar hanya sebuah HMAC. Tetapi untuk tujuan kita di sini, anggap saja
PRF(P, S) = Hash(P || S)
(yaitu, PRF dari 2 input adalah sama, secara kasar, seperti hash dengan keduanya digabungkan bersama-sama). Sangat tidak , tapi untuk tujuan kita.Jadi PBKDF2 mempertahankan resistensi tabrakan dari
Hash
fungsi yang mendasarinya , di mana PBKDF1 tidak.Mengikat Semuanya:
Kami tahu cara aman untuk mengulang hash. Faktanya:
Biasanya aman.
Sekarang, untuk membahas mengapa kita ingin hash, mari kita menganalisis gerakan entropi.
Hash mengambil himpunan tak terbatas:
S(∞)
dan menghasilkan himpunan yang lebih kecil dan berukuran konsistenS(n)
. Iterasi berikutnya (dengan asumsi input dilewatkan kembali) petaS(∞)
keS(n)
lagi:Perhatikan bahwa hasil akhir memiliki jumlah entropi yang persis sama dengan yang pertama . Iterasi tidak akan "membuatnya lebih dikaburkan". Entropinya identik. Tidak ada sumber ajaib dari ketidakpastian (ini adalah Fungsi Semu-Acak, bukan Fungsi Acak).
Namun ada keuntungan untuk iterasi. Itu membuat proses hashing lebih lambat secara artifisial. Dan itulah mengapa iterasi bisa menjadi ide yang bagus. Sebenarnya, ini adalah prinsip dasar dari sebagian besar algoritma hashing kata sandi modern (fakta bahwa melakukan sesuatu berulang kali membuatnya lebih lambat).
Lambat itu baik, karena itu memerangi ancaman keamanan utama: kekerasan. Semakin lambat kita membuat algoritma hashing kita, semakin sulit penyerang bekerja untuk menyerang hash kata sandi yang dicuri dari kita. Dan itu bagus !!!
sumber
$output = md5($output); // < 2^128 possibilities
--- apakah itu benar-benar ketat<
, atau<=
?md5()
dalam hal ini) untuk benar-benar mengetahui secara pasti. Tetapi secara umum akan<
dan tidak<=
... Ingat, kita berbicara tentang ukuran set$output
untuk semua kemungkinan$inputs
. Jadi jika kita punya satu tabrakan<
, itu<
adalah generalisasi yang lebih baik.Ya, hashing ulang mengurangi ruang pencarian, tetapi tidak, tidak masalah - pengurangan efektif tidak signifikan.
Re-hashing meningkatkan waktu yang diperlukan untuk brute-force, tetapi melakukannya hanya dua kali juga suboptimal.
Yang Anda inginkan adalah hash kata sandi dengan PBKDF2 - metode yang terbukti menggunakan hash aman dengan garam dan iterasi. Lihatlah respons SO ini .
EDIT : Saya hampir lupa - JANGAN GUNAKAN MD5 !!!! Gunakan hash kriptografi modern seperti keluarga SHA-2 (SHA-256, SHA-384, dan SHA-512).
sumber
Ya - ini mengurangi jumlah string yang mungkin cocok dengan string.
Seperti yang telah Anda sebutkan, hash asin jauh lebih baik.
Artikel di sini: http://websecurity.ro/blog/2007/11/02/md5md5-vs-md5/ , mencoba membuktikan mengapa itu setara, tapi saya tidak yakin dengan logika. Sebagian mereka berasumsi bahwa tidak ada perangkat lunak yang tersedia untuk menganalisis md5 (md5 (teks)), tetapi jelas itu cukup sepele untuk menghasilkan tabel pelangi.
Saya masih tetap dengan jawaban saya bahwa ada jumlah yang lebih kecil dari hash jenis md5 (md5 (teks)) dari hash md5 (teks), meningkatkan kemungkinan tabrakan (bahkan jika masih dengan probabilitas yang tidak mungkin) dan mengurangi ruang pencarian.
sumber
Sebagian besar jawaban adalah oleh orang-orang tanpa latar belakang dalam kriptografi atau keamanan. Dan mereka salah. Gunakan garam, jika mungkin unik per catatan. MD5 / SHA / etc terlalu cepat, kebalikan dari yang Anda inginkan. PBKDF2 dan bcrypt lebih lambat (yang bagus) tetapi dapat dikalahkan dengan ASIC / FPGA / GPU (sangat terjangkau saat ini). Jadi algoritma memory-hard diperlukan: masukkan scrypt .
Berikut penjelasan orang awam tentang garam dan kecepatan (tetapi bukan tentang algoritma memori-keras).
sumber
Saya hanya melihat ini dari sudut pandang praktis. Apa yang dicari peretas? Mengapa, kombinasi karakter yang, ketika dimasukkan melalui fungsi hash, menghasilkan hash yang diinginkan.
Anda hanya menyimpan hash terakhir, oleh karena itu, peretas hanya perlu memaksa satu hash. Dengan asumsi Anda memiliki peluang yang hampir sama untuk menemukan hash yang diinginkan pada setiap langkah bruteforce, jumlah hash tidak relevan. Anda bisa melakukan sejuta iterasi hash, dan itu tidak akan menambah atau mengurangi keamanan sedikit pun, karena pada akhir baris masih ada hanya satu hash untuk dipecahkan, dan kemungkinan melanggar itu sama dengan hash.
Mungkin poster sebelumnya berpikir bahwa input itu relevan; ini bukan. Selama apa pun yang Anda masukkan ke dalam fungsi hash menghasilkan hash yang diinginkan, itu akan membantu Anda, input benar atau input salah.
Sekarang, tabel pelangi adalah cerita lain. Karena tabel pelangi hanya membawa kata sandi mentah, hashing dua kali mungkin merupakan langkah pengamanan yang baik, karena tabel pelangi yang berisi setiap hash dari setiap hash akan terlalu besar.
Tentu saja, saya hanya mempertimbangkan contoh OP memberikan, di mana itu hanya kata sandi teks biasa yang di-hash. Jika Anda memasukkan nama pengguna atau garam dalam hash, itu adalah cerita yang berbeda; hashing dua kali sama sekali tidak perlu, karena tabel pelangi sudah terlalu besar untuk praktis dan mengandung hash yang tepat.
Ngomong-ngomong, bukan ahli keamanan di sini, tapi hanya itu yang saya dapatkan dari pengalaman saya.
sumber
Dari apa yang telah saya baca, mungkin sebenarnya direkomendasikan untuk melakukan hash password ratusan atau ribuan kali.
Idenya adalah jika Anda dapat membuatnya lebih lama untuk menyandikan kata sandi, lebih baik bagi penyerang untuk menjalankan banyak tebakan untuk memecahkan kata sandi. Itu tampaknya menjadi keuntungan untuk hashing ulang - bukan karena lebih aman secara kriptografis, tetapi hanya membutuhkan waktu lebih lama untuk menghasilkan serangan kamus.
Tentu saja komputer menjadi lebih cepat setiap saat, sehingga keunggulan ini berkurang seiring waktu (atau mengharuskan Anda meningkatkan iterasi).
sumber
Secara pribadi saya tidak akan repot dengan banyak hash, tapi saya akan memastikan juga hash UserName (atau bidang User ID lainnya) serta kata sandi sehingga dua pengguna dengan kata sandi yang sama tidak akan berakhir dengan hash yang sama. Juga saya mungkin akan melemparkan beberapa string konstan lainnya ke string input juga untuk ukuran yang baik.
sumber
Mari kita asumsikan Anda menggunakan algoritma hashing: compute rot13, ambil 10 karakter pertama. Jika Anda melakukannya dua kali (atau bahkan 2000 kali) dimungkinkan untuk membuat fungsi yang lebih cepat, tetapi yang memberikan hasil yang sama (yaitu hanya mengambil 10 karakter pertama).
Demikian juga dimungkinkan untuk membuat fungsi yang lebih cepat yang memberikan output yang sama dengan fungsi hashing berulang. Jadi pilihan fungsi hashing Anda sangat penting: seperti pada contoh rot13 tidak diberikan bahwa hashing berulang akan meningkatkan keamanan. Jika tidak ada penelitian yang mengatakan bahwa algoritma ini dirancang untuk penggunaan berulang, maka lebih aman untuk menganggap bahwa itu tidak akan memberi Anda perlindungan tambahan.
Yang mengatakan: Untuk semua kecuali fungsi hashing yang paling sederhana kemungkinan besar akan mengambil ahli kriptografi untuk menghitung fungsi yang lebih cepat, jadi jika Anda berjaga-jaga terhadap penyerang yang tidak memiliki akses ke ahli kriptografi, mungkin lebih aman dalam praktiknya untuk menggunakan fungsi hashing berulang. .
sumber
Secara umum, tidak ada keamanan tambahan untuk menggandakan hash atau menggandakan sesuatu. Jika Anda dapat memecahkan hash satu kali, Anda dapat merusaknya lagi. Biasanya tidak ada salahnya keamanan untuk melakukan ini.
Dalam contoh Anda menggunakan MD5, karena Anda mungkin tahu ada beberapa masalah tabrakan. "Double Hashing" tidak benar-benar membantu melindungi dari ini, karena tabrakan yang sama masih akan menghasilkan hash pertama yang sama, yang kemudian Anda dapat MD5 lagi untuk mendapatkan hash kedua.
Ini memang melindungi dari serangan kamus, seperti "membalikkan basis data MD5", tetapi begitu juga salting.
Pada garis singgung, Double mengenkripsi sesuatu tidak memberikan keamanan tambahan karena semua yang dilakukannya adalah menghasilkan kunci yang berbeda yang merupakan kombinasi dari dua kunci yang sebenarnya digunakan. Jadi upaya untuk menemukan "kunci" tidak berlipat ganda karena dua kunci sebenarnya tidak perlu ditemukan. Ini tidak benar untuk hashing, karena hasil hash biasanya tidak sama panjang dengan input asli.
sumber
Hash ganda masuk akal bagi saya hanya jika saya hash kata sandi pada klien, dan kemudian menyimpan hash (dengan garam berbeda) dari hash di server.
Dengan cara itu bahkan jika seseorang meretas jalannya ke server (sehingga mengabaikan keamanan yang disediakan SSL), dia masih tidak bisa mendapatkan kata sandi yang jelas.
Ya, ia akan memiliki data yang diperlukan untuk menembus ke dalam sistem, tetapi ia tidak akan dapat menggunakan data itu untuk berkompromi dengan akun luar yang dimiliki pengguna. Dan orang-orang diketahui menggunakan kata sandi yang sama untuk apa saja.
Satu-satunya cara dia bisa mendapatkan kata sandi yang jelas adalah menginstal keygen pada klien - dan itu bukan masalah Anda lagi.
Singkatnya:
sumber
Kekhawatiran tentang mengurangi ruang pencarian secara matematis benar, meskipun ruang pencarian tetap cukup besar untuk semua tujuan praktis (dengan asumsi Anda menggunakan garam), pada 2 ^ 128. Namun, karena kita berbicara tentang kata sandi, jumlah string 16-karakter yang mungkin (alfanumerik, huruf kecil, beberapa simbol dilemparkan) kira-kira 2 ^ 98, menurut perhitungan back-of-the-envelope saya. Jadi penurunan yang dirasakan dalam ruang pencarian tidak benar-benar relevan.
Selain itu, sebenarnya tidak ada perbedaan, secara kriptografis berbicara.
Meskipun ada primitif crypto yang disebut "rantai hash" - teknik yang memungkinkan Anda melakukan beberapa trik keren, seperti mengungkapkan kunci tanda tangan setelah digunakan, tanpa mengorbankan integritas sistem - dengan sinkronisasi waktu yang minimal, ini memungkinkan Anda menghindari masalah distribusi kunci awal dengan bersih. Pada dasarnya, Anda melakukan precompute set besar hash - h (h (h (h .... (h (k)) ...)))), gunakan nilai n untuk masuk, setelah interval yang ditentukan, Anda mengirim keluar kunci, dan menandatanganinya menggunakan kunci (n-1). Penerima sekarang dapat memverifikasi bahwa Anda mengirim semua pesan sebelumnya, dan tidak ada yang bisa memalsukan tanda tangan Anda sejak periode waktu validnya.
Re-hashing ratusan ribu kali seperti yang disarankan Bill hanyalah buang-buang cpu Anda .. gunakan kunci yang lebih panjang jika Anda khawatir tentang orang yang memecahkan 128 bit.
sumber
Seperti yang disarankan oleh beberapa tanggapan dalam artikel ini, ada beberapa kasus di mana ia dapat meningkatkan keamanan dan yang lain justru merusaknya. Ada solusi yang lebih baik yang pasti akan meningkatkan keamanan. Alih-alih menggandakan jumlah kali Anda menghitung hash, gandakan ukuran garam Anda, atau gandakan jumlah bit yang digunakan dalam hash, atau lakukan keduanya! Alih-alih SHA-245, melompat ke SHA-512.
sumber
Hashing ganda jelek karena itu kemungkinan besar penyerang telah membangun sebuah meja untuk datang dengan sebagian besar hash. Lebih baik garamkan hash Anda, dan campur hash bersama-sama. Ada juga skema baru untuk "menandatangani" hash (pada dasarnya pengasinan), tetapi dengan cara yang lebih aman.
sumber
Iya.
Sama sekali tidak menggunakan beberapa iterasi fungsi hash konvensional, seperti
md5(md5(md5(password)))
. pada terbaik Anda akan mendapatkan peningkatan marjinal dalam keamanan (skema seperti ini hampir tidak menawarkan perlindungan terhadap serangan GPU; hanya pipa itu.) Paling buruk, Anda mengurangi ruang hash Anda (dan dengan demikian keamanan) dengan setiap iterasi yang Anda tambahkan . Dalam keamanan, adalah bijaksana untuk menganggap yang terburuk.Jangan gunakan kata sandi yang telah dirancang oleh ahli kriptografi yang kompeten untuk menjadi kata sandi yang efektif, dan tahan terhadap serangan brute-force dan time-space. Ini termasuk bcrypt, scrypt, dan dalam beberapa situasi PBKDF2. Hash berbasis glibc SHA-256 juga dapat diterima.
sumber
Aku akan pergi mengambil risiko dan mengatakan itu lebih aman dalam keadaan tertentu ... jangan downvote saya dulu!
Dari sudut pandang matematika / kriptografis, itu kurang aman, karena alasan saya yakin orang lain akan memberi Anda penjelasan yang lebih jelas daripada yang saya bisa.
Namun , ada database besar hash MD5, yang lebih cenderung mengandung teks "kata sandi" daripada MD5 itu. Jadi dengan double-hashing, Anda mengurangi efektivitas basis data tersebut.
Tentu saja, jika Anda menggunakan garam maka keuntungan ini (kerugian?) Hilang.
sumber