Bagaimana kata sandi garam membantu melawan serangan tabel pelangi?

Saya mengalami kesulitan memahami tujuan dari kata sandi untuk kata sandi. Ini pemahaman saya bahwa penggunaan utama adalah untuk menghambat serangan meja pelangi. Namun, metode yang saya lihat untuk menerapkan ini tampaknya tidak benar-benar membuat masalah lebih sulit.

Saya telah melihat banyak tutorial yang menyarankan agar garam digunakan sebagai berikut:

$hash =  md5($salt.$password)

Alasannya adalah bahwa hash sekarang memetakan tidak ke kata sandi asli, tetapi kombinasi kata sandi dan garam. Tapi katakan $salt=foodan $password=bardan $hash=3858f62230ac3c915f300c664312c63f. Sekarang seseorang dengan meja pelangi bisa membalik hash dan muncul dengan input "foobar". Mereka kemudian dapat mencoba semua kombinasi kata sandi (f, fo, foo, ... oobar, obar, bar, ar, ar). Mungkin butuh beberapa milidetik lagi untuk mendapatkan kata sandi, tetapi tidak banyak lagi.

Penggunaan lain yang pernah saya lihat adalah pada sistem linux saya. Di / etc / shadow kata sandi hash sebenarnya disimpan dengan garam. Sebagai contoh, garam "foo" dan password "bar" akan hash ini: $1$foo$te5SBM.7C25fFDu6bIRbX1. Jika seorang hacker entah bagaimana bisa mendapatkan file ini, saya tidak tahu apa tujuan dari melayani garam, karena hash sebaliknya te5SBM.7C25fFDu6bIRbXdiketahui mengandung "foo".

Terima kasih atas cahaya yang dapat ditumpahkan siapa pun dalam hal ini.

EDIT : Terima kasih atas bantuannya. Untuk meringkas apa yang saya mengerti, garam membuat kata sandi hash lebih kompleks, sehingga membuatnya lebih kecil kemungkinannya ada di tabel pelangi yang telah dikomputasi. Apa yang saya salah pahami sebelumnya adalah saya berasumsi ada meja pelangi untuk SEMUA hash.

Garam publik tidak akan membuat serangan kamus lebih sulit ketika memecahkan satu kata sandi. Seperti yang telah Anda tunjukkan, penyerang memiliki akses ke kata sandi hash dan garam, sehingga saat menjalankan serangan kamus, ia dapat menggunakan garam yang dikenal saat mencoba memecahkan kata sandi.

Garam publik melakukan dua hal: membuatnya lebih memakan waktu untuk memecahkan daftar kata sandi yang besar, dan membuatnya tidak layak untuk menggunakan tabel pelangi.

Untuk memahami yang pertama, bayangkan satu file kata sandi yang berisi ratusan nama pengguna dan kata sandi. Tanpa garam, saya bisa menghitung "md5 (upaya [0])", dan kemudian memindai melalui file untuk melihat apakah hash itu muncul di mana saja. Jika ada garam, maka saya harus menghitung "md5 (garam [a]. Percobaan [0])", bandingkan dengan entri A, lalu "md5 (garam [b]. Percobaan [0])", bandingkan dengan entri B , dll. Sekarang saya memiliki nbanyak pekerjaan yang harus dilakukan, di mana njumlah nama pengguna dan kata sandi yang terkandung dalam file.

Untuk memahami yang kedua, Anda harus memahami apa itu rainbow table. Tabel pelangi adalah daftar besar hash yang sudah dihitung sebelumnya untuk kata sandi yang umum digunakan. Bayangkan lagi file kata sandi tanpa garam. Yang harus saya lakukan adalah pergi melalui setiap baris file, mengeluarkan kata sandi hash, dan mencarinya di tabel pelangi. Saya tidak pernah harus menghitung satu hash. Jika pencarian jauh lebih cepat daripada fungsi hash (yang mungkin), ini akan sangat mempercepat cracking file.

Tetapi jika file kata sandi diasinkan, maka tabel pelangi harus berisi "garam. Kata sandi" yang sudah di-hash. Jika garamnya cukup acak, ini sangat tidak mungkin. Saya mungkin akan memiliki hal-hal seperti "halo" dan "foobar" dan "qwerty" dalam daftar kata sandi yang sering digunakan, yang sudah di-hash (tabel pelangi), tetapi saya tidak akan memiliki hal-hal seperti "jX95psDZhello" atau "LPgB0sdgxfoobar" atau "dZVUABJtqwerty" sudah dihitung sebelumnya. Itu akan membuat meja pelangi sangat besar.

Jadi, garam mengurangi penyerang kembali ke satu-perhitungan-per-baris-per-upaya, yang, ketika digabungkan dengan kata sandi acak yang cukup panjang, cukup, secara umum tidak dapat dipecahkan.

Jawaban lain tampaknya tidak membahas kesalahpahaman Anda tentang topik ini, jadi begini:

Dua macam penggunaan garam

Saya telah melihat banyak tutorial yang menyarankan agar garam digunakan sebagai berikut:

$hash = md5($salt.$password)

[...]

Penggunaan lain yang pernah saya lihat adalah pada sistem linux saya. Di / etc / shadow kata sandi hash sebenarnya disimpan dengan garam.

Anda selalu harus menyimpan garam dengan kata sandi, karena untuk memvalidasi apa yang dimasukkan pengguna terhadap basis data kata sandi Anda, Anda harus menggabungkan input dengan garam, hash dan membandingkannya dengan hash yang disimpan.

Keamanan hash

Sekarang seseorang dengan meja pelangi bisa membalik hash dan muncul dengan input "foobar".

[...]

karena hash kebalikan dari te5SBM.7C25fFDu6bIRbX diketahui mengandung "foo".

Tidak mungkin membalik hash seperti itu (setidaknya secara teori). Hash "foo" dan hash "saltfoo" tidak memiliki kesamaan. Mengubah bahkan satu bit dalam input fungsi hash kriptografi harus sepenuhnya mengubah output.

Ini berarti Anda tidak dapat membuat tabel pelangi dengan kata sandi yang umum dan kemudian "memperbarui" dengan sedikit garam. Anda harus memperhitungkan garam dari awal.

Ini adalah alasan utama mengapa Anda membutuhkan meja pelangi di tempat pertama. Karena Anda tidak bisa mendapatkan kata sandi dari hash, Anda melakukan precompute semua hash dari kata sandi yang paling sering digunakan dan kemudian membandingkan hash Anda dengan hash mereka.

Kualitas garam

Tapi katakan $salt=foo

"Foo" akan menjadi pilihan garam yang sangat buruk. Biasanya Anda akan menggunakan nilai acak, yang disandikan dalam ASCII.

Juga, setiap kata sandi memiliki garam sendiri, berbeda (semoga) dari semua garam lain di sistem. Ini berarti, bahwa penyerang harus menyerang setiap kata sandi secara individual alih-alih memiliki harapan bahwa salah satu hash cocok dengan salah satu nilai dalam database-nya.

Serangan itu

Jika seorang hacker entah bagaimana bisa mendapatkan file ini, saya tidak tahu apa gunanya garam itu,

Serangan tabel pelangi selalu dibutuhkan /etc/passwd(atau database kata sandi apa pun yang digunakan), atau kalau tidak, bagaimana Anda membandingkan hash di tabel pelangi dengan hash dari kata sandi yang sebenarnya?

Adapun tujuannya: misalkan penyerang ingin membuat tabel pelangi untuk 100.000 kata bahasa Inggris dan kata sandi yang umum digunakan (pikirkan "rahasia"). Tanpa garam dia harus melakukan precompute 100.000 hash. Bahkan dengan garam UNIX tradisional 2 karakter (masing-masing adalah salah satu dari 64 pilihan [a–zA–Z0–9./]:) ia harus menghitung dan menyimpan 4.096.000.000 hash ... cukup perbaikan.

Gagasan dengan garam adalah untuk membuatnya lebih sulit ditebak dengan kekerasan daripada kata sandi berbasis karakter normal. Tabel pelangi sering dibangun dengan karakter khusus yang dipikirkan, dan tidak selalu menyertakan semua kombinasi yang mungkin (meskipun mereka bisa).

Jadi nilai garam yang baik akan menjadi bilangan bulat 128-bit acak atau lebih lama. Inilah yang membuat serangan rainbow-table gagal. Dengan menggunakan nilai garam berbeda untuk setiap kata sandi yang disimpan, Anda juga memastikan bahwa tabel pelangi dibuat untuk satu nilai garam tertentu (seperti halnya jika Anda adalah sistem populer dengan nilai garam tunggal) tidak memberi Anda akses ke semua kata sandi sekaligus.

Namun pertanyaan besar lainnya, dengan banyak jawaban yang sangat bijaksana - +1 hingga SO!

Satu hal kecil yang belum saya lihat sebutkan secara eksplisit adalah bahwa, dengan menambahkan garam acak ke setiap kata sandi, Anda benar-benar menjamin bahwa dua pengguna yang kebetulan memilih kata sandi yang sama akan menghasilkan hash yang berbeda.

Mengapa ini penting?

Bayangkan basis data kata sandi di sebuah perusahaan perangkat lunak besar di barat laut AS. Misalkan berisi 30.000 entri, di antaranya 500 memiliki layar blues sandi . Misalkan lebih lanjut bahwa seorang hacker berhasil mendapatkan kata sandi ini, katakan dengan membacanya dalam email dari pengguna ke departemen TI. Jika kata sandi tidak ditolak, peretas dapat menemukan nilai hash dalam database, lalu cukup mencocokkannya untuk mendapatkan akses ke 499 akun lainnya.

Pengasinan kata sandi memastikan bahwa masing-masing dari 500 akun memiliki keunikan (garam + kata sandi), menghasilkan hash yang berbeda untuk masing-masing akun, dan dengan demikian mengurangi pelanggaran ke satu akun. Dan mari kita berharap, dengan segala kemungkinan, bahwa setiap pengguna yang cukup naif untuk menulis kata sandi plaintext dalam pesan email tidak memiliki akses ke API tidak berdokumen untuk OS berikutnya.

Saya sedang mencari metode yang baik untuk menerapkan garam dan menemukan artikel yang sangat baik ini dengan kode sampel:

http://crackstation.net/hashing-security.htm

Penulis merekomendasikan untuk menggunakan garam acak per pengguna, sehingga mendapatkan akses ke garam tidak akan membuat seluruh daftar hash mudah diretas.

Untuk Menyimpan Kata Sandi:

• Hasilkan garam acak panjang menggunakan CSPRNG.
• Tambahkan garam ke kata sandi dan hash dengan fungsi hash kriptografis standar seperti SHA256.
• Simpan garam dan hash dalam catatan basis data pengguna.

Untuk Memvalidasi Kata Sandi:

• Ambil garam dan hash pengguna dari basis data.
• Tambahkan garam ke kata sandi yang diberikan dan hash menggunakan fungsi hash yang sama.
• Bandingkan hash dari kata sandi yang diberikan dengan hash dari database. Jika cocok, kata sandi sudah benar. Jika tidak, kata sandi salah.

Alasan mengapa garam dapat membuat serangan tabel pelangi gagal adalah karena untuk n-bit garam, tabel pelangi harus 2 kali lebih besar dari ukuran tabel tanpa garam.

Contoh Anda menggunakan 'foo' sebagai garam dapat membuat tabel pelangi 16 juta kali lebih besar.

Dengan contoh Carl tentang garam 128-bit, ini membuat tabel 2 ^ 128 kali lebih besar - sekarang besar - atau dengan kata lain, berapa lama sebelum seseorang memiliki penyimpanan portabel sebesar itu?

Sebagian besar metode pemecahan enkripsi berbasis hash bergantung pada serangan brute force. Serangan pelangi pada dasarnya adalah serangan kamus yang lebih efisien, dirancang untuk menggunakan penyimpanan digital berbiaya rendah untuk memungkinkan pembuatan peta dari sejumlah besar kata sandi yang mungkin untuk di-hash, dan memfasilitasi pemetaan terbalik. Serangan semacam ini berfungsi karena banyak kata sandi cenderung pendek atau menggunakan salah satu dari beberapa pola format berbasis kata.

Serangan seperti itu tidak efektif dalam kasus di mana kata sandi mengandung lebih banyak karakter dan tidak sesuai dengan format berbasis kata umum. Pengguna dengan kata sandi yang kuat untuk memulai tidak akan rentan terhadap gaya serangan ini. Sayangnya, banyak orang tidak memilih kata sandi yang baik. Tapi ada kompromi, Anda dapat meningkatkan kata sandi pengguna dengan menambahkan sampah acak ke dalamnya. Jadi sekarang, alih-alih "hunter2" kata sandi mereka bisa menjadi "hunter2908! Fld2R75 {R7 /; 508PEzoz ^ U430" secara efektif, yang merupakan kata sandi yang jauh lebih kuat. Namun, karena Anda sekarang harus menyimpan komponen kata sandi tambahan ini, ini mengurangi efektivitas kata sandi komposit yang lebih kuat. Ternyata, masih ada manfaat bersih untuk skema seperti itu karena sekarang setiap kata sandi, bahkan yang lemah, tidak lagi rentan terhadap hash / rainbow table yang sama yang dihitung sebelumnya. Sebaliknya, setiap entri hash kata sandi hanya rentan terhadap tabel hash yang unik.

Katakanlah Anda memiliki situs yang memiliki persyaratan kekuatan kata sandi yang lemah. Jika Anda tidak menggunakan garam kata sandi sama sekali hash Anda rentan terhadap tabel hash yang dihitung sebelumnya, seseorang dengan akses ke hash Anda akan memiliki akses ke kata sandi untuk sebagian besar pengguna Anda (namun banyak kata sandi rentan yang digunakan, yang akan menjadi persentase yang substansial). Jika Anda menggunakan garam kata sandi konstan maka tabel hash pra-dihitung tidak lagi berharga, jadi seseorang harus menghabiskan waktu untuk menghitung tabel hash khusus untuk garam itu, mereka bisa melakukannya secara bertahap, menghitung tabel yang mencakup permutasi yang semakin besar dari ruang masalah. Kata sandi yang paling rentan (mis. Kata sandi berbasis kata sederhana, kata sandi alfanumerik yang sangat singkat) akan di-crack dalam beberapa jam atau hari, kata sandi yang kurang rentan akan di-crack setelah beberapa minggu atau bulan. Seiring waktu berjalan, penyerang akan mendapatkan akses ke kata sandi untuk persentase pengguna Anda yang terus bertambah. Jika Anda menggunakan garam unik untuk setiap kata sandi maka akan butuh berhari-hari atau berbulan-bulan untuk mendapatkan akses ke masing-masing kata sandi yang rentan itu.

Seperti yang Anda lihat, ketika Anda melangkah dari tanpa garam ke garam konstan menjadi garam unik, Anda melakukan beberapa peningkatan pesanan dalam upaya untuk memecahkan kata sandi yang rentan pada setiap langkah. Tanpa garam, kata sandi pengguna Anda yang terlemah mudah diakses, dengan garam yang konstan, kata sandi yang lemah tersebut dapat diakses oleh penyerang yang ditentukan, dengan garam yang unik biaya mengakses kata sandi dinaikkan begitu tinggi sehingga hanya penyerang yang paling gigih yang dapat memperoleh akses ke bagian kecil dari kata sandi yang rentan, dan kemudian hanya dengan biaya besar.

Inilah situasi yang harus dihadapi. Anda tidak pernah dapat sepenuhnya melindungi pengguna dari pilihan kata sandi yang buruk, tetapi Anda dapat meningkatkan biaya kompromi kata sandi pengguna Anda ke tingkat yang membuat kompromi bahkan satu kata sandi pengguna sangat mahal.

Salah satu tujuan pengasinan adalah untuk mengalahkan tabel hash yang dikomputasi. Jika seseorang memiliki daftar jutaan hash yang telah dihitung sebelumnya, mereka tidak akan dapat mencari $ 1 $ foo $ te5SBM.7C25fFDu6bIRbX1 di tabel mereka meskipun mereka tahu hash dan garam. Mereka masih harus dengan paksa memaksanya.

Tujuan lain, seperti yang Carl S sebutkan adalah membuat brute memaksa daftar hash lebih mahal. (beri mereka semua garam berbeda)

Kedua tujuan ini masih tercapai meskipun garamnya adalah untuk umum.

Sejauh yang saya tahu, garam ini dimaksudkan untuk membuat serangan kamus lebih sulit.

Ini adalah fakta yang diketahui bahwa banyak orang akan menggunakan kata-kata umum untuk kata sandi dan bukannya string acak.

Jadi, seorang hacker bisa menggunakan ini untuk keuntungannya daripada menggunakan kekuatan kasar saja. Dia tidak akan mencari kata sandi seperti aaa, aab, aac ... melainkan menggunakan kata-kata dan kata sandi umum (seperti tuan nama cincin!;))

Jadi, jika kata sandi saya adalah Legolas, seorang peretas dapat mencobanya dan menebaknya dengan "beberapa" percobaan. Namun, jika kita memberi garam kata sandi dan itu menjadi fooLegolas, hash akan berbeda, sehingga serangan kamus tidak akan berhasil.

Semoga itu bisa membantu!

Saya berasumsi bahwa Anda menggunakan fungsi PHP --- md5 (), dan variabel $ preceded --- maka, Anda dapat mencoba mencari artikel ini Shadow Password HOWTO Khususnya paragraf ke-11.

Selain itu, Anda takut menggunakan algoritme intisari pesan, Anda dapat mencoba algoritme kode sandi asli, seperti yang disediakan oleh modul mcrypt , atau algoritme intisari pesan yang lebih kuat, seperti yang menyediakan modul mhash (sha1, sha256, dan lainnya).

Saya berpikir bahwa algoritma intisari pesan yang lebih kuat adalah suatu keharusan. Diketahui bahwa MD5 dan SHA1 mengalami masalah tabrakan.