Garam non-acak untuk hash kata sandi

PEMBARUAN: Baru-baru ini saya belajar dari pertanyaan ini bahwa dalam seluruh diskusi di bawah ini, saya (dan saya yakin orang lain juga melakukannya) agak membingungkan: Apa yang terus saya sebut tabel pelangi, sebenarnya disebut tabel hash. Tabel pelangi adalah makhluk yang lebih kompleks, dan sebenarnya merupakan varian dari Hellman Hash Chains. Meskipun saya yakin jawabannya masih sama (karena tidak sampai pada pembacaan sandi), beberapa diskusi mungkin sedikit miring.
Pertanyaannya: " Apakah tabel pelangi itu dan bagaimana penggunaannya? "

Biasanya, saya selalu merekomendasikan penggunaan nilai acak yang kuat secara kriptografik seperti salt, untuk digunakan dengan fungsi hash (misalnya untuk kata sandi), seperti untuk melindungi dari serangan Rainbow Table.

Tetapi apakah sebenarnya garam perlu secara kriptografik menjadi acak? Apakah nilai unik apa pun (unik per pengguna, mis. UserId) cukup dalam hal ini? Ini sebenarnya akan mencegah penggunaan satu Tabel Pelangi untuk memecahkan semua (atau sebagian besar) kata sandi dalam sistem ...
Tetapi apakah kurangnya entropi benar-benar melemahkan kekuatan kriptografi dari fungsi hash?

Catatan, saya tidak bertanya tentang mengapa menggunakan garam, bagaimana melindunginya (tidak perlu), menggunakan hash konstan tunggal (jangan), atau jenis fungsi hash apa yang digunakan.
Apakah garam membutuhkan entropi atau tidak.

Terima kasih atas jawabannya sejauh ini, tetapi saya ingin fokus pada area yang (sedikit) kurang saya kenal. Implikasi utamanya untuk kriptanalisis - saya akan sangat menghargai jika ada yang memiliki masukan dari PoV matematika-kripto.
Selain itu, jika ada vektor tambahan yang belum dipertimbangkan, itu juga merupakan masukan yang bagus (lihat poin @Dave Sherohman pada beberapa sistem).
Di luar itu, jika Anda memiliki teori, ide, atau praktik terbaik - harap dukung ini dengan bukti, skenario serangan, atau bukti empiris. Atau bahkan pertimbangan yang valid untuk trade-off yang dapat diterima ... Saya akrab dengan Praktik Terbaik (huruf besar B kapital P) tentang masalah ini, saya ingin membuktikan nilai apa yang sebenarnya diberikan ini.

EDIT: Beberapa jawaban yang sangat bagus di sini, tapi saya pikir seperti yang dikatakan @Dave, itu turun ke Tabel Pelangi untuk nama pengguna umum ... dan kemungkinan nama yang kurang umum juga. Namun, bagaimana jika nama pengguna saya unik secara global? Tidak selalu unik untuk sistem saya, tetapi untuk setiap pengguna - mis. Alamat email.
Tidak akan ada insentif untuk membangun RT untuk satu pengguna (seperti yang ditekankan @Dave, garam tidak dirahasiakan), dan ini masih akan mencegah pengelompokan. Satu-satunya masalah adalah saya mungkin memiliki email dan kata sandi yang sama di situs yang berbeda - tetapi garam tidak akan mencegahnya.
Jadi, kembali ke pembacaan sandi - APAKAH entropi diperlukan, atau tidak? (Pemikiran saya saat ini adalah tidak perlu dari sudut pandang kriptanalisis, tetapi dari alasan praktis lainnya.)

Salt secara tradisional disimpan sebagai awalan untuk kata sandi yang di-hash. Ini sudah diketahui oleh penyerang mana pun yang memiliki akses ke hash kata sandi. Menggunakan nama pengguna sebagai salt atau tidak tidak mempengaruhi pengetahuan itu dan, oleh karena itu, tidak akan berpengaruh pada keamanan sistem tunggal.

Namun, menggunakan nama pengguna atau nilai lain yang dikontrol pengguna sebagai salt akan mengurangi keamanan lintas sistem, karena pengguna yang memiliki nama pengguna dan sandi yang sama di beberapa sistem yang menggunakan algoritme hashing sandi yang sama akan berakhir dengan hash sandi yang sama di masing-masing sistem tersebut. Saya tidak menganggap ini sebagai tanggung jawab yang signifikan karena saya, sebagai penyerang, akan mencoba kata sandi yang diketahui telah digunakan oleh akun target pada sistem lain terlebih dahulu sebelum mencoba cara lain untuk menyusupi akun. Hash identik hanya akan memberi tahu saya sebelumnya bahwa kata sandi yang diketahui akan berfungsi, mereka tidak akan membuat serangan yang sebenarnya lebih mudah. (Namun, perhatikan bahwa perbandingan cepat database akun akan memberikan daftar target dengan prioritas lebih tinggi, karena ini akan memberi tahu saya siapa dan siapa yang tidak menggunakan ulang kata sandi.)

Bahaya yang lebih besar dari gagasan ini adalah bahwa nama pengguna biasanya digunakan kembali - hampir semua situs yang ingin Anda kunjungi akan memiliki akun pengguna bernama "Dave", misalnya, dan "admin" atau "root" bahkan lebih umum - yang akan membuat konstruksi tabel pelangi yang menargetkan pengguna dengan nama-nama umum tersebut jauh lebih mudah dan lebih efektif.

Kedua kelemahan ini dapat diatasi secara efektif dengan menambahkan nilai garam kedua (baik tetap dan tersembunyi atau terbuka seperti garam standar) ke kata sandi sebelum melakukan hashing, tetapi, pada titik itu, Anda mungkin juga hanya menggunakan garam entropik standar sebagai gantinya. menggunakan nama pengguna di dalamnya.

Diedit menjadi Tambah: Banyak orang berbicara tentang entropi dan apakah entropi dalam garam itu penting. Memang, tetapi bukan karena alasan sebagian besar komentar di dalamnya tampaknya berpikir.

Pemikiran umum tampaknya bahwa entropi itu penting sehingga garam akan sulit ditebak oleh penyerang. Ini tidak benar dan, pada kenyataannya, sama sekali tidak relevan. Seperti yang telah ditunjukkan beberapa kali oleh berbagai orang, serangan yang akan dipengaruhi oleh garam hanya dapat dilakukan oleh seseorang dengan basis data kata sandi dan seseorang dengan basis data kata sandi hanya dapat melihat untuk melihat apa garam setiap akun. Entah itu bisa ditebak atau tidak, tidak masalah kapan Anda bisa mencarinya dengan sepele.

Alasan pentingnya entropi adalah untuk menghindari pengelompokan nilai garam. Jika salt didasarkan pada nama pengguna dan Anda tahu bahwa kebanyakan sistem akan memiliki akun bernama "root" atau "admin", maka Anda dapat membuat tabel pelangi untuk kedua garam tersebut dan ini akan memecahkan sebagian besar sistem. Sebaliknya, jika garam 16-bit acak digunakan dan nilai acak memiliki distribusi yang kira-kira sama, maka Anda memerlukan tabel pelangi untuk semua 2 ^ 16 kemungkinan garam.

Ini bukan tentang mencegah penyerang mengetahui apa garam akun individu, ini tentang tidak memberi mereka target besar dan gemuk dari satu garam yang akan digunakan pada sebagian besar target potensial.

Menggunakan garam dengan entropi tinggi mutlak diperlukan untuk menyimpan kata sandi dengan aman.

Ambil nama pengguna saya 'gs' dan tambahkan ke kata sandi saya 'Kata Sandi Saya' memberi gsMyPassword. Ini mudah dipecahkan menggunakan rainbow-table karena jika nama pengguna tidak memiliki cukup entropi, bisa jadi nilai ini sudah disimpan di tabel pelangi, terutama jika nama penggunanya pendek.

Masalah lainnya adalah serangan di mana Anda tahu bahwa pengguna berpartisipasi dalam dua atau lebih layanan. Ada banyak nama pengguna yang umum, mungkin yang paling penting adalah admin dan root. Jika seseorang membuat tabel pelangi yang memiliki garam dengan nama pengguna yang paling umum, dia dapat menggunakannya untuk menyusupi akun.

Mereka dulu memiliki garam 12-bit . 12 bit adalah 4096 kombinasi berbeda. Itu belum cukup aman karena banyak informasi dapat dengan mudah disimpan sekarang . Hal yang sama berlaku untuk 4096 nama pengguna yang paling sering digunakan. Sepertinya beberapa pengguna Anda akan memilih nama pengguna yang termasuk dalam nama pengguna yang paling umum.

Saya telah menemukan pemeriksa kata sandi ini yang berfungsi untuk mengetahui entropi kata sandi Anda. Memiliki entropi yang lebih kecil dalam kata sandi (seperti dengan menggunakan nama pengguna) membuatnya lebih mudah untuk rainbowtables karena mereka mencoba untuk menutupi setidaknya semua kata sandi dengan entropi rendah, karena mereka lebih mungkin terjadi.

Memang benar bahwa hanya nama pengguna yang mungkin bermasalah karena orang mungkin berbagi nama pengguna di antara situs web yang berbeda. Tetapi seharusnya tidak bermasalah jika pengguna memiliki nama yang berbeda di setiap situs web. Jadi mengapa tidak membuatnya unik di setiap situs web. Hash sandi agak seperti ini

hashfunction ("www.yourpage.com /" + username + "/" + password)

Ini seharusnya menyelesaikan masalah. Saya bukan ahli kriptanalisis, tapi saya yakin ragu bahwa fakta bahwa kita tidak menggunakan entropi tinggi akan membuat hash semakin lemah.

Saya suka menggunakan keduanya: salt per record acak dengan entropi tinggi, ditambah ID unik dari record itu sendiri.

Meskipun ini tidak menambah banyak keamanan terhadap serangan kamus, dll., Ini menghapus kasus pinggiran di mana seseorang menyalin garam dan hash mereka ke catatan lain dengan tujuan mengganti kata sandi dengan milik mereka sendiri.

(Memang sulit untuk memikirkan keadaan di mana ini berlaku, tetapi saya tidak melihat ada salahnya sabuk dan kawat gigi dalam hal keamanan.)

Jika garam diketahui atau mudah ditebak, Anda tidak meningkatkan kesulitan serangan kamus. Bahkan dimungkinkan untuk membuat tabel pelangi yang dimodifikasi yang memperhitungkan garam "konstan".

Menggunakan garam unik meningkatkan kesulitan serangan kamus BULK.

Idealnya, memiliki nilai garam yang unik dan kuat secara kriptografis.

Saya akan mengatakan bahwa selama garam berbeda untuk setiap kata sandi, Anda mungkin akan baik-baik saja. Inti dari salt, adalah agar Anda tidak dapat menggunakan tabel rainbow standar untuk menyelesaikan setiap password dalam database. Jadi, jika Anda menerapkan salt yang berbeda ke setiap kata sandi (meskipun tidak acak), penyerang pada dasarnya harus menghitung tabel pelangi baru untuk setiap kata sandi, karena setiap kata sandi menggunakan garam yang berbeda.

Menggunakan salt dengan lebih banyak entropi tidak banyak membantu, karena penyerang dalam hal ini diasumsikan sudah memiliki database. Karena Anda harus dapat membuat ulang hash, Anda harus sudah mengetahui apa itu garam. Jadi, Anda harus menyimpan garam, atau nilai yang membentuk garam di file Anda. Dalam sistem seperti Linux, metode untuk mendapatkan garam diketahui, jadi tidak ada gunanya memiliki garam rahasia. Anda harus berasumsi bahwa penyerang yang memiliki nilai hash Anda, mungkin juga mengetahui nilai garam Anda.

Kekuatan fungsi hash tidak ditentukan oleh inputnya!

Menggunakan garam yang diketahui penyerang jelas membuat pembuatan tabel pelangi (terutama untuk nama pengguna berkode keras seperti root ) lebih menarik, tetapi itu tidak melemahkan hash . Menggunakan garam yang tidak diketahui penyerang akan membuat sistem lebih sulit untuk menyerang.

Penggabungan nama pengguna dan kata sandi mungkin masih memberikan entri untuk tabel pelangi cerdas, jadi menggunakan garam rangkaian karakter pseudo-random, disimpan dengan kata sandi yang di-hash mungkin merupakan ide yang lebih baik. Sebagai ilustrasi, jika saya memiliki nama pengguna "kentang" dan sandi "bir", masukan gabungan untuk hash Anda adalah "potatobeer", yang merupakan entri yang wajar untuk tabel pelangi.

Mengubah salt setiap kali pengguna mengubah sandi mereka mungkin membantu untuk mengalahkan serangan yang berkepanjangan, seperti halnya penegakan kebijakan sandi yang wajar, misalnya huruf campuran, tanda baca, panjang minimum, perubahan setelah n minggu.

Namun, menurut saya pilihan algoritma intisari Anda lebih penting. Penggunaan SHA-512 akan terbukti lebih merepotkan bagi seseorang yang membuat tabel pelangi daripada MD5, misalnya.

Salt harus memiliki entropi sebanyak mungkin untuk memastikan bahwa jika nilai input yang diberikan di-hash beberapa kali, nilai hash yang dihasilkan akan, sedekat mungkin, selalu berbeda.

Menggunakan nilai salt yang selalu berubah dengan entropi sebanyak mungkin di dalam salt akan memastikan bahwa kemungkinan hashing (katakanlah, password + salt) akan menghasilkan nilai hash yang sama sekali berbeda.

Semakin sedikit entropi dalam garam, semakin besar peluang Anda menghasilkan nilai garam yang sama, karena semakin besar peluang Anda untuk menghasilkan nilai hash yang sama.

Ini adalah sifat dari nilai hash menjadi "konstan" ketika input diketahui dan "konstan" yang memungkinkan serangan kamus atau tabel pelangi menjadi begitu efektif. Dengan memvariasikan nilai hash yang dihasilkan sebanyak mungkin (dengan menggunakan nilai garam entropi tinggi) memastikan bahwa hashing input yang sama + garam-acak akan menghasilkan banyak hasil nilai hash yang berbeda, sehingga mengalahkan (atau setidaknya sangat mengurangi efektivitas) tabel pelangi serangan.

Entropi adalah titik nilai Salt.

Jika ada beberapa "matematika" sederhana dan dapat direproduksi di belakang garam, maka itu sama dengan garam tidak ada. Menambahkan nilai waktu saja sudah cukup.