Password Hashing untuk Pemula: Kenapa MD5 Berbahaya dan Bcrypt/Argon2 Jadi Standar

Setiap kali sebuah situs mengumumkan "kebocoran data pengguna", pertanyaan pertama yang seharusnya muncul adalah: bagaimana password-nya disimpan? Jawabannya menentukan apakah kebocoran itu bencana besar atau sekadar insiden yang bisa ditangani dengan tenang.

Banyak developer pemula sudah tahu "jangan simpan password polos". Tapi tahap berikutnya sering disalahpahami: tidak semua hashing itu setara. MD5 dan SHA-1 pun sebenarnya hashing — tapi keduanya tidak cocok untuk password, dan memahami kenapa adalah pelajaran penting soal keamanan aplikasi.

Kenapa Password Polos Adalah Bencana

Menyimpan password dalam bentuk teks biasa (plaintext) berarti siapa pun yang punya akses ke database — administrator nakal, penyerang yang berhasil masuk, atau bahkan backup yang bocor — langsung mendapatkan password asli pengguna.

Masalahnya berlipat ganda karena kebiasaan manusia: banyak orang memakai password yang sama di berbagai layanan. Satu kebocoran plaintext bisa membuka pintu ke akun email, media sosial, bahkan rekening bank orang yang sama.

Hashing: Jalan Satu Arah

Solusinya adalah hashing — fungsi matematika yang mengubah input apa pun menjadi string dengan panjang tetap, dan yang terpenting: tidak bisa dibalik. Anda tidak bisa mengambil hasil hash lalu "menghitung mundur" untuk mendapatkan password aslinya.

password123  →  ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94

Saat pengguna mendaftar, aplikasi menghitung hash dari passwordnya dan menyimpan hash itu — bukan passwordnya. Saat login, aplikasi menghitung hash dari password yang dimasukkan, lalu membandingkannya dengan hash yang tersimpan. Cocok berarti password benar, tanpa aplikasi pernah perlu tahu atau menyimpan password aslinya.

Sampai di sini terdengar aman. Tapi ada jebakan besar: tidak semua algoritma hash dirancang untuk kasus ini.

Kenapa MD5 dan SHA-1/SHA-256 Berbahaya untuk Password

MD5 dan keluarga SHA (SHA-1, SHA-256) memang fungsi hash — tapi mereka dirancang untuk tujuan berbeda: memverifikasi integritas file, membuat checksum, atau tanda tangan digital. Tujuan-tujuan itu justru menginginkan hashing yang secepat mungkin, supaya bisa memverifikasi file besar dengan cepat.

Kecepatan itulah masalahnya ketika dipakai untuk password. Algoritma seperti MD5 bisa dihitung miliaran kali per detik dengan GPU modern. Ini membuka dua teknik serangan:

1. Brute force. Penyerang mencoba semua kombinasi karakter yang mungkin. Dengan kecepatan miliaran hash per detik, password pendek bisa ditembus dalam hitungan menit hingga jam.

2. Rainbow table. Penyerang sudah menghitung sebelumnya hash dari jutaan password umum (123456, password, qwerty, dan seterusnya), lalu tinggal mencocokkan hash yang bocor dengan tabel itu. Untuk password umum, hasilnya bisa didapat hampir seketika — tanpa perlu menghitung apa pun secara real-time.

MD5 dan SHA-1 juga punya masalah tambahan: keduanya sudah terbukti rentan collision (dua input berbeda menghasilkan hash yang sama), yang membuat keduanya sudah ditinggalkan bahkan untuk keperluan integritas data sekalipun.

Mengapa Salt Saja Tidak Cukup

Langkah pertama yang biasa diajarkan untuk memperbaiki MD5/SHA adalah menambah salt — string acak unik yang digabungkan dengan password sebelum di-hash:

hash(password + salt)

Salt memang menyelesaikan satu masalah: rainbow table generik jadi tidak berguna, karena setiap pengguna punya salt berbeda sehingga hash-nya pun berbeda meski passwordnya sama.

Tapi salt tidak mengatasi masalah kecepatan. Algoritma MD5+salt tetap bisa dihitung miliaran kali per detik. Penyerang yang menargetkan satu akun spesifik masih bisa brute force dengan cepat begitu tahu salt-nya (dan salt memang tidak dirahasiakan — biasanya disimpan berdampingan dengan hash).

Yang sebenarnya dibutuhkan bukan sekadar salt, melainkan algoritma yang sengaja dibuat lambat.

Solusinya: Algoritma Hashing Khusus Password

Inilah alasan lahirnya algoritma seperti bcrypt, scrypt, dan Argon2 — dirancang dari awal untuk satu tujuan spesifik: memperlambat penyerang, bukan mempercepat verifikasi.

Ciri utamanya:

• Cost factor / work factor — jumlah putaran komputasi bisa diatur naik seiring waktu, mengikuti perkembangan kecepatan hardware penyerang.
• Salt otomatis — dihasilkan dan disimpan sebagai bagian dari hash-nya sendiri, developer tidak perlu mengelolanya manual.
• Memory-hard (khusus Argon2 dan scrypt) — algoritma sengaja membutuhkan banyak memori, bukan cuma waktu CPU. Ini membuat serangan lewat GPU atau hardware khusus (ASIC) jauh lebih mahal dan tidak efisien.

Contoh bcrypt di Node.js:

const bcrypt = require('bcrypt');

// Saat registrasi
const saltRounds = 12;
const hash = await bcrypt.hash(password, saltRounds);
// Simpan `hash` ke database

// Saat login
const cocok = await bcrypt.compare(passwordInput, hashDariDatabase);

Contoh Argon2 (algoritma pemenang Password Hashing Competition 2015, direkomendasikan OWASP saat ini):

const argon2 = require('argon2');

// Saat registrasi
const hash = await argon2.hash(password);

// Saat login
const cocok = await argon2.verify(hashDariDatabase, passwordInput);

Perhatikan bahwa Anda tidak perlu mengelola salt secara manual — kedua library menanganinya secara otomatis dan menyimpannya menyatu di dalam string hash yang dihasilkan.

Perbandingan Singkat

Jika Anda menemukan kode lama yang masih memakai md5($password) atau sha1($password), itu bukan sekadar "kurang optimal" — itu adalah kerentanan aktif yang perlu segera diganti.

Praktik Tambahan yang Perlu Diingat

• Jangan pernah membuat algoritma hashing sendiri. Kriptografi adalah bidang yang mudah terlihat benar padahal salah. Selalu pakai library yang sudah diaudit dan teruji publik.
• Naikkan cost factor secara berkala. Rekomendasi hari ini bisa jadi terlalu ringan lima tahun lagi seiring hardware makin cepat. Beberapa library mendukung migrasi otomatis saat pengguna login ulang.
• Batasi percobaan login (rate limiting). Hashing yang kuat tetap perlu didampingi pembatasan percobaan login untuk mencegah brute force online terhadap akun spesifik.
• Terapkan MFA (multi-factor authentication) sebagai lapisan tambahan — bahkan jika hash bocor, akun tetap terlindungi tanpa faktor kedua.

Penutup

Perbedaan antara MD5 dan Argon2 mungkin terlihat seperti detail teknis kecil, tetapi dalam skenario kebocoran data, perbedaan itu adalah selisih antara "penyerang butuh berabad-abad" dan "penyerang sudah dapat semuanya sebelum sarapan".

Aturan sederhananya: jika Anda sedang membangun sistem autentikasi hari ini, jangan sentuh MD5 atau SHA mentah sama sekali. Langsung pakai bcrypt atau Argon2 sejak baris kode pertama — bukan sebagai perbaikan nanti, tapi sebagai fondasi sejak awal.