Apa yang sebenarnya dilindungi oleh hashing kata sandi

Versi singkat

Hashing kata sandi melindungi pengguna ketika basis data kata sandi Anda dicuri.

Itulah tugas utamanya. Bukan satu-satunya detail, bukan seluruh model keamanan, tetapi alasan utama kita melakukan hash pada kata sandi alih-alih menyimpannya secara langsung.

Kata sandi yang di-hash dengan benar sulit dibalik. Jika penyerang mendapatkan salinan tabel pengguna Anda, mereka seharusnya tidak langsung mengetahui bahwa kata sandi Alice adalah Spring2026!. Sebaliknya, mereka mendapatkan hash tersimpan yang membutuhkan waktu, uang, dan perangkat keras untuk diuji terhadap tebakan.

Perbedaan itu penting. Hashing kata sandi tidak dimaksudkan untuk membuat login aman dengan sendirinya. Ia tidak menghentikan phishing. Ia tidak menghentikan seseorang mencoba kata sandi yang bocor pada formulir login Anda. Ia tidak melindungi cookie sesi setelah login. Ia membeli waktu dan mengurangi kerugian setelah kegagalan yang sangat spesifik: penyimpanan verifier kata sandi Anda terekspos.

Jika Anda memahami batasan itu, Anda akan membuat keputusan yang lebih baik tentang algoritma, work factor, reset, logging, dan respons insiden.

Apa itu hash kata sandi

Hash kata sandi adalah output dari fungsi satu arah yang diterapkan pada kata sandi, biasanya dengan salt unik dan algoritma hashing kata sandi yang sengaja dibuat lambat.

Ketika pengguna membuat akun, sistem kira-kira harus melakukan ini:

1. Menerima kata sandi melalui HTTPS.
2. Membuat salt acak dan unik.
3. Menjalankan kata sandi dan salt melalui fungsi hashing kata sandi seperti Argon2id, bcrypt, scrypt, atau PBKDF2.
4. Menyimpan nama algoritma, parameter, salt, dan hash yang dihasilkan.
5. Membuang kata sandi asli.

Ketika pengguna login nanti, sistem mengulangi proses hashing yang sama dengan kata sandi yang dikirimkan dan parameter tersimpan. Jika hash yang dihasilkan cocok dengan hash tersimpan, login berhasil.

Bagian pentingnya: aplikasi tidak perlu mengetahui kata sandi asli. Aplikasi hanya perlu memverifikasi bahwa kata sandi yang dikirimkan menghasilkan output yang diharapkan.

Inilah mengapa menyimpan kata sandi dengan enkripsi yang dapat dibalik biasanya merupakan model yang salah. Jika aplikasi Anda dapat mendekripsi setiap kata sandi, maka siapa pun yang mencuri kunci dekripsi dapat melakukan hal yang sama. Kata sandi biasanya seharusnya tidak dapat diverifikasi secara terbalik, bukan sekadar disembunyikan.

Apa yang dilindungi oleh hashing

1. Pengungkapan kata sandi langsung setelah pelanggaran basis data

Jika penyerang mencuri basis data yang berisi kata sandi plaintext, kerusakannya terjadi seketika. Setiap kata sandi terekspos. Pengguna berisiko bukan hanya di situs Anda, tetapi di mana pun mereka menggunakan ulang kata sandi itu.

Jika basis data berisi kata sandi yang di-hash dengan baik, penyerang harus bekerja lebih keras. Mereka harus menebak kandidat kata sandi, melakukan hash pada setiap tebakan dengan salt dan parameter yang benar, lalu membandingkan hasilnya.

Untuk kata sandi yang lemah, ini mungkin masih cepat. Untuk kata sandi unik yang kuat, ini bisa menjadi tidak praktis.

Hashing mengubah pengungkapan yang katastrofik menjadi perlombaan: dapatkah pengguna mereset kata sandi dan dapatkah Anda membatasi insiden sebelum penyerang memecahkan banyak di antaranya?

Itu tidak sempurna. Ini tetap merupakan pelanggaran. Tetapi ini adalah mode kegagalan yang jauh lebih baik.

2. Serangan massal terhadap seluruh basis pengguna Anda

Salt adalah bagian penting dari penyimpanan kata sandi karena mencegah penyerang menyerang banyak pengguna sekaligus secara efisien dengan tabel prakomputasi.

Salt bukan rahasia. Salt disimpan bersama hash. Tugasnya adalah memberikan keunikan.

Jika dua pengguna memilih kata sandi yang sama, salt unik memastikan hash tersimpan mereka berbeda. Itu mencegah penyerang melihat sekilas bahwa banyak pengguna berbagi kata sandi yang sama. Ini juga mencegah serangan rainbow table klasik, di mana penyerang menggunakan daftar prakomputasi besar berisi pemetaan kata sandi-ke-hash.

Tanpa salt, satu hash yang berhasil dipecahkan dapat mengungkap setiap pengguna dengan kata sandi yang sama. Dengan salt, setiap tebakan kata sandi harus diuji secara terpisah untuk setiap pengguna.

3. Penebakan offline yang cepat

Setelah penyerang memiliki basis data kata sandi, mereka dapat menebak secara offline. Itu berarti pembatasan laju login, CAPTCHA, pemblokiran IP, dan pemantauan Anda tidak lagi berpengaruh. Penyerang dapat menguji tebakan pada perangkat keras mereka sendiri.

Di sinilah pilihan algoritma menjadi penting.

Hash tujuan umum seperti SHA-256 dan SHA-512 dirancang agar cepat. Itu baik untuk integritas berkas dan tanda tangan digital. Itu buruk untuk penyimpanan kata sandi.

Algoritma hashing kata sandi dirancang agar lambat, dapat disetel, dan kadang-kadang memory-hard. Argon2id, bcrypt, scrypt, dan PBKDF2 semuanya memungkinkan Anda menyesuaikan parameter biaya sehingga setiap tebakan membutuhkan waktu yang berarti.

Argon2id banyak direkomendasikan untuk sistem baru karena dapat dikonfigurasi untuk membutuhkan waktu CPU sekaligus memori, yang membuat cracking GPU berskala besar menjadi lebih mahal. bcrypt tetap umum dan dapat diterima jika dikonfigurasi dengan baik, meskipun memiliki keterbatasan seperti penanganan panjang kata sandi. PBKDF2 masih digunakan di beberapa lingkungan yang didorong oleh kepatuhan, terutama ketika komponen tervalidasi FIPS diperlukan.

Prinsipnya sederhana: buat login sah tetap cukup cepat, sambil membuat miliaran tebakan menjadi mahal.

Apa yang tidak dilindungi oleh hashing

1. Phishing

Jika pengguna mengetik kata sandinya ke halaman login palsu, hashing di server Anda tidak membantu. Penyerang menerima kata sandi sebelum sistem Anda sempat melihatnya.

Pertahanan di sini berbeda: autentikasi multifaktor, passkeys, edukasi pengguna, kebersihan domain, autentikasi tahan phishing, dan alur reset kata sandi yang hati-hati.

Hashing kata sandi adalah penyangga terakhir untuk rahasia yang disimpan. Ini bukan pertahanan terhadap pengguna yang ditipu untuk menyerahkan rahasia tersebut.

2. Credential stuffing

Credential stuffing terjadi ketika penyerang mengambil pasangan nama pengguna dan kata sandi yang bocor dari satu layanan dan mencobanya di layanan lain.

Hash kata sandi Anda mungkin sangat baik, dan credential stuffing tetap dapat berhasil jika pengguna menggunakan ulang kata sandi.

Ini adalah serangan online terhadap formulir login Anda, bukan serangan offline terhadap basis data Anda. Anda membutuhkan pembatasan laju, deteksi anomali, pemeriksaan kata sandi yang bocor, MFA, dan kebijakan lockout yang masuk akal yang tidak menciptakan peluang denial-of-service yang mudah.

Pemikiran praktis yang sama berlaku untuk formulir apa pun yang terekspos. Jika Anda sedang meninjau permukaan autentikasi Anda, ada baiknya membaca tentang mengapa formulir kontak Anda adalah liabilitas spam terbesar Anda; mekanismenya berbeda, tetapi pelajarannya serupa: input publik membutuhkan kontrol penyalahgunaan, bukan hanya kode backend yang bersih.

3. Kata sandi yang tertangkap di log atau analytics

Hashing hanya membantu jika kata sandi plaintext dibuang dengan cepat dan tidak pernah disalin ke tempat lain.

Kegagalan umum meliputi:

• Mencatat seluruh body request pada percobaan login yang gagal.
• Mengirim kata sandi ke alat pemantauan error.
• Menangkap kolom kata sandi dalam produk session replay.
• Menyertakan kredensial dalam URL selama alur reset atau migrasi yang dirancang buruk.
• Menyimpan kata sandi plaintext sementara selama impor.

Kesalahan ini sepenuhnya melewati hashing kata sandi. Jika plaintext masuk ke log, backup, data warehouse, atau alat pihak ketiga, fungsi hash Anda tidak relevan.

Perlakukan kolom kata sandi sebagai data beracun. Redaksikan sebelum logging. Kecualikan dari analytics. Jauhkan dari URL. Batasi siapa yang dapat mengakses trace produksi.

4. Keamanan sesi yang buruk

Setelah login, browser pengguna biasanya menerima cookie sesi atau token. Jika token itu dicuri, penyerang mungkin tidak memerlukan kata sandi sama sekali.

Hashing kata sandi tidak melindungi dari cross-site scripting, cookie yang tidak aman, session fixation, pembuatan token yang lemah, atau masa hidup sesi yang terlalu panjang.

Cookie sesi layak mendapatkan tinjauan tersendiri: HttpOnly, Secure, SameSite yang sesuai, sesi berisiko tinggi yang berumur pendek, dan invalidasi sisi server saat kata sandi berubah. Lanskap privasi dan browser yang lebih luas juga terus bergeser, sebagaimana dibahas dalam apa yang berubah untuk cookies pada 2026.

5. Reset kata sandi dan pemulihan akun yang lemah

Banyak pengambilalihan akun tidak dimulai dari kata sandi. Mereka dimulai dari alur reset.

Jika token reset dapat diprediksi, berumur panjang, bocor melalui header referrer, atau dikirim ke akun email yang terkompromi, hashing kata sandi tidak akan menyelamatkan Anda.

Gunakan token reset berentropi tinggi, jendela kedaluwarsa singkat, penggunaan satu kali, dan notifikasi pengguna yang jelas. Karena email sering menjadi kanal pemulihan, autentikasi domain dasar juga penting. Jika tim Anda memperlakukan record DNS sebagai ritual misterius, mulailah dengan tur ramah developer tentang MX, SPF, DKIM dan DMARC.

Pilihan algoritma: apa yang digunakan sekarang

Untuk aplikasi baru, gunakan Argon2id jika platform Anda mendukungnya dengan baik. Ini adalah pemenang Password Hashing Competition dan dirancang untuk penyimpanan kata sandi, termasuk ketahanan terhadap cracking yang berat menggunakan GPU.

Hierarki modern yang masuk akal terlihat seperti ini:

1. Argon2id untuk sistem baru jika tersedia.
2. bcrypt ketika Argon2id tidak praktis dan dukungan bcrypt sudah matang.
3. scrypt ketika konfigurasi memory-hard didukung dengan baik.
4. PBKDF2 jika diwajibkan oleh batasan platform atau kepatuhan.

Hindari SHA-256, SHA-512, MD5 polos, atau kombinasi buatan sendiri seperti sha256(password + salt). Hash cepat bukan fungsi penyimpanan kata sandi. Konstruksi kustom yang terlihat cerdik cenderung lebih buruk daripada standar yang membosankan.

Hindari juga menciptakan kebijakan kata sandi sendiri berdasarkan trivia algoritma. Pengguna tidak mendapat manfaat dari checklist komposisi kata sandi 12 aturan jika itu mendorong mereka ke pola yang mudah ditebak. Kata sandi unik yang lebih panjang, password manager, penyaringan kata sandi yang pernah bocor, dan MFA biasanya lebih penting.

Cost factor bukan sesuatu yang diatur sekali lalu dilupakan

Hashing kata sandi memiliki parameter. Argon2id memiliki memori, iterasi, dan paralelisme. bcrypt memiliki cost factor. PBKDF2 memiliki jumlah iterasi.

Nilai-nilai ini harus dipilih berdasarkan lingkungan produksi Anda. Terlalu rendah, dan penyerang dapat menebak dengan murah. Terlalu tinggi, dan sistem login Anda menjadi lambat atau rentan terhadap denial-of-service.

Target praktis sering kali berada dalam rentang puluhan hingga beberapa ratus milidetik per verifikasi kata sandi di server aktual Anda, tergantung pada trafik dan risiko. Sistem dengan keamanan tinggi mungkin memilih lebih. Sistem berskala konsumen mungkin membutuhkan perencanaan kapasitas yang hati-hati.

Jangan menyalin cost factor dari posting blog lima tahun lalu. Perangkat keras berubah. Library berubah. Trafik Anda berubah.

Tinjau parameter secara berkala dan rencanakan rehashing. Pola umum adalah menyimpan algoritma dan parameter bersama setiap hash. Saat login berhasil, jika parameter tersimpan sudah usang, lakukan rehash pada kata sandi yang dikirimkan dengan konfigurasi yang lebih baru dan perbarui record.

Pepper: berguna, tetapi bukan pengganti

Pepper adalah nilai rahasia yang ditambahkan ke proses hashing kata sandi dan disimpan terpisah dari basis data, sering kali di secrets manager atau hardware security module.

Tidak seperti salt, pepper harus tetap rahasia.

Pepper dapat mengurangi kerusakan jika basis data bocor tetapi rahasia aplikasi tidak. Pepper paling berguna di lingkungan matang dengan manajemen kunci yang baik. Pepper kurang berguna jika penyerang yang sama dapat mencuri basis data sekaligus konfigurasi aplikasi.

Jika Anda menggunakan pepper, rencanakan rotasi dengan hati-hati. Merotasinya mungkin mengharuskan pengguna login lagi atau mereset kata sandi, tergantung desainnya. Pepper adalah lapisan tambahan, bukan alasan untuk melemahkan pengaturan hash yang mendasarinya.

Checklist operasional

Jika Anda bertanggung jawab atas sistem nyata, checklist praktisnya singkat:

• Simpan kata sandi hanya dengan algoritma hashing kata sandi standar.
• Gunakan salt acak unik untuk setiap kata sandi.
• Utamakan Argon2id untuk build baru.
• Setel parameter biaya pada perangkat keras yang menyerupai produksi.
• Simpan algoritma dan parameter bersama setiap hash.
• Lakukan rehash saat login ketika parameter menjadi usang.
• Jangan pernah mencatat kata sandi atau mengirimnya ke alat analytics.
• Gunakan TLS di mana pun kredensial dikirimkan.
• Tambahkan MFA atau passkeys jika risiko membenarkannya.
• Lindungi alur reset sama seriusnya dengan alur login.
• Miliki rencana insiden untuk reset paksa dan notifikasi pengguna.

Hashing kata sandi tidak glamor. Ini adalah plumbing. Tetapi ini jenis plumbing yang menentukan apakah sebuah pelanggaran menjadi insiden menyakitkan atau bencana bagi seluruh pengguna.

<!-- tool-cta:start -->

💡 Coba ini: Lihat bagaimana input yang sama dipetakan ke algoritma berbeda dengan Hash Generator, yang membuat perbedaan antara hash cepat dan hash tingkat kata sandi menjadi nyata.

<!-- tool-cta:end -->

Model mental yang jujur

Cara terbaik untuk memikirkan hashing kata sandi adalah ini:

Hashing tidak melindungi kata sandi saat pengguna mengetiknya. Ia tidak melindungi akun setelah pengguna login. Ia tidak melindungi pengguna yang menggunakan ulang kata sandi di seluruh web.

Ia melindungi verifier yang disimpan.

Itu terdengar sempit, tetapi sangat penting. Basis data bocor. Backup bocor. Sistem staging disalin. Vendor mendapatkan akses yang seharusnya tidak mereka miliki. Ekspor lama tersimpan di object storage lebih lama daripada yang diingat siapa pun.

Ketika itu terjadi, desain penyimpanan kata sandi Anda menjadi perbedaan antara penyerang menerima kata sandi dan penyerang menerima masalah penebakan yang mahal.

Itulah yang sebenarnya dilindungi oleh hashing kata sandi.