Apakah menggunakan bcrypt(md5(pwd) + salt) merupakan praktik yang buruk?

Saya mencoba berbagi login antara aplikasi saya dan forum IPB.

Saya telah melihat bahwa Invision menyediakan modul untuk berbagi kredensial: IPS Terhubung

Sederhananya, ada aplikasi master dan satu atau beberapa budak. Budak mengirimkan kredensial yang perlu disimpan master melalui API.

Masalahnya adalah untuk metode register atau login IPB mengirimkan md5 hash kata sandi. Tidak mungkin saya menyimpan md5 di db saya jadi saya berpikir untuk menggunakan bcrypt pada hash md5 melakukan sesuatu seperti

$storedPassword = bcrypt(md5(pwd) + salt);

Apa pendapat Anda tentang alternatif ini, apakah praktik yang baik untuk melakukan hash dengan bcrypt di atas hash md5?


php passwords md5 bcrypt password-protection
person darkheir    schedule 06.05.2013    source sumber
comment
Ide buruk, melakukan hashing berkali-kali meningkatkan kemungkinan tabrakan   -  person Daniel Mensing    schedule 06.05.2013
comment
Saya pernah mendengarnya, tetapi apakah hal itu meningkatkan kemungkinan tabrakan?   -  person darkheir    schedule 06.05.2013
comment
Dua pengguna juga dapat memiliki kata sandi yang sama sebelum melakukan hashing, jadi tidak masalah jika terjadi tabrakan. Dan kemungkinan dua pengguna dengan kata sandi berbeda dan hash md5 yang sama hampir tidak ada   -  person Hugo Delsing    schedule 06.05.2013
comment
@DanielMensing Benar-benar penasaran, apa yang membuat Anda berpikir begitu?   -  person likeitlikeit    schedule 04.06.2013

Jawaban (2)


arrow_upward
1
arrow_downward

Meskipun penggunaan $storedPassword = bcrypt(md5(pwd) + salt); dalam aplikasi Anda baik-baik saja, dari segi keamanan, manfaatnya hanya sedikit. Juga tidak perlu menambahkan garam Anda sendiri ke enkripsi. bcrypt akan mengurusnya secara internal dan Anda tidak perlu menyimpan garam di mana pun.

Seorang penyerang menargetkan tautan terlemah dan jika server lain hanya menggunakan md5, mereka dapat menyerang situs tersebut untuk mendapatkan kata sandi dan tidak peduli seberapa kuat Anda mengamankannya.

Tapi sekali lagi. Menutup satu pintu masih lebih baik daripada membiarkan semuanya terbuka.

person Hugo Delsing    schedule 06.05.2013
comment
Ya tetapi situs lain tidak akan menyimpannya, ia hanya akan mengirimkan kata sandi (menggunakan md5) saat pendaftaran atau ketika pengguna mencoba masuk. Jadi bagi saya tautan yang lemah adalah mengendus koneksi antara 2 server pada saat kredensial dikirim. - person darkheir; 06.05.2013
comment
Maka pendekatan Anda baik-baik saja jika Anda menghilangkan garamnya. Untuk semua yang Anda pedulikan, pengguna memasukkan 32 karakter sebagai kata sandinya sendiri. - person Hugo Delsing; 06.05.2013
comment
Mengapa saya harus membuang garamnya? Saya pikir itulah yang membuat hashnya unik, bukan? - person darkheir; 06.05.2013
comment
Jika Anda menambahkan garam, Anda juga perlu menyimpan garam secara terpisah di database untuk dapat memeriksa kata sandi yang valid. bCrypt namun memiliki garam bawaan. Tidak perlu menambahkannya. Lihat stackoverflow.com/questions/ 6832445/ atau en.wikipedia.org/wiki/Bcrypt - person Hugo Delsing; 06.05.2013

arrow_upward
1
arrow_downward

Hal ini mengurangi keamanan.

Hash MD5 biasanya memperpendek kata sandi. Ini berarti penyerang hanya perlu melakukan iterasi pada ruang MD5. Bahkan jika Anda menganggap ruang MD5 besar, memetakan kamus kata ke dalamnya adalah hal yang sepele. Hal ini tidak memberikan manfaat apa pun, namun berpotensi mengurangi ruang.

Mengenai tabrakan: Anda tidak memenangkan lotere galaksi dengan bcrypt. Namun, dengan MD5, segala sesuatunya menjadi kurang pasti, yang merupakan alasan lain untuk menjauhinya.

Anda tidak perlu menambahkan garam, bcrypt sudah menambahkan garam yang bagus dan unik. Jika Anda menggunakan bcrypt dengan benar, Anda tidak perlu memikirkan garamnya.

Agak aneh bahwa sumber Anda hanya mengirimkan hash MD5. Saya biasanya merekomendasikan untuk mengirim kata sandi (teks biasa) melalui koneksi terenkripsi:

  • Jika koneksi dienkripsi, aman untuk mengirimkannya sebagai teks biasa.
  • Jika tidak dienkripsi, tidak masalah jika Anda meng-hash kata sandinya terlebih dahulu, penyerang tetap dapat membacanya dari jaringan.
person mafu    schedule 18.02.2016