bcrypt vs Argon2: memilih pengaturan hashing kata sandi

Masalah yang diselesaikan password hashing

Password hashing memungkinkan backend menyimpan kata sandi tanpa menyimpan kata sandi itu sendiri. Saat seseorang mendaftar, server menjalankan kata sandi melalui fungsi satu arah dan menyimpan hasilnya (hash). Saat login, server meng-hash kata sandi yang diketik pengguna dan membandingkannya dengan yang tersimpan.

Hash bukan enkripsi. Tidak ada cara untuk mendekripsinya. Sifat satu arah inilah alasan hashing digunakan untuk kata sandi.

Lalu kenapa tidak menggunakan hash cepat seperti SHA-256? Karena cepat adalah yang diinginkan penyerang. Jika sebuah database dicuri, penyerang tidak menebak kata sandi dengan mencoba login satu per satu. Mereka menebak secara offline menggunakan daftar hash yang dicuri, mendorong tebakan secepat perangkat keras mereka mengizinkan. Dengan GPU, hash cepat bisa diuji dalam skala besar. Bahkan dengan salt unik, hash cepat masih murah untuk brute-force.

Mode kegagalan yang realistis seperti ini: sebuah aplikasi web kecil kehilangan tabel penggunanya dalam suatu breach. Penyerang mendapatkan email dan hash kata sandi. Jika hash dibuat dengan fungsi cepat, kata sandi umum dan variasi kecilnya cepat terungkap. Lalu penyerang mencoba kata sandi yang sama di situs lain (credential stuffing), atau menggunakannya untuk mengakses fitur berprivilege tinggi di dalam aplikasi Anda.

Hash kata sandi yang baik membuat penebakan menjadi mahal. Tujuannya bukan “tidak bisa ditembus.” Tujuannya adalah “terlalu lambat dan mahal sehingga tidak sepadan.”

Sebuah setup hashing kata sandi harus:

• Satu arah (verifikasi, bukan pembalikan)
• Lambat per tebakan
• Mahal untuk perangkat paralel (terutama GPU)
• Cukup cepat sehingga login nyata terasa normal
• Dapat disesuaikan sehingga Anda bisa menaikkan biaya dari waktu ke waktu

bcrypt dan Argon2, dalam satu menit

Saat Anda membandingkan bcrypt vs Argon2, Anda memilih cara memperlambat penebakan kata sandi setelah kebocoran database.

bcrypt adalah opsi yang lebih tua dan banyak didukung. Ia dirancang agar mahal pada CPU, dan memiliki satu pengaturan utama: cost factor. Ia juga “membosankan” dalam arti baik: mudah ditemukan di library, mudah dipakai, dan dapat diprediksi.

Argon2 lebih baru dan dirancang supaya memerlukan banyak memori. Ia bisa memaksa setiap tebakan kata sandi menggunakan jumlah RAM yang berarti, bukan hanya CPU. Itu penting karena penyerang sering menang dengan menjalankan banyak tebakan paralel di GPU atau perangkat khusus. Memori lebih sulit dan lebih mahal untuk diskalakan pada tingkat paralel seperti itu.

Argon2 memiliki tiga varian:

• Argon2i: menekankan resistensi terhadap beberapa serangan side-channel
• Argon2d: menekankan resistensi terhadap GPU, dengan pertimbangan side-channel yang berbeda
• Argon2id: campuran praktis dari keduanya, dan default umum untuk hashing kata sandi

Jika stack Anda mendukung Argon2id dan Anda bisa men-tune memori dengan aman, biasanya itu pilihan modern terbaik. Jika Anda butuh kompatibilitas maksimal di sistem lama, bcrypt masih pilihan solid jika dikonfigurasi dengan faktor biaya yang cukup tinggi.

Properti keamanan yang paling penting

Pertanyaan inti sederhana: jika penyerang mencuri database kata sandi, seberapa mahal menebak kata sandi dalam skala besar?

Dengan bcrypt, Anda mengontrol cost (work factor). Cost yang lebih tinggi berarti setiap tebakan butuh waktu lebih lama. Itu memperlambat penyerang dan juga memperlambat pemeriksaan login Anda sendiri, jadi Anda men-tune hingga titik yang menyulitkan penyerang tetapi masih bisa diterima pengguna.

Dengan Argon2id, Anda bisa menambahkan ketergantungan pada memori di atas biaya waktu. Setiap tebakan butuh waktu CPU dan RAM yang diakses dalam pola tertentu. GPU bisa sangat cepat untuk kerja komputasi berat, tetapi mereka kehilangan banyak keunggulan ketika setiap tebakan paralel membutuhkan memori signifikan.

Salt tidak bisa ditawar. Salt acak unik per kata sandi:

• mencegah tabel pra-komputasi dipakai ulang di seluruh database Anda
• memastikan kata sandi identik tidak menghasilkan hash identik antar pengguna

Salt tidak membuat kata sandi lemah menjadi kuat. Salt terutama melindungi Anda setelah kebocoran database dengan memaksa penyerang melakukan kerja nyata per pengguna.

Kekuatan dan batas bcrypt yang perlu Anda tahu

bcrypt masih banyak dipakai, terutama karena mudah dideploy di mana-mana. Ia cocok ketika Anda membutuhkan interoperabilitas luas, ketika stack Anda punya opsi kripto terbatas, atau ketika Anda ingin satu tuas penyesuaian yang sederhana.

Kejutan terbesar adalah batas 72-byte. bcrypt hanya menggunakan 72 byte pertama dari kata sandi dan mengabaikan sisanya. Ini bisa mengejutkan orang yang memakai passphrase panjang atau password manager.

Jika Anda memilih bcrypt, jelaskan perilaku panjang kata sandi. Entah tetapkan panjang maksimal (dalam byte, bukan karakter) atau tangani input panjang secara konsisten di semua layanan. Yang penting adalah menghindari pemangkasan diam-diam yang mengubah apa yang pengguna pikir sebagai kata sandi mereka.

bcrypt juga kurang tahan terhadap perangkat cracking paralel modern dibanding opsi yang memerlukan memori. Pertahanannya tetap valid, tetapi sangat bergantung pada memilih cost factor yang membuat tiap tebakan mahal.

Jika Anda membangun sistem baru atau memiliki akun bernilai tinggi (paket berbayar, peran admin), memigrasikan hash baru ke Argon2id sambil terus menerima hash bcrypt yang ada sampai pengguna login adalah jalur umum dan berisiko rendah.

Kekuatan dan trade-off Argon2

Argon2 dibuat untuk hashing kata sandi. Argon2id adalah varian yang dipilih banyak tim karena menyeimbangkan resistensi GPU dengan perlindungan yang masuk akal terhadap side-channel.

Argon2id memberi Anda tiga parameter:

• Memori (m): berapa banyak RAM yang digunakan setiap hash saat berjalan
• Waktu/iterasi (t): berapa kali ia melewati memori itu
• Paralelisme (p): berapa banyak lane yang digunakan (membantu pada CPU multi-core)

Memori adalah keuntungan utama. Jika setiap tebakan membutuhkan jumlah RAM yang berarti, penyerang tidak bisa menjalankan sebanyak tebakan secara paralel tanpa membayar mahal untuk kapasitas dan bandwidth memori.

Kekurangannya adalah operasional: lebih banyak memori per hash berarti lebih sedikit login bersamaan sebelum server Anda terasa tertekan. Jika Anda menetapkan memori terlalu tinggi, lonjakan login dapat menyebabkan antrean, timeouts, atau bahkan kegagalan out-of-memory. Anda juga harus memikirkan penyalahgunaan: banyak upaya login bersamaan bisa menjadi masalah sumber daya jika Anda tidak membatasi pekerjaan.

Untuk menjaga Argon2id aman dan bisa dipakai, atur seperti fitur performa:

• lakukan benchmark di perangkat keras mirip produksi
• batasi pekerjaan hashing bersamaan (kap pekerja, antrean)
• batasi laju percobaan login dan kunci untuk kegagalan berulang
• jaga pengaturan konsisten di seluruh layanan sehingga satu endpoint lemah tidak jadi target

Biaya performa di backend web nyata

Dengan hashing kata sandi, “lebih cepat lebih baik” biasanya tujuan yang salah. Anda ingin tiap tebakan jadi mahal bagi penyerang sementara login tetap terasa cepat bagi pengguna nyata.

Cara praktis untuk mengatur ini adalah anggaran waktu per verifikasi pada perangkat keras produksi Anda. Banyak tim menargetkan sekitar 100 hingga 300 ms per pemeriksaan hash, tetapi angka yang tepat bergantung pada lalu lintas dan server Anda. Perbedaan antara bcrypt dan Argon2 adalah apa yang Anda bayar: bcrypt kebanyakan menghabiskan waktu CPU, sedangkan Argon2 juga bisa memesan memori.

Pilih target waktu, lalu ukur

Pilih waktu target per hash dan uji dalam kondisi yang menyerupai produksi. Ukur baik hashing pada signup/ubah kata sandi maupun verifikasi login, tetapi perlakukan login sebagai jalur panas.

Rencana pengukuran ringan:

• uji 1, 10, dan 50 pemeriksaan login bersamaan dan catat p50 serta p95 latensi
• ulangi run untuk mengurangi noise dari caching dan boosting CPU
• ukur panggilan database secara terpisah sehingga Anda tahu berapa biaya hashing sebenarnya
• uji dengan container dan batas CPU yang sama seperti deployment

Lonjakan lebih penting daripada rata-rata

Kebanyakan sistem gagal saat puncak. Jika sebuah email pemasaran mengarahkan gelombang pengguna ke halaman login, pengaturan hashing Anda yang menentukan apakah sistem tetap responsif.

Jika satu verifikasi membutuhkan 250 ms dan server Anda bisa menangani 40 secara paralel sebelum antre, lonjakan 500 permintaan login bisa berubah menjadi tunggu beberapa detik. Dalam situasi itu, sedikit pengurangan biaya ditambah batas laju yang kuat bisa meningkatkan keamanan nyata lebih daripada mendorong parameter sampai endpoint login menjadi rapuh.

Jaga login interaktif tetap dapat diprediksi

Tidak semua operasi kata sandi memerlukan urgensi yang sama. Jaga biaya login interaktif stabil, lalu lakukan pekerjaan berat di luar jalur kritis. Pola umum adalah rehash-on-login (tingkatkan hash pengguna segera setelah login sukses) atau pekerjaan latar untuk migrasi dan impor.

Cara memilih parameter langkah demi langkah

Penyesuaian parameter tentang menaikkan biaya penyerang per tebakan tanpa membuat sign-in lambat atau merusak server Anda.

1. Pilih algoritma yang didukung stack Anda dengan baik. Jika Argon2id tersedia dan didukung, biasanya itu pilihan default. Jika Anda butuh kompatibilitas luas, bcrypt masih oke.

2. Tetapkan target waktu per hash di perangkat keras mirip produksi. Pilih sesuatu yang menjaga login tetap mulus saat beban puncak.

3. Sesuaikan untuk mencapai waktu itu. Dengan bcrypt, ubah cost factor. Dengan Argon2id, seimbangkan memori, iterasi, dan paralelisme. Memori adalah tuas yang paling mengubah ekonomi penyerang.

4. Simpan algoritma dan pengaturan bersama hash. Banyak format hash standar sudah menyematkan detail ini. Pastikan juga kolom database cukup panjang sehingga hash tidak pernah terpotong.

5. Rencanakan upgrade dengan rehash-on-login. Ketika pengguna login, jika hash tersimpan menggunakan pengaturan lebih lemah dari kebijakan saat ini, rehash dan ganti.

Titik awal praktis

Jika Anda butuh baseline sebelum mengukur, mulailah konservatif dan sesuaikan berdasarkan waktu.

• Untuk bcrypt, banyak tim memulai di sekitar cost 12 dan menyesuaikan berdasarkan pengukuran nyata.
• Untuk Argon2id, baseline umum adalah memori dalam puluhan hingga beberapa ratus MB, time cost 2 sampai 4, dan paralelisme 1 sampai 2.

Anggap ini titik awal, bukan aturan. Pengaturan yang tepat adalah yang cocok dengan lalu lintas, perangkat keras, dan lonjakan login puncak Anda.

Kesalahan umum yang melemahkan penyimpanan kata sandi

Sebagian besar kegagalan penyimpanan kata sandi berasal dari celah setup, bukan dari algoritma yang rusak.

Kesalahan salt adalah salah satu besar. Setiap kata sandi perlu salt unik yang disimpan bersama hash. Mengulang salt, atau menggunakan satu salt global untuk semua pengguna, mempermudah penyerang menggunakan ulang kerja dan membandingkan akun.

Mengabaikan biaya adalah lain. Tim sering mengirim dengan biaya rendah karena login terasa lebih cepat, lalu tidak pernah meninjau lagi. Perangkat keras membaik, penyerang skala naik, dan pengaturan yang tadinya cukup menjadi murah.

Over-tuning Argon2 juga umum. Menetapkan memori sangat tinggi bisa terlihat bagus di atas kertas, lalu menyebabkan login lambat, antrean permintaan, atau kesalahan OOM saat lonjakan nyata.

Perlakuan panjang kata sandi penting, terutama dengan perilaku 72-byte bcrypt. Jika Anda membolehkan kata sandi panjang tapi memangkasnya diam-diam, Anda menciptakan perilaku membingungkan dan mengurangi keamanan.

Beberapa kebiasaan praktis mencegah sebagian besar masalah ini:

• gunakan salt unik per kata sandi (biarkan library yang menghasilkannya)
• lakukan load test dan tinjau pengaturan secara berkala
• tune memori Argon2 untuk lalu lintas puncak, bukan hanya benchmark satu-login
• buat batas panjang kata sandi eksplisit dan konsisten
• pasang batas concurrency dan monitoring pada endpoint login

Daftar periksa singkat untuk setup yang lebih aman

Simpan daftar pendek ini saat Anda deploy dan saat mengubah infrastruktur:

• Salt unik per kata sandi, dibuat secara acak dan disimpan bersama hash
• Biaya hashing yang bertahan saat beban puncak, diverifikasi dengan load test pada perangkat keras mirip produksi
• Parameter disimpan bersama hash, sehingga Anda bisa memverifikasi akun lama dan menaikkan biaya nanti
• Kontrol serangan online, termasuk batas laju dan penguncian singkat untuk kegagalan berulang
• Jalur upgrade, biasanya rehash-on-login

Pemeriksaan kesehatan sederhana: jalankan tes staging yang mencakup lonjakan login (sukses dan gagal) dan pantau latensi end-to-end serta penggunaan CPU dan RAM. Jika jalur login kesulitan, tune biaya dan perketat batas laju. Jangan “memperbaiki” dengan memangkas hal esensial seperti salt.

Contoh realistis: men-tune untuk aplikasi web kecil

Bayangkan sebuah aplikasi SaaS kecil dengan beberapa ribu pengguna. Sebagian besar hari lalu lintas stabil, tetapi Anda melihat lonjakan singkat setelah newsletter atau saat awal hari kerja. Di sinilah pilihan menjadi perencanaan kapasitas.

Anda memilih Argon2id untuk menaikkan biaya cracking offline. Pilih target waktu verifikasi pada perangkat keras server nyata Anda (misalnya 100–250 ms), lalu tune parameter untuk mencapainya sambil memantau RAM, karena pengaturan memori bisa membatasi berapa banyak login yang bisa Anda tangani sekaligus.

Loop tuning praktis seperti ini:

• mulai dengan iterasi dan paralelisme moderat
• tingkatkan memori sampai concurrency terasa tidak nyaman
• sesuaikan iterasi untuk menghaluskan biaya waktu
• uji ulang dengan simulasi lonjakan, bukan hanya permintaan tunggal

Jika Anda sudah punya hash lama dengan pengaturan lebih lemah, terus verifikasi mereka tetapi upgrade secara senyap. Saat login sukses, rehash dengan pengaturan saat ini dan simpan nilai baru. Seiring waktu, pengguna aktif berpindah ke hash yang lebih kuat tanpa perlu reset paksa.

Setelah rilis, pantau login seperti endpoint kritis lain: tail latency (p95/p99), CPU dan RAM saat lonjakan, lonjakan kegagalan login, dan seberapa cepat hash lama diganti.

Langkah selanjutnya: deploy dengan aman dan terus tingkatkan

Tuliskan kebijakan Anda dan anggap itu pengaturan yang hidup. Misalnya: “Argon2id dengan X memori, Y iterasi, Z paralelisme” atau “bcrypt cost factor N,” plus tanggal pemilihannya dan kapan akan ditinjau (setiap 6–12 bulan adalah awal yang baik).

Sediakan jalur upgrade sehingga Anda tidak terjebak dengan hash lama. Rehash-on-login sederhana dan bekerja baik di kebanyakan sistem.

Hash yang kuat membantu, tetapi tidak menggantikan kontrol penyalahgunaan online. Batas laju, penguncian, dan alur reset kata sandi yang hati-hati sama pentingnya untuk keamanan nyata.

Jika Anda membangun backend menggunakan platform no-code seperti AppMaster, ada baiknya memeriksa bahwa modul autentikasi menggunakan hashing kata sandi yang kuat secara default dan bahwa biaya hashing ditune pada jenis infrastruktur yang sama dengan yang akan Anda deploy. Sedikit pengujian awal sering menjadi perbedaan antara “aman dan lancar” dan “aman tetapi tidak bisa dipakai saat beban tinggi.”