Di halaman fitur banyak aplikasi, kamu mungkin pernah membaca kalimat seperti "password dilindungi enkripsi standar militer". Terdengar meyakinkan, tapi apa sebenarnya artinya? Dan apakah pemilik bisnis kecil perlu peduli?
Saya memakai kalimat itu sendiri di materi beberapa produk, karena DevRAB memang melindungi akun admin dengan PBKDF2 SHA-256. Justru karena itu saya merasa perlu menjelaskannya dengan jujur: apa yang sebenarnya terjadi pada password, dan kenapa ini bukan fitur yang boleh dilewatkan.
Dua Kemungkinan Setelah Database Bocor (Ilustrasi)
Bayangkan database sebuah sistem bisnis bocor ke tangan orang yang tidak berhak. Ini bisa terjadi pada sistem mana pun, besar maupun kecil. Yang menentukan seberapa parah akibatnya adalah cara password disimpan.
Kemungkinan pertama: password tersimpan apa adanya. Penyerang membuka tabel pengguna dan langsung membaca semua password. Karena banyak orang memakai password yang sama di banyak tempat, kebocoran satu sistem merembet ke email, media sosial, bahkan akun lain milik mereka.
Kemungkinan kedua: password tersimpan sebagai hash bersalt dengan banyak putaran. Penyerang mendapat deretan karakter acak yang tidak bisa dibaca, dan untuk menebak satu password saja ia harus mengulang proses pengolahan yang sengaja dibuat lambat. Dampaknya terbatas. Perbedaan dua kemungkinan inilah alasan fitur ini penting.
Pertama: Password yang Baik Tidak Disimpan Sama Sekali
Sistem yang benar tidak menyimpan passwordmu. Yang disimpan adalah hasil olahan satu arah dari password itu, disebut hash. Saat kamu login, sistem mengolah password yang kamu ketik dengan cara yang sama lalu membandingkan hasilnya. Cocok berarti benar, tanpa pernah perlu menyimpan password aslinya.
Konsekuensi menariknya: pengelola sistem pun tidak bisa memberi tahu passwordmu kalau kamu lupa. Yang bisa dilakukan hanya mengatur ulang. Kalau sebuah layanan bisa mengirimkan password lamamu lewat email, itu tanda bahaya.
Hashing, Bukan Enkripsi
Secara teknis, enkripsi itu bisa dibuka kembali dengan kunci, sedangkan hashing tidak bisa dibalik. Untuk password, yang kita inginkan adalah hashing. Jadi kalau ada vendor menulis "enkripsi password", biasanya yang dimaksud sebenarnya hashing. Istilah enkripsi dipakai karena lebih mudah dipahami orang awam.
Dan frasa "standar militer" lebih tepat dibaca sebagai bahasa pemasaran. Yang bisa diperiksa adalah nama algoritmanya. PBKDF2 adalah metode terbuka yang dipublikasikan dan sudah lama dipakai luas, bukan rahasia dan bukan milik militer mana pun. Kabar baiknya, justru karena terbuka dan banyak diuji, ia bisa dipercaya.
Salt: Supaya Password yang Sama Tidak Menghasilkan Hash yang Sama
Bayangkan dua karyawan sama-sama memakai password yang umum. Tanpa tambahan apa pun, hash keduanya akan identik, dan penyerang yang berhasil menebak satu otomatis tahu yang lain. Penyerang juga bisa memakai tabel hash siap pakai berisi jutaan password umum untuk mencocokkan secara instan.
Salt menyelesaikannya. Sebelum diolah, setiap password digabung dengan serangkaian karakter acak yang unik untuk masing-masing akun. Akibatnya, dua password yang sama menghasilkan hash yang berbeda, dan tabel siap pakai milik penyerang jadi tidak berguna. Inilah yang dimaksud frasa "enkripsi acak bersalt" di Assets DEMO.
Putaran: Sengaja Dibuat Lambat
Bagian PBKDF2 yang paling menarik adalah iterasinya. Pengolahan password sengaja diulang puluhan ribu kali. Untuk satu kali login, itu hanya memakan sepersekian detik, nyaris tidak terasa oleh pengguna. Tapi bagi penyerang yang mencoba jutaan tebakan, setiap tebakan menjadi mahal, sehingga serangan tebak-tebakan yang tadinya cepat berubah menjadi sangat lambat.
Di Issue Tracker, misalnya, password diolah dengan PBKDF2-HMAC-SHA256 plus salt sebanyak 60.000 putaran. Hash lama bahkan diperkuat otomatis saat pengguna login, jadi akun lama ikut naik standar tanpa pengguna melakukan apa-apa.
Satu catatan jujur: di sana saya memakai PBKDF2 karena batasan platform Google Apps Script, bukan karena menganggapnya satu-satunya pilihan. Ada metode lain seperti bcrypt, dan pilihan terbaik memang bergantung pada platform yang dipakai.
Hash Saja Tidak Cukup: Lapisan di Sekitarnya
Password yang tersimpan dengan baik tetap bisa ditebak kalau pintu login terbuka tanpa batas. Karena itu perlindungan harus berlapis. Contoh dari produk yang saya bangun:
• Issue Tracker: lima kali gagal login menyebabkan akun terkunci bertahap, 1 menit, lalu 5 menit, lalu 15 menit. Hitungan kembali ke awal setelah 1 jam tanpa percobaan. Password juga ditolak kalau berupa kata umum atau urutan sederhana.
• DevRAB: sistem anti brute-force memblokir percobaan masuk mencurigakan yang berulang, dan portal klien hanya menampilkan proposal yang bersangkutan.
• Assets DEMO: sesi tunggal mencegah satu akun dipakai bersamaan, dan akses dibagi per peran.
Keamanan sistem datang dari kombinasi lapisan-lapisan ini, bukan dari satu istilah yang terdengar canggih.
Bagian yang Tetap Tanggung Jawab Pengguna
Secanggih apa pun penyimpanannya, password lemah tetap lemah. Beberapa kebiasaan sederhana yang layak disampaikan ke tim:
• Pilih password yang panjang. Kalimat acak yang mudah diingat lebih kuat daripada kata pendek dengan simbol.
• Jangan memakai password yang sama di banyak layanan.
• Pertimbangkan password manager supaya tidak perlu mengingat semuanya.
• Jangan membagikan password lewat chat, dan jangan berbagi akun.
Sistem yang baik membantu dengan menolak password yang terlalu umum dan membatasi percobaan, tetapi kebiasaan penggunanya tetap menentukan.
Apa yang Perlu Kamu Tanyakan ke Developer
Kamu tidak perlu memahami matematikanya. Cukup ajukan beberapa pertanyaan berikut:
1. Apakah password disimpan sebagai hash dengan salt, dan bukan sebagai teks biasa?
2. Algoritma apa yang dipakai, dan berapa putarannya?
3. Apa yang terjadi kalau seseorang menebak password berkali-kali?
4. Apakah akun yang dibajak bisa dideteksi, misalnya lewat pembatasan sesi?
5. Kalau saya lupa password, apakah sistem mengirim password lama, atau mengatur ulang yang baru?
Developer yang serius akan menjawab semuanya dengan lugas. Kalau jawabannya hanya "aman kok, pakai enkripsi", tanyakan lebih lanjut. Pertanyaan spesifik adalah cara termudah membedakan keamanan sungguhan dari sekadar slogan.
Salah satu lapisan lain yang layak ditanyakan adalah pembatasan sesi, yang saya bahas di artikel "Single Active Session: Fitur Kecil yang Mencegah Akun Dibajak atau Dipakai Bersama".
Kesimpulan & Refleksi
Perlindungan password yang baik intinya tiga hal: jangan simpan passwordnya, beri salt agar setiap hash unik, dan perlambat proses tebakan lewat banyak putaran. Sisanya adalah lapisan pendukung seperti penguncian login dan pembatasan sesi.
Ini bukan fitur yang dipamerkan di brosur, tapi justru saat terjadi kebocoran data, inilah yang menentukan apakah dampaknya terbatas atau meluas. Untuk sistem yang menyimpan data bisnismu, layak dipastikan fondasi ini ada. Kalau kamu ingin membahas keamanan untuk sistem bisnismu, kamu bisa mengobrol dulu lewat WhatsApp.