Dalam satu kalimat
Algoritma password hashing seperti bcrypt dan Argon2 mengubah password pengguna menjadi serangkaian karakter panjang yang tidak bisa dibalik (irreversible), didesain agar lambat dan mahal untuk dihitung, sehingga penyerang bakal susah payah membobolnya bahkan jika mereka berhasil mencuri seluruh database pengguna kamu.
Masalah yang diselesaikan
Di zaman kegelapan digital, para developer menyimpan password pengguna dalam bentuk plaintext. Kalau seorang hacker berhasil membobol database, mereka akan mendapatkan file berisi setiap username dan password-nya. Game over. Kebayang kan bencananya.
Langkah pertama untuk jadi lebih baik adalah "hashing". Alih-alih menyimpan P@ssword123, kamu akan menyimpan hash-nya—sebuah string dengan panjang tetap yang dihasilkan oleh algoritma seperti MD5 atau SHA-1. Saat pengguna login, kamu akan melakukan hash pada password yang mereka masukkan dan melihat apakah cocok dengan hash yang tersimpan. Ini lebih baik, tapi punya kelemahan fatal: rainbow tables. Karena fungsi hash selalu menghasilkan output yang sama untuk input yang sama (misalnya, password akan selalu di-hash menjadi 5f4dcc3b5aa765d61d8327deb882cf99 dengan MD5), para penyerang melakukan pra-hitung hash untuk miliaran password umum dan menyimpannya dalam tabel pencarian raksasa. Hash yang dicuri bisa dibalikkan ke password aslinya dalam hitungan milidetik.
Evolusi berikutnya adalah "salting". Sebelum melakukan hashing pada password, kamu menambahkan string acak yang unik yang disebut "salt". Jadi, alih-alih menghash P@ssword123, kamu akan menghash P@ssword123 + aBcDeFg12345. Salt ini kemudian disimpan bersama dengan hash di database. Ini benar-benar melumpuhkan rainbow tables, karena sekarang hash setiap pengguna menjadi unik, bahkan jika mereka semua memilih password "password". Seorang penyerang harus membuat rainbow table baru untuk setiap salt unik milik masing-masing pengguna, yang mana tidak memungkinkan secara komputasi.
Tapi kemudian muncul penjahat baru: kekuatan komputasi mentah. GPU modern dan hardware kustom (ASIC) dapat mencoba miliaran kombinasi password dengan salt per detik terhadap satu hash yang dicuri. Algoritma hashing seperti SHA-256 sengaja dibuat cepat, yang bagus untuk memverifikasi integritas file tapi sangat buruk untuk melindungi password.
Inilah masalah yang coba diselesaikan oleh bcrypt dan Argon2. Keduanya adalah fungsi password hashing (PHF), kelas khusus dari algoritma hash yang sengaja dibuat super lambat dan boros sumber daya. Mereka membuat proses pengecekan satu password pun menjadi sangat mahal sehingga melakukan brute-force pada database yang dicuri menjadi mimpi buruk dari segi biaya dan waktu bagi si penyerang.
Cara kerjanya di balik layar
Keajaiban di balik password hashing modern bukan hanya tentang algoritmanya; tapi tentang membuat algoritma itu melakukan "pekerjaan" dalam jumlah yang bisa dikonfigurasi. Ini sering disebut "key stretching".
Ide Utamanya: Biaya Adaptif
Baik bcrypt maupun Argon2 memiliki faktor "biaya" atau "beban kerja" yang bisa diatur. Inilah kekuatan super mereka. Ini adalah angka yang kamu setel untuk menentukan seberapa lambat dan boros sumber daya proses hashing tersebut. Idenya adalah untuk mengatur biaya ini sehingga hashing password di server kamu memakan waktu yang wajar (katakanlah, 100-500 milidetik)—cukup lambat untuk membuat frustrasi penyerang, tetapi cukup cepat agar tidak mengganggu pengguna.
Seiring komputer menjadi lebih cepat sesuai dengan Hukum Moore, kamu cukup menaikkan faktor biaya setiap beberapa tahun untuk mempertahankan tingkat keamanan yang sama. "Latihan" hashing kamu menjadi lebih berat seiring menguatnya hardware penyerang.
Bcrypt: Sang Veteran Terpercaya
Bcrypt, yang diperkenalkan pada tahun 1999, didasarkan pada sandi enkripsi Blowfish. Pertahanan utamanya terhadap serangan brute-force adalah karena ia tidak hanya intensif secara komputasi, tetapi juga intensif memori.
Algoritma ini berulang kali memproses password dan salt, tetapi bagian kunci dari state internalnya disimpan dengan cara yang memerlukan akses sering ke sepotong RAM. Sementara CPU bagus dalam hal ini, GPU—senjata pilihan penyerang—justru unggul dalam kalkulasi sederhana yang bisa diparalelkan dengan akses memori minimal. Dengan memaksa proses untuk terus-menerus mengakses memori, bcrypt mengacaukan kerja mesin pembobol berbasis GPU.
String hash bcrypt yang tipikal terlihat seperti ini:
$2b$12$J9yLsf9dTOZiCEpT1zO97uF2Yp3uG/yG4Q6V.C1rCg8u6d5qO5GqS
Mari kita bedah:
| Bagian | Contoh | Arti |
|---|---|---|
| Algoritma | $2b |
Mengidentifikasi algoritma dan versi bcrypt. |
| Faktor Biaya | 12 |
Faktor beban kerja. Jumlah iterasinya adalah 212. Menaikkannya 1 angka akan menggandakan waktu proses. |
| Salt & Hash | J9yLsf...d5qO5GqS |
22 karakter pertama adalah salt yang di-encode Base64. Sisanya adalah digest password yang sudah di-hash. |
Yang terpenting, semua informasi yang dibutuhkan untuk memverifikasi password—algoritma, biaya, dan salt—disimpan langsung di sana dalam satu string yang praktis.
Argon2: Jawara Modern
Argon2 adalah pemenang Password Hashing Competition (PHC) pada tahun 2015, sebuah upaya multi-tahun untuk menemukan algoritma password hashing baru yang terstandarisasi. Ia dirancang untuk lebih tahan terhadap serangan hardware modern daripada bcrypt.
Ia menawarkan tiga tuas kendali berbeda untuk mengatur biayanya:
- Biaya Memori (m): Jumlah memori (dalam KiB) yang akan digunakan oleh algoritma. Ini adalah pertahanan utamanya terhadap akselerasi hardware, karena dapat diatur untuk membutuhkan lebih banyak memori daripada yang tersedia di satu core GPU.
- Biaya Waktu (t): Jumlah iterasi, atau putaran, yang dilakukan algoritma pada memori. Ini meningkatkan total waktu komputasi.
- Paralelisme (p): Jumlah thread atau "jalur" yang dapat digunakan. Ini memungkinkan algoritma untuk memanfaatkan CPU multi-core untuk hashing, tetapi juga berarti penyerang dapat menggunakan paralelisme yang sama. Ini adalah parameter trade-off.
Varian yang direkomendasikan adalah Argon2id, yang merupakan hibrida dari dua versi lainnya. Ia memberikan resistensi yang seimbang terhadap serangan side-channel (di mana penyerang menganalisis efek sistem seperti konsumsi daya) dan serangan pembobolan GPU.
String hash Argon2id juga sama-sama mandiri:
$argon2id$v=19$m=65536,t=3,p=4$c29tZXNhbHQ$RdescudvJCsgt3ub+b+dWRWJTIT0T7cKLfgflAIk124
| Bagian | Contoh | Arti |
|---|---|---|
| Algoritma | $argon2id |
Mengidentifikasi algoritma Argon2id. |
| Versi | v=19 |
Nomor versi algoritma. |
| Parameter | m=65536,t=3,p=4 |
Biaya memori, waktu, dan paralelisme. |
| Salt | c29tZXNhbHQ |
Salt acak yang di-encode Base64. (Ini kalau di-decode jadi "somesalt"). |
| Hash | Rdescudv...flAIk124 |
Digest password yang sudah di-hash dan di-encode Base64. |
Proses Verifikasi
Ini bagian yang indahnya. Kamu tidak pernah mendekripsi sebuah hash. Verifikasi adalah jalan satu arah.
- Seorang pengguna mencoba login dengan
P@ssword123. - Aplikasi kamu mengambil string hash lengkap mereka dari database (misalnya, string Argon2id dari tabel di atas).
- Kode kamu mengurai string tersebut, mengekstrak algoritma (
argon2id), versi (19), faktor biaya (m=65536, t=3, p=4), dan salt (c29tZXNhbHQ). - Kemudian, kode mengambil password yang baru saja dimasukkan pengguna (
P@ssword123) dan melakukan hashing menggunakan parameter yang persis sama. - Terakhir, kode membandingkan hash yang baru dibuat dengan bagian hash dari string yang ada di database. Jika identik, passwordnya benar. Jika tidak, akses ditolak.
Kisah dari dunia nyata
Pembobolan LinkedIn 2012: Pelajaran tentang Kecepatan
Pada tahun 2012, LinkedIn mengalami pembobolan besar-besaran, dan lebih dari 6,5 juta hash password pengguna bocor ke sebuah forum hacker Rusia. Masalahnya? Hash-nya adalah SHA-1 tanpa salt. Dalam hitungan jam, para pegiat keamanan dan black hat sama-sama berlomba untuk membobolnya. Daftar password yang berhasil dibobol bertambah dari menit ke menit. Karena hash-nya "cepat" dan tanpa salt, satu rainbow table raksasa saja sudah cukup. Kerusakan reputasinya sangat besar.
Pelajaran: Hash yang cepat dan tanpa salt hampir tidak lebih baik dari plaintext. Pembobolan LinkedIn adalah pukulan telak yang menyadarkan industri, mendorong banyak perusahaan untuk akhirnya mengadopsi hashing yang lambat dan menggunakan salt seperti bcrypt.
Situs E-commerce yang Mengulur Waktu
Seorang developer cerdas di sebuah startup, "CircuitCraze," bersikeras menggunakan Argon2id untuk database pelanggan baru mereka, mengatur parameternya agar memakan waktu sekitar 300ms per login. Setahun kemudian, sebuah cloud storage bucket yang salah konfigurasi mengekspos backup database. Tabel users, dengan semua hash Argon2id-nya, diunduh oleh seorang penyerang. Tim segera memaksa semua pengguna untuk mereset password. Si penyerang, dihadapkan pada prospek menghabiskan ribuan dolar untuk komputasi awan hanya untuk membobol segelintir password dari dataset yang kini tidak berguna, akhirnya menyerah dan beralih ke target yang lebih gampang.
Pelajaran: Password hashing yang kuat adalah pertahanan utamamu setelah terjadi pembobolan. Ia tidak mencegah pembobolan itu sendiri, tetapi mengubah kebocoran data yang katastrofik menjadi insiden yang bisa ditangani dengan memberimu waktu krusial untuk bereaksi.
Peningkatan Cost Factor Bertahap
Sebuah tim meluncurkan aplikasi web baru pada tahun 2015, dengan bijak memilih bcrypt dengan cost factor 10. Semuanya berjalan lancar. Maju cepat ke hari ini. Hukum Moore telah bekerja, dan cost factor 10 sekarang dianggap lemah. Sebuah audit keamanan menandainya sebagai risiko prioritas tinggi. Tim sekarang menghadapi dilema: bagaimana mereka meningkatkan keamanan untuk jutaan pengguna tanpa memaksa reset password massal? Solusi elegannya: saat pengguna login berikutnya, sistem memverifikasi password mereka terhadap hash lama dengan cost 10. Jika benar, sistem segera menghash ulang password yang sama dengan cost 13 yang baru dan mengganti hash lama di database.
Pelajaran: Keamanan password bukanlah sesuatu yang "sekali atur lalu lupakan". Cost factor adalah pengaturan hidup yang harus ditinjau secara berkala dan ditingkatkan untuk mengimbangi kemampuan penyerang.
Kesalahan dan jebakan umum
- Menggunakan hash yang cepat. Jangan. MD5, SHA-1, SHA-256, SHA-512... itu semua untuk checksum, bukan password. Mereka dirancang untuk cepat, yang justru kebalikan dari yang kamu inginkan.
- Membuat skema kriptografi sendiri. Jangan pernah mencoba menciptakan skema hashing sendiri, seperti
sha512(password + salt). Gunakan library standar, yang sudah ditinjau oleh banyak ahli, dan teruji di lapangan untuk bcrypt atau Argon2 yang melakukannya dengan benar. - Menggunakan salt yang statis atau dipakai ulang. Sebuah salt harus acak secara kriptografis dan unik untuk setiap password yang kamu simpan. Menyimpan salt unik di samping setiap hash adalah praktik yang benar dan standar.
- Mengatur biaya terlalu rendah. Cost factor bcrypt di bawah 12 (pada tahun 2024) atau parameter Argon2 yang lemah akan menggagalkan seluruh tujuannya. Kamu sama saja memberi kemudahan bagi penyerang. Aturlah selambat mungkin yang bisa kamu toleransi.
- Mengatur biaya terlalu tinggi. Jika hashing memakan waktu 10 detik, form login kamu akan timeout dan terasa rusak. Lebih buruk lagi, kamu membuka servermu untuk serangan Denial-of-Service (DoS) di mana seseorang bisa membuat CPU kamu macet total hanya dengan berulang kali mengirim data ke form login.
- Hanya menyimpan digest hash-nya saja. String yang dihasilkan oleh bcrypt dan Argon2 mengandung algoritma, biaya, dan salt karena suatu alasan. Kamu harus menyimpan seluruh string tersebut (misalnya, dalam kolom
VARCHAR(255)) agar bisa memverifikasi password di masa depan.
Kenapa ini perlu kamu perhatikan
Jika pekerjaanmu melibatkan pembuatan apa pun yang memiliki form login, kamu perlu memahami ini.
- Developer Backend & Full-Stack: Ini adalah tanggung jawab langsungmu. Kalau salah di bagian ini, kamu mempertaruhkan keamanan semua penggunamu.
- Insinyur Keamanan & DevOps: Kalianlah yang menetapkan kebijakan, melakukan audit, dan mengelola infrastruktur. Kalian perlu tahu seperti apa standar yang "baik" itu dan cara mengujinya.
- Developer Frontend: Memahami bahwa login yang aman mungkin memakan waktu beberapa ratus milidetik menjelaskan mengapa kamu perlu memberikan umpan balik kepada pengguna (seperti ikon loading) untuk mencegah mereka mengklik tombol "Log In" berkali-kali karena kesal.
Singkatnya, jika kata "pengguna," "akun," atau "password" muncul di mana pun dalam persyaratan proyekmu, password hashing adalah konsep fundamental yang tidak boleh kamu abaikan.
Pelajari lebih dalam
- OWASP Password Storage Cheat Sheet — Panduan esensial dan otoritatif untuk developer.
- Argon2 Specification — Paper formal yang menjelaskan cara kerja Argon2.
- How To Safely Store A Password oleh Coda Hale — Postingan blog klasik dari tahun 2010 yang menjelaskan "mengapa" harus menggunakan bcrypt kepada satu generasi developer.
- Bcrypt on Wikipedia — Gambaran solid tentang sejarah dan desain algoritma.
- Argon2 on Wikipedia — Latar belakang tentang Password Hashing Competition dan desain Argon2.
- Password Hashing Competition — Situs resmi kompetisi yang memenangkan Argon2.