Saya telah membaca bahwa ketika membuat kata sandi, banyak programmer merekomendasikan menggunakan algoritma BCrypt.
Saya pemrograman dalam C # dan bertanya-tanya apakah ada yang tahu implementasi yang baik untuk BCrypt? Saya menemukan halaman ini , tetapi saya tidak benar-benar tahu apakah itu palsu atau tidak.
Apa yang harus saya ketahui ketika memilih skema hashing kata sandi? Apakah BCrypt implementasi yang 'baik'?
Jawaban:
Pertama, beberapa istilah yang penting:
Hashing - Tindakan mengambil string dan menghasilkan urutan karakter yang tidak dapat dikembalikan ke string asli.
Symmetric Encryption - (Biasanya hanya disebut sebagai 'enkripsi') - Tindakan mengambil string dan menghasilkan urutan karakter yang dapat didekripsi ke string asli melalui penggunaan kunci enkripsi yang sama yang dienkripsi itu.
Rainbow Table - tabel pencarian yang berisi semua variasi karakter yang hash dalam algoritma hashing tertentu.
Garam - string acak yang dikenal ditambahkan ke string asli sebelum hash.
Untuk .NET Framework, Bcrypt belum memiliki implementasi referensi terverifikasi . Ini penting karena tidak ada cara untuk mengetahui apakah ada kelemahan serius dalam implementasi yang ada. Anda bisa mendapatkan implementasi BCrypt untuk .NET di sini . Saya tidak cukup tahu tentang kriptografi untuk mengatakan apakah itu implementasi yang baik atau buruk. Kriptografi adalah bidang yang sangat dalam. Jangan mencoba membangun algoritma enkripsi Anda sendiri . Serius.
Jika Anda ingin menerapkan keamanan kata sandi Anda sendiri, maka Anda perlu melakukan beberapa hal:
Sayangnya, bahkan jika Anda melakukan semua ini, seorang hacker yang gigih masih berpotensi menemukan kata sandinya, itu hanya akan memakan waktu yang sangat lama. Itu musuh utama Anda: Waktu .
The algoritma bcrypt bekerja karena butuh lima lipat lebih lama untuk hash password dari MD5 ; (dan masih lebih lama dari AES atau SHA-512). Ini memaksa peretas untuk menghabiskan lebih banyak waktu untuk membuat tabel pelangi untuk mencari kata sandi Anda, membuatnya jauh lebih kecil kemungkinannya bahwa kata sandi Anda akan terancam diretas.
Jika Anda salting dan hashing kata sandi Anda, dan setiap garam berbeda, maka peretas potensial harus membuat tabel pelangi untuk setiap variasi garam , hanya untuk memiliki tabel pelangi untuk satu kata sandi + hash asin. Itu berarti jika Anda memiliki 1 juta pengguna, seorang hacker harus menghasilkan 1 juta tabel pelangi. Jika Anda menggunakan garam yang sama untuk setiap pengguna, maka peretas hanya perlu membuat 1 tabel pelangi untuk berhasil meretas sistem Anda.
Jika Anda tidak memberi salin kata sandi, maka yang harus dilakukan penyerang adalah menarik tabel Rainbow yang ada untuk setiap implementasi di luar sana (AES, SHA-512, MD5) dan hanya melihat apakah ada yang cocok dengan hash. Ini sudah dilakukan , penyerang tidak perlu menghitung tabel Rainbow ini sendiri .
Bahkan dengan semua ini, Anda harus menggunakan praktik keamanan yang baik . Jika mereka dapat berhasil menggunakan vektor serangan lain (XSS, SQL Injection, CSRF, et. Al. ) Di situs Anda, keamanan kata sandi yang baik tidak masalah. Itu terdengar seperti pernyataan yang kontroversial, tetapi pikirkan: Jika saya bisa mendapatkan semua informasi pengguna Anda melalui serangan injeksi SQL, atau saya bisa meminta pengguna Anda untuk memberikan saya cookie mereka melalui XSS, maka tidak masalah seberapa baik kata sandi Anda keamanan .
Sumber lain:
Catatan: Harap rekomendasikan sumber daya lain yang baik. Saya pasti telah membaca selusin artikel oleh puluhan penulis, tetapi hanya sedikit yang menulis sejelas itu tentang subjek seperti yang dilakukan Jeff. Harap edit dalam artikel saat Anda menemukannya.
Anda tidak boleh menggunakan BCrypt di .NET. Anda harus menggunakan PBKDF2 sebagaimana halnya dengan implementasi .NET framework bawaan. Ini adalah satu-satunya implementasi yang diverifikasi secara cryptographically tersedia di. NET bersama dengan menjadi algoritma yang direkomendasikan oleh NIST .
StackId sebelumnya menggunakan BCrypt dan pindah ke PBKDF2 karena alasan ini:
Bagi mereka yang penasaran, kami membuat kata sandi dengan PBKDF2. Kode yang relevan ada di sini ( http://code.google.com/p/stackid/source/browse/OpenIdProvider/Current.cs#1135 ), melalui beberapa lapisan tipuan. Dalam iterasi sebelumnya, kami menggunakan BCrypt; tetapi pindah ke PBKDF2 karena dibangun ke dalam kerangka .NET, sedangkan BCrypt akan meminta kami untuk memverifikasi suatu implementasi (bukan usaha kecil).
(Tautan yang diperbarui di GitHub)
Sunting: Arti diverifikasi dalam istilah kriptografi tampaknya tidak mudah dipahami, implementasi yang terverifikasi berarti telah terbukti secara kriptografi untuk diimplementasikan tanpa kesalahan. Biaya ini dapat dengan mudah mencapai $ 20.000 atau lebih tinggi. Saya ingat ini ketika saya sedang melakukan penelitian tentang OpenSSL dan membaca di mana mereka menyatakan mereka belum menyelesaikan seluruh proses verifikasi tetapi jika Anda perlu diverifikasi sepenuhnya bahwa mereka dapat mengarahkan Anda ke jalan yang benar untuk itu dan menyebutkan biaya yang terkait. Persyaratan pemerintah tertentu termasuk mandat untuk algoritma enkripsi yang diverifikasi.
Implementasi bcrypt di .NET belum diverifikasi. Menggunakan implementasi enkripsi yang tidak diverifikasi, Anda tidak dapat benar-benar yakin bahwa tidak ada kesalahan berbahaya yang disengaja di dalamnya seperti memungkinkan pintu belakang ke apa yang dienkripsi atau kesalahan implementasi yang tidak disengaja yang menghasilkan data yang tidak aman secara kriptografis.
Sunting 2014: Bagi siapa pun yang mempertanyakan pentingnya menggunakan algoritma cryptopgraphical terverifikasi, lihatlah kehancuran yang disebabkan oleh peretasan yang dilakukan di OpenSSL. Itu adalah biaya menggunakan implementasi yang tidak diverifikasi. Aman .... sampai Anda mengetahui bahwa ada orang yang bisa membaca seluruh isi memori server Anda.
Penulis perubahan yang memperkenalkan Heartbleed, Robin Seggelmann, menyatakan bahwa ia "melewatkan validasi variabel yang berisi panjang" dan menyangkal niat untuk mengajukan implementasi yang cacat. Setelah pengungkapan Heartbleed, Seggelmann menyarankan untuk fokus pada aspek kedua, yang menyatakan bahwa OpenSSL tidak ditinjau oleh cukup banyak orang.
Ini adalah definisi dari implementasi yang tidak diverifikasi. Bahkan cacat terkecil dapat mengakibatkan melumpuhkan seluruh keamanan.
Sunting 2015: Bahasa berbasis rekomendasi yang dihapus dan diganti dengan absolut. Tertulis asli Kevin Montrose komentar untuk anak cucu.