Berapa panjang optimal untuk garam kata sandi pengguna? [Tutup]

128

Setiap garam sama sekali jelas akan membantu ketika pengasinan dan hashing password pengguna. Adakah praktik terbaik untuk berapa lama garam itu seharusnya? Saya akan menyimpan garam di tabel pengguna saya, jadi saya ingin tradeoff terbaik antara ukuran penyimpanan dan keamanan. Apakah garam 10 karakter acak cukup? Atau apakah saya membutuhkan sesuatu yang lebih lama?

encryption hash salt

— David
sumber

10

Saya tidak memiliki rekomendasi tentang panjang garam, tetapi jawaban yang muncul di sini memiliki banyak informasi buruk. Garam Anda seharusnya: - acak - bersifat rahasia (bukan nilai tunggal yang disimpan dalam gambar program atau file konfigurasi Anda). Garam bukan rahasia kriptografi, jadi menyimpannya di meja Anda tidak masalah. Satu-satunya tujuan dari garam adalah untuk memastikan bahwa ketika instance berbeda dari item yang sama di-hash (atau dienkripsi) maka Anda mendapatkan hasil yang berbeda.

— Michael Burr

2

Bagi mereka yang tidak tahu apa itu garam: <a href=" en.wikipedia.org/wiki/Salt_(cryptography)"> Garam (kriptografi) </a> di Wikipedia

— David Koelle

1

Atau jika ada rasio optimal untuk panjang garam dengan panjang hasil hash? Garam 8-byte mungkin cukup untuk HMAC-SHA-256, tetapi mungkin tidak untuk HMAC-SHA-512.

— Crend King

1

Garam acak secara kriptografi dengan ukuran yang sama dengan output dari fungsi hashing berarti bahwa serangan "coba semua kemungkinan garam" (ditambah kamus kata sandi) memerlukan upaya yang sama besarnya dengan serangan "coba semua hasil hash" - yang merupakan kekuatan kasar standar . Garam yang lebih pendek berarti Anda dapat memiliki kamus garam ditambah kamus kata sandi sebagai serangan brute force.

— Richard Gadsden

-1 Harus diakui tidak (bahkan berusaha) menjawab pertanyaan.

— user359996

70

Sebagian besar jawaban ini agak salah arah dan menunjukkan kebingungan antara garam dan kunci kriptografi. Tujuan memasukkan garam adalah untuk memodifikasi fungsi yang digunakan untuk hash setiap kata sandi pengguna sehingga setiap hash kata sandi yang disimpan harus diserang secara individual. Satu-satunya persyaratan keamanan adalah mereka unik per pengguna, tidak ada untungnya mereka tidak dapat diprediksi atau sulit ditebak.

Garam hanya perlu cukup lama sehingga garam setiap pengguna akan unik. Garam 64-bit acak sangat tidak mungkin untuk diulang bahkan dengan satu miliar pengguna terdaftar, jadi ini tidak masalah. Garam yang diulang sendiri adalah masalah keamanan yang relatif kecil, memungkinkan penyerang untuk mencari dua akun sekaligus tetapi secara agregat tidak akan mempercepat pencarian banyak di seluruh database. Bahkan garam 32-bit dapat diterima untuk sebagian besar keperluan, dalam kasus terburuk akan mempercepat pencarian penyerang sekitar 58%. Biaya peningkatan garam di luar 64 bit tidak tinggi tetapi tidak ada alasan keamanan untuk melakukannya.

Ada beberapa manfaat untuk juga menggunakan garam di seluruh situs di atas garam per pengguna, ini akan mencegah kemungkinan tabrakan dengan hash kata sandi yang disimpan di situs lain, dan mencegah penggunaan tabel pelangi untuk keperluan umum, meskipun bahkan 32 bit garam cukup untuk membuat tabel pelangi serangan tidak praktis.

Bahkan yang lebih sederhana - dan pengembang selalu mengabaikan hal ini - jika Anda memiliki ID pengguna unik atau nama login, itu berfungsi dengan baik sebagai garam. Jika Anda melakukan ini, Anda harus menambahkan garam di seluruh situs untuk memastikan Anda tidak tumpang tindih dengan pengguna sistem lain yang memiliki ide cemerlang yang sama.

— Keamanan
sumber

16

Ada manfaat dalam garam yang tidak dapat diprediksi. Garam yang dapat diprediksi dapat diprediksi dan digunakan dalam serangan tabel hash. Misalnya, jika garam Anda hanya userID, maka tabel hash alfa biasa yang cukup panjang akan mencakup tidak hanya semua kata sandi, tetapi semua kombinasi nama pengguna + kata sandi.

— Richard Gadsden

6

Perhatikan sehubungan dengan paragraf terakhir Anda, jika Anda menggunakan garam seluruh situs, itu harus persis seperti itu: seluruh situs. Tidak seluas aplikasi, yaitu setiap instance baru yang Anda instal dari aplikasi Anda harus menghasilkan garam baru di seluruh situs. Sebagai contoh, jika Windows menggunakan garam yang sama pada setiap database otentikasi Windows, maka akan bermanfaat untuk membuat tabel pelangi untuk garam itu, tetapi jika setiap instalasi Windows menghasilkan garam baru, maka itu tidak akan.

— Richard Gadsden

5

Masalahnya sebenarnya bukan garam yang sulit ditebak. Penyerang tidak perlu menebak garam: siapa pun yang memiliki akses ke hash sudah memiliki garam. Masalahnya adalah bahwa jika garam Anda sangat umum (seperti nama pengguna), mereka mungkin sama dengan yang ada di situs lain, dan pada saat itu penyerang membutuhkan satu set tabel pelangi yang jauh lebih kecil untuk membuat serangan layak. Inilah sebabnya mengapa ide garam per-situs disebutkan, untuk menghindari tabrakan semacam ini dengan situs lain.

— Nate CK

3

Catatan cepat: Jika menggunakan nama pengguna sebagai garam, ini bisa menjadi masalah jika nama pengguna berubah. Secara praktis, (terlepas dari apa yang dikatakan dalam dokumen desain pelanggan) saya telah menemukan bahwa pengguna sering ingin mengubah nama pengguna.

— SilentSteel

5

@ NateC-K, Ide garam per-situs yang Anda bicarakan disebut lada.

— Pacerier

35

Standar yang diterima saat ini untuk hashing kata sandi membuat garam panjang 16 karakter baru untuk setiap kata sandi dan menyimpan garam dengan hash kata sandi.

Tentu saja perawatan kriptografi yang tepat untuk membuat garam benar-benar acak harus dilakukan.

— David Schmitt
sumber

6

Karakter agak tidak jelas. Anda harus mengatakan byte .

— CodesInChaos

10

@CodesInChaos Saya percaya maksud Anda oktet ;-)

— user2864740

1

Hai! Tampaknya artikel wikipedia diubah - mungkin Anda harus merujuk ke en.wikipedia.org/wiki/PBKDF2 atau apalah?

— Boris Treukhov

5

Atau bahkan lebih baik owasp.org/index.php/Password_Storage_Cheat_Sheet

— Boris Treukhov

24

Sunting: Jawaban saya di bawah ini menjawab pertanyaan sebagaimana ditanyakan, tetapi jawaban "nyata" adalah: cukup gunakan bcrypt , scrypt , atau Argon2 . Jika Anda mengajukan pertanyaan seperti ini, Anda hampir pasti menggunakan alat pada level yang terlalu rendah.

Jujur, tidak ada alasan yang bisa dipertahankan untuk tidak membuat garam sama panjangnya dengan kata sandi hash. Jika Anda menggunakan SHA-256, maka Anda memiliki hash 256-bit. Tidak ada alasan untuk tidak menggunakan garam 256-bit.

Lebih dari 256 bit tidak akan memberi Anda peningkatan keamanan, secara matematis. Tetapi menggunakan garam yang lebih pendek selalu berakhir dengan situasi di mana meja pelangi mencapai panjang garam Anda - terutama dengan garam yang lebih pendek.

— Stephen Touset
sumber

10

Itu bukan yang kesepakatan besar; pengguna hampir tidak akan melihat perbedaan antara hash milidetik dan hash setengah detik, ditambah hashing kata sandi sebenarnya akan membutuhkan waktu lebih lama untuk memperlambat serangan brute force - meskipun tiga serangan khas yang dikunci selama 15 menit lebih baik. Apakah Anda "membuang" siklus CPU untuk melakukan ini? Ya terserah. CPU menghabiskan lebih banyak waktu idle daripada tidak di sebagian besar situs web, jadi apa masalahnya? Jika Anda mengalami masalah kinerja, diskalakan.

— Randolpho

14

Garam bertahan melawan meja pelangi. Garam 512-bit dengan hash 256-bit masih hanya akan menghasilkan 256 bit entropi pada kata sandi akhir.

— Stephen Touset

8

Hashing lambat adalah fitur, bukan bug.

— outis

7

Jika Anda memiliki hash 3-bit, garam 9999-bit Anda masih hanya akan hash hingga 3 bit entropi yang mungkin. Tabel pelangi hanya perlu menemukan tiga garam untuk setiap kata sandi yang menghasilkan output yang berbeda, yang merupakan faktor multiplikasi konstan dan dengan demikian dibuang dari big-O.

— Stephen Touset

2

.................................................. ...................................... sistem tertentu. The Tujuan dari garam adalah untuk menghentikan serangan precomputation sehingga hash tidak dapat dicari dan segera dibalik menjadi plaintext . Dengan garam 9999-bit, kata sandi Anda tetap menjadi rahasia , sedangkan dengan garam 3-bit, kata sandi Anda sekarang dikenal di seluruh dunia (dan mereka dapat menggunakannya untuk masuk ke akun Anda yang lain karena banyak orang sering menggunakan kembali kata sandi). Saya merasa lucu bahwa 5 orang di sini benar-benar telah meningkatkan komentar Anda karena kata "entropi" di dalamnya.

— Pacerier

7

Wikipedia :

Metode SHA2-crypt dan bcrypt — digunakan di Linux, BSD Unixes, dan Solaris — memiliki garam 128 bit. Nilai garam yang lebih besar ini membuat serangan perhitungan untuk hampir semua panjang kata sandi tidak mungkin dilakukan terhadap sistem ini di masa mendatang.

Garam 128-bit (16-byte) sudah cukup. Anda dapat mewakilinya sebagai urutan 128 / 4 = 32digit heksadesimal.

— Andrii Nemchenko
sumber

Tampak bagi saya bahwa contoh dari apa yang menggunakan sistem aman lainnya adalah contoh yang bagus dari apa praktik terbaiknya.

— cjbarth

1

@ mklement0 Terima kasih, saya telah memperbarui jawabannya.

— Andrii Nemchenko

2

Satu jawaban mungkin untuk menggunakan sebagai ukuran garam nilai bahwa hash yang akan Anda gunakan memberikan keamanan.

Misalnya, jika Anda akan menggunakan SHA-512, gunakan garam 256 bit karena keamanan yang disediakan oleh SHA-512 adalah 256 bit.

— Roberto Martelloni
sumber