Apakah SHA-1 aman untuk penyimpanan kata sandi?


148

Kesimpulan: SHA-1 aman seperti apa pun terhadap serangan preimage, namun mudah untuk dihitung, yang berarti lebih mudah untuk memasang serangan bruteforce atau kamus. (Hal yang sama berlaku untuk penerus seperti SHA-256.) Tergantung pada keadaan, fungsi hash yang dirancang untuk menjadi mahal secara komputasi (seperti bcrypt) mungkin merupakan pilihan yang lebih baik.


Beberapa orang sering berkomentar seperti "SHA-1 sudah rusak", jadi saya mencoba memahami apa artinya itu. Mari kita asumsikan saya memiliki basis data hash kata sandi SHA-1, dan seorang penyerang dengan algoritma pemecahan SHA-1 yang canggih dan botnet dengan 100.000 mesin dapat mengaksesnya. (Memiliki kendali atas 100k komputer rumah berarti mereka dapat melakukan sekitar 10 ^ 15 operasi per detik.) Berapa banyak waktu yang mereka perlukan untuk

  1. mencari tahu kata sandi salah satu pengguna?
  2. cari tahu kata sandi pengguna yang diberikan?
  3. cari tahu kata sandi semua pengguna?
  4. menemukan cara untuk masuk sebagai salah satu pengguna?
  5. menemukan cara untuk masuk sebagai pengguna tertentu?

Bagaimana itu berubah jika kata sandi diasinkan? Apakah metode salting (prefix, postfix, keduanya, atau sesuatu yang lebih rumit seperti xor-ing) penting?

Inilah pemahaman saya saat ini, setelah beberapa googling. Harap perbaiki dalam jawaban jika saya salah mengerti sesuatu.

  • Jika tidak ada garam, serangan pelangi akan segera menemukan semua kata sandi (kecuali yang sangat panjang).
  • Jika ada garam acak yang cukup panjang, cara paling efektif untuk mengetahui kata sandi adalah serangan brute force atau kamus. Baik serangan tabrakan maupun preimage tidak membantu menemukan kata sandi yang sebenarnya, jadi serangan kriptografis terhadap SHA-1 tidak membantu di sini. Bahkan tidak masalah apa algoritma yang digunakan - seseorang bahkan bisa menggunakan MD5 atau MD4 dan kata sandi akan sama amannya (ada sedikit perbedaan karena menghitung hash SHA-1 lebih lambat).
  • Untuk mengevaluasi seberapa aman "sama amannya", mari kita asumsikan bahwa menjalankan tunggal sha1 membutuhkan 1000 operasi dan kata sandi berisi huruf besar, huruf kecil dan angka (yaitu, 60 karakter). Itu berarti penyerang dapat menguji 10 15 * 60 * 60 * 24/1000 ~ = 10 17 kata sandi potensial sehari. Untuk serangan brute force, itu berarti menguji semua kata sandi hingga 9 karakter dalam 3 jam, hingga 10 karakter dalam seminggu, hingga 11 karakter dalam setahun. (Dibutuhkan 60 kali lebih banyak untuk setiap karakter tambahan.) Serangan kamus jauh, jauh lebih cepat (bahkan penyerang dengan komputer tunggal dapat melakukannya dalam hitungan jam), tetapi hanya menemukan kata sandi yang lemah.
  • Untuk masuk sebagai pengguna, penyerang tidak perlu mencari tahu kata sandi yang tepat; itu cukup untuk menemukan string yang menghasilkan hash yang sama. Ini disebut serangan preimage pertama. Sejauh yang saya bisa temukan, tidak ada serangan preimage terhadap SHA-1. (Serangan bruteforce akan membutuhkan 2 160 operasi, yang berarti penyerang teoretis kita akan memerlukan 10 30 tahun untuk menariknya. Batas kemungkinan teoretis sekitar 260 operasi, di mana serangan itu akan memakan waktu beberapa tahun.) Ada serangan preimage terhadap versi SHA-1 yang berkurang dengan efek yang dapat diabaikan (untuk SHA-1 yang berkurang yang menggunakan 44 langkah alih-alih 80, waktu serangan turun dari 2 160 operasi menjadi 2 157). Ada serangan tabrakan terhadap SHA-1 yang berada dalam kemungkinan teoritis ( yang terbaik yang saya temukan membawa waktu dari 2 80 ke 2 52 ), tetapi itu tidak berguna terhadap hash kata sandi, bahkan tanpa salting.

Singkatnya, menyimpan kata sandi dengan SHA-1 tampaknya sangat aman. Apakah saya melewatkan sesuatu?

Update: Marcelo menunjukkan sebuah artikel yang menyebutkan serangan preimage kedua di 2 106 operasi . ( Sunting: Seperti dijelaskan Thomas , serangan ini adalah konstruksi hipotetis yang tidak berlaku untuk skenario kehidupan nyata.) Saya masih tidak melihat bagaimana ini mengeja bahaya untuk penggunaan SHA-1 sebagai fungsi derivasi kunci, meskipun. Adakah umumnya alasan yang bagus untuk berpikir bahwa serangan tabrakan atau serangan preimage kedua pada akhirnya dapat berubah menjadi serangan preimage pertama?


Ini sekarang berusia 7 tahun dan banyak yang telah terjadi sejak diedit terakhir kali. SHA-1 tidak lagi dianggap cukup aman untuk hashing kata sandi
GordonM

@ LordonM apa yang terjadi? Dengan pertumbuhan kekuatan komputasi, serangan tabrakan SHA-1 menjadi lebih dan lebih praktis tetapi mereka tidak benar-benar relevan di sini. SHA-1 tidak pernah benar-benar aman untuk hashing kata sandi (hash cepat umumnya tidak), tetapi sejauh ini, masih AFAIK.
Tgr

SHA-1 tidak pernah aman untuk hashing kata sandi karena tidak pernah berniat untuk mengamankan kata sandi ...
Azxdreuwa

Jawaban:


209

Jawaban singkat untuk pertanyaan Anda adalah: SHA-1 aman seperti yang Anda dapatkan. MD5 juga akan baik-baik saja, bahkan MD4; tetapi bisa membuat beberapa investor gugup. Untuk hubungan masyarakat , yang terbaik adalah menggunakan fungsi hash "lebih baik", misalnya SHA-256, bahkan jika Anda memotong outputnya menjadi 160 atau 128 bit (untuk menghemat biaya penyimpanan). Beberapa kandidat SHA-3 round-2 nampaknya lebih cepat dari SHA-1 sementara bisa dibilang "lebih aman"; namun mereka masih agak baru, jadi tetap menggunakan SHA-256 atau SHA-512 akan menjadi rute yang lebih aman saat ini. Itu akan membuat Anda terlihat profesional dan berhati-hati, yang bagus.

Perhatikan bahwa "seaman Anda bisa mendapatkan" tidak sama dengan "sangat aman". Lihat di bawah untuk penjelasan yang agak panjang.

Tentang serangan yang diketahui:

Serangan yang diketahui pada MD4, MD5 dan SHA-1 adalah tentang tabrakan, yang tidak mempengaruhi resistensi preimage. Telah ditunjukkan bahwa MD4 memiliki beberapa kelemahan yang dapat (hanya secara teoritis) dieksploitasi ketika mencoba untuk memecahkan HMAC / MD4, tetapi ini tidak berlaku untuk masalah Anda. Serangan preimage 2 106 detik di koran oleh Kesley dan Schneier adalah trade-off generik yang hanya berlaku untuk input yang sangat panjang ( 260 byte; itu satu juta terabyte - perhatikan bagaimana 106 + 60 melebihi 160; di situlah Anda melihat bahwa trade-off tidak memiliki keajaiban di dalamnya).

Sisa dari pesan ini mengasumsikan bahwa fungsi hash yang Anda gunakan (misalnya SHA-1) adalah "kotak hitam" tanpa properti khusus yang dapat digunakan penyerang. Itulah yang Anda miliki sekarang bahkan dengan fungsi hash "rusak" MD5 dan SHA-1.

Tentang tabel pelangi:

"Serangan pelangi" sebenarnya berbagi biaya dari serangan kamus atau brute force. Ini adalah turunan dari trade-off waktu-memori yang pertama kali dijelaskan oleh Hellman pada tahun 1980. Dengan asumsi Anda memiliki N kata sandi yang mungkin (itu ukuran kamus Anda, atau 2 n jika Anda mempertimbangkan dengan kasar memaksa fungsi hash dengan output dari n bits), ada serangan time-sharing di mana Anda melakukan precompute password hash N dan menyimpannya dalam tabel besar. Jika Anda mengurutkan output hash, Anda bisa mendapatkan kata sandi Anda dalam satu pencarian. Meja pelangi adalah cara cerdas untuk menyimpan meja itu dengan ruang yang jauh berkurang. Anda hanya menyimpan N / t kata sandi hash, dan Anda memecahkan kata sandi dengan O (t 2 ) pencarian. Tabel pelangi memungkinkan Anda untuk secara virtual menangani tabel prakomputasi yang jauh lebih besar daripada yang Anda simpan secara realistis.

Namun, pelangi atau tidak, penyerang masih harus menjalankan serangan penuh setidaknya sekali. Ini dapat dilihat sebagai beberapa lapisan optimisasi berturut-turut:

  1. Serangan brute-force / dictionary menelan biaya N untuk memecahkan setiap kata sandi.
  2. Dengan tabel yang dihitung sebelumnya, penyerang membayar biaya N sekali dan setelah itu dapat menyerang banyak kata sandi dengan biaya ekstra per kata sandi yang sangat kecil.
  3. Jika tabel yang dihitung sebelumnya adalah tabel pelangi, maka N dapat menjadi agak lebih besar, karena biaya penyimpanan berkurang. Kemacetan pada N menjadi kekuatan CPU yang dapat dikerahkan penyerang, bukan ukuran hardisknya.

Jika N cukup besar sehingga biaya CPU untuk hashing kata sandi N menggelikan, maka serangan seperti itu tidak layak, terlepas dari apakah tabel pelangi digunakan atau tidak. Ini berarti bahwa fungsi hash (preimage-resistant) dengan output 80 bit atau lebih sudah cukup untuk membuat serangan brute-force tidak layak.

Tentang garam:

Garam adalah cara untuk mengalahkan pra-perhitungan. Dalam uraian di atas, garam mengembalikan penyerang ke langkah 1: salting mencegah penyerang berbagi biaya O ( N ) antara beberapa kata sandi yang diserang. Tabel pra-komputasi, tabel pelangi fortiori , tidak lagi layak.

Anda ingin salting karena ketika data hash terdiri dalam kata sandi , yaitu sesuatu yang cocok di dalam otak manusia acak, maka N bisa sangat rendah: manusia benar-benar buruk dalam memilih dan mengingat kata sandi. Inilah yang dimaksud dengan "serangan kamus": yang menggunakan ruang potensial kata sandi yang berkurang ("kamus") dengan asumsi bahwa banyak kata sandi pengguna akan berada dalam ruang yang dipilih secara khusus.

Oleh karena itu pengasinan setidaknya akan mencegah penyerang dari menggunakan tabel pra-dihitung, khususnya tabel pelangi pra-dihitung. Ini mengasumsikan bahwa penyerang akan dapat memecahkan satu atau dua kata sandi; kami tidak ingin dia memecahkan 1000 kata sandi lainnya dengan sedikit overhead tambahan.

Juga, pengasinan baik untuk hubungan masyarakat.

Tentang biaya SHA-1:

Biaya dasar SHA-1 adalah tentang hashing blok 64-byte. Begitulah cara kerja SHA-1: data diisi, lalu dipecah menjadi blok 64-byte. Biaya pemrosesan satu blok adalah sekitar 500 siklus clock pada sistem Intel Core2, dan itu untuk satu inti. MD5 dan MD4 lebih cepat, masing-masing menghitung sekitar 400 dan 250 siklus. Jangan lupa bahwa sebagian besar CPU modern memiliki beberapa core, jadi gandakan dengan sesuai.

Beberapa skema pengasinan meresepkan garam besar; misalnya apa yang memasuki fungsi hash sebenarnya adalah 40000 salinan berturut-turut dari garam 128-bit, diikuti oleh kata sandi itu sendiri. Ini membuat hashing kata sandi lebih mahal (dengan faktor 10.000 dengan contoh saya), baik untuk pengguna yang sah maupun untuk penyerang. Apakah ini ide yang baik tergantung pada pengaturan. Untuk login pada sistem desktop, ini bagus: pengguna bahkan tidak akan menyadari bahwa butuh 10 ms untuk mem-hash kata sandinya, bukannya 1μs; tetapi biaya untuk penyerang telah meningkat dengan faktor yang sangat mencolok 10000. Pada server bersama dengan ribuan klien per detik, biaya agregat dapat menjadi penghalang. Secara konseptual, meningkatkan standar dengan faktor yang sama untuk pengguna yang sah dan penyerang pada akhirnya bukanlah keamanan yang baik; tetapi itu bisa menjadi ide yang bermanfaat dalam beberapa situasi tertentu.

Tentang serangan online:

Semua hal di atas adalah tentang mengalahkan serangan offline . Serangan offline adalah serangan di mana penyerang memiliki semua data yang dia butuhkan untuk "menguji" kata sandi; misalnya penyerang bisa mendapatkan salinan dari database yang menyimpan kata sandi hash. Dalam serangan offline, penyerang hanya dibatasi oleh sumber daya komputasinya. Sebaliknya, serangan online adalah serangan di mana setiap tebakan oleh penyerang harus melalui verifikasi yang jujur ​​(misalnya penyerang hanya mencoba masuk pada sistem yang diserang). Serangan online digagalkan dengan memberlakukan batasan pada berapa banyak kata sandi yang dapat dicoba per detik. Contoh ekstrem adalah kartu pintar yang dimatikan setelah tiga PIN salah.

Biasanya, untuk keamanan kata sandi, membayar jauh lebih banyak untuk mengatur sistem untuk tidak membiarkan penyerang membuat serangan offline. Itulah yang dilakukan sistem Unix: kata sandi hash, yang dulunya berada di /etc/passwordfile yang dapat dibaca dunia , sekarang berada dalam /etc/shadowfile yang dilindungi terhadap akses baca, kecuali oleh beberapa aplikasi istimewa. Asumsinya di sini adalah bahwa jika penyerang dapat membaca /etc/shadow, maka ia mungkin memiliki kendali yang cukup atas sistem sehingga ia tidak benar-benar membutuhkan kata sandi lagi ...


5
Jawaban yang sangat bagus. Satu-satunya hal yang saya tidak setuju adalah "Secara konseptual, meningkatkan standar dengan faktor yang sama untuk pengguna yang sah dan penyerang tidak pada akhirnya keamanan yang baik" - penyerang harus melakukan banyak operasi yang harus dilakukan oleh pengguna. Menambahkan satu siklus jam untuk login pengguna menambahkan jutaan untuk penyerang.
Nick Johnson

1
@ Thomas Ini tetap akurat dan mungkin akan tetap akurat untuk masa mendatang yang tidak terbatas. Peretas dapat menebak kata sandi aktual melalui segala jenis hashing karena buruknya kualitas kata sandi umum. Kira "123456" dan Anda akan selalu mendapatkan beberapa hit. Ini akan tetap benar, apa pun penyimpanan kata sandi yang Anda gunakan.
tylerl

1
Hanya sudut pandang saya, tetapi mengapa Anda tetap menggunakan SHA1, ketika enkripsi kata sandi yang lebih kuat sudah tersedia secara luas? Setahun yang lalu, MD5 dianggap "aman", dan sekarang tidak - hal yang sama dapat terjadi pada SHA1 sekarang, untuk semua yang kita tahu. Secara pribadi, saya akan bertaruh pada Blowfish mulai saat ini - tampaknya memiliki perwakilan yang lebih baik dan lebih sedikit pakar yang peduli dalam komunitas crypto, tersedia hampir di mana saja, jadi tidak ada alasan untuk bertaruh dengan SHA1.
mindplay.dk

1
Saya terkejut pada intinya untuk menyimpang dari jawaban dari @ThomasPornin mengatakan MD5 aman untuk penyimpanan kata sandi. Jika MD5 baik-baik saja, mengapa semua mengatakan tidak menggunakannya, gunakan bcrypt ?? Apakah mereka terlalu berhati-hati? Saya telah membaca dan memahami segalanya dan berada di bawah kesan MD5 sangat buruk karena sangat rentan terhadap kekerasan. Komentar baru-baru ini setahun yang lalu tidak bertentangan dengan jawabannya ...
temporary_user_name

1
@Aerovistae: Anda mungkin ingin melihat jawaban itu di situs security.SE; ini berisi lebih banyak analisis dan detail terbaru tentang hashing kata sandi.
Thomas Pornin

30

Jawaban sebelumnya tidak menyebutkan GPU, yang dapat memparalelkan hasrat SHA-1 sampai-sampai seluruh basis data sekarang dapat diubah paksa dalam hitungan menit atau jam, bukan dalam hitungan hari atau minggu, bahkan jika kata sandi telah diasinkan.

Algoritma hash password modern seperti bcrypt atau scrypt dirancang khusus agar sulit dijalankan pada GPU karena fakta bahwa mereka adalah blok cipher dengan persyaratan memori yang jauh lebih tinggi (dan akses memori dalam GPU tidak dapat diparalelkan pada tingkat yang sama). Mereka juga memiliki "fungsi kerja" yang memungkinkan mereka dibuat lebih lambat saat teknologi meningkat.

Singkatnya, Anda hanya harus menggunakan alat terbaik untuk pekerjaan itu. Dan SHA-1 sangat jauh dari canggih.

Untuk bacaan lebih lanjut:


2
"Algoritma hash password modern seperti bcrypt atau PBKDF2 dirancang khusus agar sulit dijalankan pada GPU" - apakah maksud Anda "bcrypt atau scrypt"? PBKDF2 hanyalah iterasi hashing, tidak ada di dalamnya yang akan bermasalah untuk GPU.
Tgr

4
Tolong beri tahu saya GPU apa yang Anda gunakan, saya akan membeli yang sama. Jika Anda dapat melakukan 2 ^ 160 perhitungan SHA-1 dalam "menit" (itu akan kurang dari "jam", jadi paling banyak 59 menit), Anda harus dapat melakukan lebih dari 10 ^ 44 per detik. Karena PCIe mentransfer batas sekitar 128GT / s, GPU Anda juga harus memiliki memori on-board yang luar biasa. Saya menginginkannya.
Damon

3
@Damon: Anda tampaknya berasumsi bahwa pengguna memiliki kata sandi "sepele" (<8 bit entropi) atau kata sandi "tidak dapat dipecahkan" (> entropi 60 bit). Anda benar-benar mengabaikan semua orang di antara entri kata sandi yang berada dalam kisaran 10-60 bit. Mereka adalah pengguna di mana bcrypt, rainbow tables, dan GPU, dan mereka membentuk sekitar 80% dari basis pengguna biasa.
jammycakes

1
(oops ... Saya seharusnya mengatakan, "Mereka adalah pengguna di mana bcrypt, rainbow tables, dan GPU membuat perbedaan terbesar")
jammycakes

3
Untuk beberapa statistik dan analisis, lihat troyhunt.com/2011/06/brief-sony-password-analysis.html - sementara 36% pengguna memilih kata sandi yang muncul dalam kamus kata sandi, hanya 2-3% memilih yang paling umum.
jammycakes

7

Deskripsi Anda terdengar akurat untuk kondisi terkini.

Anda seharusnya tidak menggunakan iterasi tunggal dari fungsi hash apa pun, meskipun: Paling tidak, Anda harus mengulangi berkali-kali (1000 iterasi hash meningkatkan kerja penyerang 1000 kali lipat. Ini meningkatkan pekerjaan Anda dengan jumlah yang sama, tetapi Anda melakukan hashing kata sandi jauh lebih sedikit daripada mereka).

Namun, idealnya, Anda harus menggunakan primitif penyimpanan kata sandi yang ada, seperti yang dijelaskan sini .


Iterasi ribuan kali bukanlah ide yang bagus seperti yang mungkin Anda pikirkan. Ini meningkatkan risiko tabrakan hash. yorickpeterse.com/articles/use-bcrypt-fool
jammycakes

1
Artikel itu terlihat sangat membingungkan. Fungsi hashing yang aman tidak kehilangan entropi yang cukup besar melalui hashing iteratif, dan haser iteratif adalah komponen inti dari skema peregangan utama seperti PBKDF2 dan scrypt. Bahkan bcrypt, yang direkomendasikan oleh penulis, menggunakan konstruksi serupa. 'Serangan'-nya bergantung pada menemukan preimage hash - dalam hal ini, sebagian besar konstruksi menggunakan hash itu benar-benar rusak. Akhirnya, saya tidak menyarankan orang menggunakan hashing iteratif secara langsung - seperti yang saya katakan dalam pertanyaan saya, Anda harus menggunakan primitif yang ada yang dirancang untuk tujuan tersebut.
Nick Johnson

7

SHA1 adalah pesan intisari , tidak pernah dimaksudkan sebagai fungsi hashing kata sandi (atau kunci-derivasi). (Meskipun bisa digunakan blok bangunan untuk KDF, seperti di PBKDF2 dengan HMAC-SHA1.)

Fungsi kata sandi harus dipertahankan terhadap serangan kamus dan tabel pelangi. Beberapa algoritma telah dirancang untuk mencapai tujuan ini.

Saat ini, pilihan terbaik mungkin Argon2 . Rangkaian fungsi hashing kata sandi ini memenangkan Kompetisi Hashing Kata Sandi pada tahun 2015.

Jika Argon2 tidak tersedia, satu-satunya fungsi password-hashing atau key-derivation terstandarisasi lainnya adalah PBKDF2 , yang merupakan standar NIST lawas. Pilihan lain, jika menggunakan standar tidak diperlukan, termasuk bcrypt dan scrypt .

Wikipedia memiliki halaman untuk fungsi-fungsi ini:


4

Kerentanan serius telah ditemukan di SHA-1 yang membuat pencarian lebih cepat daripada kekerasan. Ini sebagian besar masih keras, tetapi itu tidak diharapkan menjadi kasus terlalu lama; programmer paranoid menyukai sesuatu dari keluarga SHA-2.

Dari artikel ini mengenai hasil asli 2005:

"Sudah waktunya untuk berjalan, tetapi tidak berlari, ke pintu keluar api. Kamu tidak melihat asap, tetapi alarm kebakaran sudah padam."

Bukannya cryptanalysis saat ini membuat SHA-1 tidak aman, tetapi komunitas crypto khawatir bahwa berita buruk mungkin akan segera muncul. Ketakutan ini juga berlaku untuk SHA-2, yang menunjukkan kelemahan yang sama dengan SHA-1, meskipun lebih banyak ruang pencarian yang lebih besar, karenanya pencarian berkelanjutan untuk SHA-3 .

Singkatnya, SHA-1 aman saat ini, dan mungkin untuk beberapa waktu akan datang, tetapi komunitas crypto tidak nyaman dengan prognosisnya.


Bisakah Anda memberikan tautan? Seperti yang saya katakan, serangan preimage terbaik yang bisa saya temukan membuat pencarian kekalahan 8 kali lebih cepat, dan bahkan untuk itu untuk bekerja Anda perlu menghilangkan setengah langkah SHA-1. (Juga, saya pikir itu adalah serangan preimage kedua, yang tidak berguna terhadap hash kata sandi.)
Tgr

Saya juga skeptis terhadap sesuatu yang berasal dari NSA, mengingat berita terbaru :)
Alex W

4

Pada Februari 2017, SHA-1 seharusnya tidak lagi dianggap aman. Google telah melaporkan keberhasilan dengan serangan tabrakan terhadap SHA-1 yang lengkap dan tidak berkurang ( tautan ke laporan ). Untuk pengumuman Google, klik di sini .

Sunting: Seperti yang ditunjukkan oleh orang lain, kata sandi tidak rentan terhadap serangan tabrakan hash. Namun sebagai pedoman umum saya tidak akan memilih SHA-1 untuk aplikasi yang berhubungan dengan keamanan. Ada alternatif yang lebih baik di luar sana.


OK, menemukan tabrakan SHA-1 memakan waktu sekitar 6.500 tahun CPU dan 100 tahun GPU , itu bukan serangan produksi. Memecahkan kata sandi bukanlah kekuatan yang kasar terhadap semua input yang mungkin, tetapi terhadap daftar 10.000.000 kata sandi yang sering. Ini kertasnya .
zaf

1
Kekurangannya hanya menggunakan fungsi hash apa saja untuk melindungi kata sandi. Hanya menggunakan fungsi hash tidak cukup dan hanya menambahkan garam tidak banyak meningkatkan keamanan, hash kriptografi sangat cepat. Alih-alih iterate di atas HMAC dengan garam acak selama sekitar 100 ms durasi dan menyimpan garam dengan hash. Gunakan fungsi seperti PBKDF2(alias Rfc2898DeriveBytes), password_hash/ password_verify, Bcryptdan fungsi serupa. Intinya adalah membuat penyerang menghabiskan banyak waktu mencari kata sandi dengan kekerasan. Melindungi pengguna Anda penting, silakan gunakan metode kata sandi yang aman.
zaf

Tabrakan bukan preimage dan kata sandi bukan tanda tangan. Serangan tabrakan tidak bekerja terhadap kata sandi karena membutuhkan pengetahuan tentang teks asli.
Tgr

Tgr: setuju, terima kasih. Zaph: Ya, pengasinan untuk melindungi dari serangan pelangi dan menggunakan hash kripto yang lambat adalah beberapa praktik yang disarankan yang saya tidak secara khusus membahas dalam jawaban ini.
Aaron

3

Jika Anda menyimpan kata sandi asin, SHA-1 baik untuk tujuan praktis. SHA-2 dianggap lebih aman, tetapi SHA-1 bukan masalah kecuali Anda punya alasan untuk benar-benar paranoid.

Berikut adalah apa yang NIST mengatakan :

Hasil yang disajikan sejauh ini di SHA-1 tidak membuat keamanannya dipertanyakan. Namun, karena kemajuan teknologi, NIST berencana untuk menghapus SHA-1 demi fungsi hash yang lebih besar dan lebih kuat (SHA-224, SHA-256, SHA-384 dan SHA-512) pada tahun 2010.


Itu adalah komentar NIST dari 2004. Rekomendasi rancangan 2010 mereka mengatakan SHA-1 disetujui untuk semua aplikasi generasi tanda tangan non-digital di luar 2010.
Tgr
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.