Garam non-acak untuk hash kata sandi


89

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


Saya harus mengatakan saya bingung dengan banyak jawaban di bawah ini. Poin utama dari penggunaan garam hanyalah untuk mencegah serangan tabel pelangi sehingga apa pun yang unik bagi pengguna harus dilakukan karena memaksa penyerang untuk membuat ulang tabel pelangi untuk setiap garam. 2c saya.
Goran

Jika garam dibutuhkan misalnya. situs, Anda sering memiliki id di url. Jika penyerang tahu (dan kami berasumsi dia tahu) bahwa garam kata sandi adalah userid + nama pengguna, cukup mudah untuk memodifikasi serangan untuk menghindari nilai garam.
dmajkic

@dmajkic, salt dimaksudkan untuk mencegah serangan RT dan membedakan kata sandi yang sama untuk pengguna yang berbeda. Ini diberikan, bahkan dengan nama pengguna.
AviD

@ AviD: Itu benar. Tetapi jika saya tahu hash untuk pass saya, dan saya tahu bahwa salt adalah nama pengguna saya, maka saya dapat dengan mudah membuat nilai pass hash untuk kata kamus apa pun, dan membandingkannya dengan orang lain melewati hash. Itulah mengapa waktu lebih baik daripada nama pengguna.
dmajkic

1
Baru saja menemukan artikel di situs web Konsorsium Keamanan PHP yang dalam contohnya menggunakan nomor acak berciri
helloworlder

Jawaban:


156

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.


Sepakat. Saya akan lebih menekankan pada penggunaan kembali nama pengguna, karena menurut saya itu adalah serangan yang paling mungkin berhasil terhadap sistem hipotetis yang menggunakan nama pengguna sebagai garam, yang akan gagal terhadap sistem yang menggunakan garam acak.
Steve Jessop

Saya menghargai pendapat Anda tentang keamanan lintas sistem. Juga, saya rasa di masa depan tidak mungkin untuk melihat tabel pelangi khusus pengguna ...
AviD

@ AviD: Menurutmu begitu? Itu adalah vektor serangan yang cukup spesifik.
David Grant

2
Bukan untuk menghasilkan garam, tidak. Satu-satunya serangan yang dipengaruhi oleh salt adalah yang dibuat secara langsung terhadap sandi yang di-hash. Sebuah serangan tidak dapat membuat serangan semacam ini kecuali mereka memiliki salinan basis data kata sandi Anda, yang juga akan berisi garam. Karena penyerang sudah memiliki garam yang dimilikinya, mereka hanya memerlukan entropi yang cukup untuk menghindari beberapa kata sandi yang di-hash dengan garam yang sama, yang akan disediakan oleh setiap RNG dasar (P).
Dave Sherohman

3
@ acidzombie24: Menggunakan satu garam tetap (biasanya disebut "nonce" menurut pengalaman saya) untuk semua sandi kurang aman dibandingkan menggunakan garam acak unik untuk setiap sandi, karena masih memungkinkan penyerang menentukan dengan mudah apakah dua atau lebih akun berbagi kata sandi yang sama. Di sisi lain, nonce kemungkinan akan disimpan dalam kode Anda daripada di database, jadi penyerang yang hanya memiliki database Anda tidak akan memiliki akses ke sana; Karena itu, opsi paling aman adalah menggunakan nonce di seluruh sistem (disimpan dalam kode) dan salt per sandi (disimpan dalam database).
Dave Sherohman

29

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.


1 untuk titik yang baik, namun, Anda sedang berbicara tentang berpotensi besar tabel pelangi. Untuk menutupi semua nilai panjang gsMyPassword (dengan asumsi alfanumerik kasus campuran) memerlukan 36 ^ 12 baris dalam tabel!
David Grant

Sebagai tindak lanjut: proyek tabel pelangi terdistribusi memiliki 63.970 hash retak, tetapi 36 ^ 12 adalah 4.738.381.338.321.616.896!
David Grant

Terima kasih, dan ini memang masuk akal - tetapi seperti yang ditunjukkan oleh Mr. PotatoHead, Anda masih memperluas ruang Anda melebihi kemungkinan cracking yang wajar dengan RT. Juga, dengan asumsi nama pengguna saya setidaknya 6-8 karakter - nilai tambahan apa yang diperlukan entropi?
AviD

@ Potato: Anda menganggap tabel pelangi berisi semua kemungkinan kombinasi karakter alfanumerik. Ini tidak perlu menjadi kasus, tabel pelangi yang efektif akan berisi hash untuk kata sandi / hash umum. Garam ada untuk melindungi dari serangan kamus atau gabungan tabel / kamus.
Guillaume

3
Menggunakan nama pengguna sebagai garam juga merupakan ide buruk untuk sistem di mana terdapat akun dengan hak istimewa tinggi yang dapat diprediksi: "Administrator" di Windows, "root" di * nix, "sa" di MSSQL, dll.
tidak ada

8

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 yakin Anda benar bahwa ini sudah cukup. Namun, mengingat bahwa hash adalah bidang matematika yang rumit dan sangat mungkin bahwa garam dengan entropi rendah membuat hash lebih mudah ditebak di masa mendatang, (terutama saat hash rusak), saya tidak akan bertaruh pada keamanan, ketika terbukti solusi yang lebih aman tidak jauh lebih mahal.
Georg Schölly

7

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


Saya suka ide untuk mengikat kata sandi ke pengguna. Tetapi jika penyerang dapat mengubah kata sandi, dia pasti juga dapat mengubah id.
Georg Schölly

Tergantung pada ID-nya: Saya menggunakan kunci utama tabel, yang tidak dapat Anda ubah sesuka hati. TBH, jika peretas menulis ke database Anda, Anda sudah berada dalam masalah yang cukup besar ...
teedyay

3
Tidak, saya menyukainya. Seorang penyerang sering kali merupakan "orang dalam". Saya bisa membayangkan skenario di mana apa yang dia cari tidak ada di database, tetapi jika dia bisa menimpa kredensial di database, dia bisa mengotentikasi dirinya sendiri untuk melakukan apa yang dia inginkan.
erickson

1
Poin yang bagus. Kami merasa semakin sulit untuk menambahkan pengguna pertama ke database baru: kami telah secara efektif membuat aplikasi kami begitu aman sehingga kami hampir tidak dapat meretasnya sendiri. [Selain itu, gunakan salt khusus aplikasi sehingga Anda tidak dapat menyalin kredensial dari satu database ke database lain.]
teedyay

Akhirnya saya menemukan seseorang mengatakan ini: menambahkan sesuatu yang spesifik untuk pengguna ke garam. Tindakan itu menghindari penyusup untuk menyalin beberapa kredensial ke pengguna lain, dan juga mencegah peretas menebak sandi apa pun jika ia berhasil menjangkau bidang hash dan garam Anda di tabel. Satu hal lagi yang ingin saya lakukan: tidak menggunakan angka bulat dari iterasi dalam hashing. Jangan pergi untuk 10k atau 20k, melainkan sesuatu seperti 19835.
Andrew

3

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.


2
Inti dari tabel pelangi adalah bahwa nilainya sudah dibuat sebelumnya, dan jika Anda membuat tabel untuk nilai (misalnya kata sandi) PLUS konstanta yang diberikan, itu adalah tabel yang sama sekali berbeda, dan Anda mungkin juga hanya coba hasil hash secara langsung. :)
David Grant

1
Hash konstan tidak ada artinya. Semua kata sandi dapat diretas menggunakan tabel pelangi tunggal. Tujuan dari garam adalah tidak mungkin membuat tabel pelangi.
Georg Schölly

1
@gs - Saya tidak mengerti mengapa Anda tidak dapat membuat tabel pelangi yang "menyertakan" efek garam konstan. Ruang serangan (kata sandi) tidak akan berubah, jadi tabel tidak perlu bertambah, cukup dihitung ulang.
HUAGHAGUAH

@ Kentang - tergantung pada pengorbanannya. Jika 20k login perusahaan Anda semuanya di-hash dengan garam konstan yang sama, mungkin lebih murah untuk menghitung tabel pelangi baru daripada menyerang kamus semuanya satu per satu. Oleh karena itu penekanan saya pada "BULK".
HUAGHAGUAH

3

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.


3
"Intinya adalah agar Anda tidak dapat menggunakan tabel pelangi standar untuk menyelesaikan setiap sandi dalam database". Saya tidak setuju. Intinya adalah agar Anda tidak dapat menggunakan tabel pelangi standar untuk menyelesaikan kata sandi apa pun . Jika salt adalah nama pengguna, maka tabel pelangi untuk "root" dapat memecahkan pw root.
Steve Jessop

Itu mungkin tentang satu-satunya aturan yang benar-benar penting. Pada dasarnya Anda ingin kata sandi menjadi sesuatu yang unik di sistem Anda, tetapi tidak masalah apa itu. Itu masih bisa menjadi sesuatu yang sederhana. Anda tidak membutuhkan banyak entropi.
Kibbee

Ini juga pemikiran saya - tapi saya terjebak pada "mungkin baik-baik saja". Saya masih tidak melihat teori ini dibuktikan - atau setidaknya diverifikasi bahwa tidak ada implikasi kriptanalisis.
AviD

@onebyone: Jika salt terdiri dari nama pengguna + nilai lokal konstan (saya sering menggunakan ':'), maka itu masih merusak RT standar, kecuali ada variasi di antaranya yang menyertakan nama pengguna umum dan nilai garam statis umum. Saya agak curiga bukan itu masalahnya.
nsayer

Bersama dengan nsayer. Anda dapat menggunakan string konstan seluruh sistem, yang tidak akan ada RT yang dibuat sebelumnya, seperti # (D83d8, bersama dengan nama pengguna sebagai salt, dan itu mungkin akan mencegah serangan tabel pelangi.
Kibbee

3

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.


Kekuatan fungsinya tidak berubah, tetapi hasilnya pasti berubah. Jika input dapat dipengaruhi atau diketahui, maka mungkin ada sesuatu yang dapat disimpulkan tentang nilai hash. Itulah risikonya.
Martin Carpenter

@Martin: Satu-satunya hal yang harus dapat Anda simpulkan dari nilai hash jika Anda memiliki kecocokan atau tidak! Menempatkan "roota" atau "rootb" (di mana "a" dan "b" mewakili kata sandi) ke dalam fungsi hash akan memberi Anda keluaran yang sangat berbeda.
David Grant

Garam diketahui oleh penyerang menggunakan tabel pelangi.
Georg Schölly

Server harus mengetahui garam yang tidak terenkripsi (untuk memeriksa kata sandi terhadap hash), sehingga orang dapat menerima begitu saja bahwa penyerang memiliki akses ke garam, atau bisa mendapatkannya dengan sangat mudah.
Georg Schölly

Benar, benar, itu sudah diberikan - untuk lebih spesifik yang saya maksudkan adalah kekuatan dari keseluruhan cryptosystem (atau -subsystem, wrt hashes).
AviD

1

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.


Sekali lagi, saya tidak mengacu pada penggunaan satu garam konstan - bukan nilai yang tidak acak, tetapi unik bagi pengguna. Misalnya userId.
AviD

Intinya adalah bahwa nilai garam Anda tidak boleh konstan. Setiap hal yang Anda hash, apakah nilai "input" yang sama atau tidak harus memiliki salt yang berbeda. Dave Sherohman menjelaskan kelemahan penggunaan bahkan nilai unik pengguna yang pada dasarnya tetap sama dengan setiap perhitungan hash.
CraigTP

-1

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.


Saya tidak mengerti komentar ini. Anda mengucapkan "gunakan entropi", lalu: "gunakan waktu" ??
Martin Carpenter

jika Nama pengguna digunakan untuk garam, itu 'tidak cukup entropis. Tetapi jika Anda menggunakan nama pengguna + tanggal saat ini - ya, karena sulit untuk menebak kapan tepatnya garam dibuat.
dmajkic

"cukup entropis" adalah subjektif; itu standarmu. Mendasarkan nilai ini pada waktu mungkin tidak cukup.
Martin Carpenter

Tidak ada yang namanya "keacakan benar yang mutlak". Adalah tanggung jawab kita untuk mengatakan kapan itu "cukup baik". Jika Anda berpikir bahwa dalam hal ini waktu tidak cukup baik, gunakan yang lain. stackoverflow.com/questions/84556/…
dmajkic

Sebenarnya, intinya adalah membuat setiap hasil hash menjadi unik - untuk mencegah (a) serangan tabel pelangi, dan (b) identifikasi sandi yang identik. Pertanyaannya adalah, untuk apa lagi entropi dibutuhkan?
AviD
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.