Kali Linux Indonesia: Cara Memilih Algoritma Hash Kata Sandi yang Aman

Kali Linux Indonesia sering menjadi tempat berbagi catatan lab tentang keamanan aplikasi, termasuk cara menyimpan kata sandi dengan benar. Memilih algoritma hash bukan sekadar memilih fungsi yang cepat, tetapi memilih biaya komputasi yang wajar bagi server dan mahal bagi penyerang. Di lab pribadi, perbedaan ini terlihat jelas saat kita membandingkan waktu verifikasi dan penggunaan memori. Artikel ini membahas kriteria praktis agar pilihan tidak berhenti pada nama algoritma yang terdengar aman.

Kata sandi adalah rahasia yang tidak boleh disimpan apa adanya. Bila basis data bocor, hash yang lemah bisa diuji jutaan kali per detik dengan perangkat keras modern. Karna itu, algoritma hash kata sandi perlu dirancang lambat, menggunakan salt unik, dan tahan terhadap serangan paralel. Tujuan pembelajaran di sini adalah memahami konsep dan pengaturan dasar, bukan menyerang akun milik orang lain.

Mengapa hash umum tidak cukup untuk kata sandi

Hash umum seperti SHA-256 dirancang cepat. Kecepatan itu bagus untuk checksum file, tetapi buruk untuk kata sandi karna penyerang bisa mencoba banyak kandidat dalam waktu singkat. Fungsi hash kata sandi sengaja dibuat lambat dan dapat diatur biayanya. Perbedaan utama bukan pada panjang output, melainkan pada biaya waktu, memori, dan paralelisme.

Salt juga membedakan penyimpanan yang baik dari yang berbahaya. Salt adalah nilai acak yang disimpan bersama hash, sehingga dua pengguna dengan kata sandi sama tidak menghasilkan hash yang sama. Tanpa salt, tabel pelangi dan pencocokan massal menjadi jauh lebih mudah. Di lab, kita bisa melihat bahwa salt tidak perlu dirahasiakan, tetapi harus unik dan cukup panjang.

Pepper adalah lapisan tambahan yang disimpan di luar basis data, misalnya di variabel lingkungan aplikasi. Pepper tidak menggantikan salt, tetapi menambah kesulitan jika hanya basis data yang bocor. Kombinasi salt dan pepper memberi pertahanan berlapis, meskipun pepper menambah kompleksitas operasional. Untuk pembelajar, penting memahami bahwa keamanan kata sandi adalah sistem, bukan satu fungsi tunggal.

Kriteria memilih algoritma yang aman

Kriteria pertama adalah tahan terhadap serangan offline. Algoritma yang baik memaksa penyerang menghabiskan waktu dan memori untuk setiap tebakan. Kriteria kedua adalah dapat dikonfigurasi. Ketika perangkat keras menjadi lebih cepat, parameter harus bisa dinaikkan tanpa mengganti seluruh skema. Kriteria ketiga adalah dukungan ekosistem, karna implementasi yang salah sering lebih berbahaya daripada algoritma yang kurang ideal.

Kriteria keempat adalah perilaku pada perangkat keras khusus. Beberapa fungsi memory-hard lebih sulit dipercepat dengan GPU atau ASIC. Ini bukan jaminan mutlak, tetapi menaikkan biaya serangan. Kriteria kelima adalah kemudahan audit. Pustaka yang dipakai luas dan teruji biasanya lebih aman daripada implementasi sendiri. Di Kali Linux Indonesia, diskusi lab biasanya menekankan pustaka standar dan dokumentasi resmi daripada eksperimen tanpa pengujian.

Jangan memilih algoritma hanya karena populer di tutorial lama. MD5 dan SHA-1 tidak dirancang untuk kata sandi dan tidak memiliki salt bawaan. SHA-256 dan SHA-512 juga bukan pilihan ideal untuk kata sandi jika digunakan langsung. Jika terpaksa memakai PBKDF2, gunakan iterasi tinggi dan salt yang benar, tetapi pahami bahwa PBKDF2 tidak memory-hard. Pilihan harus disesuaikan dengan ancaman, anggaran server, dan kebutuhan kompatibilitas.

Perbandingan algoritma populer

Argon2 adalah pemenang Password Hashing Competition pada 2015 dan sering direkomendasikan untuk penyimpanan kata sandi modern. Varian Argon2id menggabungkan ketahanan terhadap serangan side-channel dan serangan paralel. OWASP Password Storage Cheat Sheet memberi panduan parameter awal yang bisa dijadikan baseline, lalu dinaikkan sesuai kapasitas server. Di lab pribadi, mulai dari parameter konservatif dan ukur waktu verifikasi sebelum menerapkan ke sistem nyata.

Bcrypt sudah lama digunakan dan memiliki cost factor yang mudah dinaikkan. Kelemahannya, bcrypt membatasi input sampai 72 byte, sehingga kata sandi sangat panjang akan dipotong. Ini bukan masalah untuk kebanyakan pengguna, tetapi harus didokumentasikan. Scrypt juga memory-hard dan cocok untuk skenario yang ingin menaikkan biaya memori. PBKDF2 tetap relevan karena dukungan luas dan persetujuan standar, terutama di lingkungan yang sudah terikat pada NIST.

Pemilihan antara Argon2id, bcrypt, scrypt, dan PBKDF2 sebaiknya didasarkan pada dukungan platform dan kemampuan operasional. Jika aplikasi berjalan di lingkungan dengan memori terbatas, parameter Argon2 harus disesuaikan agar tidak menyebabkan denial of service. Jika sistem legacy hanya mendukung bcrypt, menaikkan cost factor secara bertahap bisa menjadi langkah realistis. Konsistensi dan pemantauan lebih penting daripada mengejar nama algoritma terbaru.

Parameter dan konfigurasi yang sering dilupakan

Salt harus dibuat dengan generator angka acak yang aman secara kriptografi, bukan fungsi acak biasa. Panjang salt minimal 16 byte, dan setiap kata sandi harus mendapat salt baru. Menyimpan salt bersama hash adalah praktik normal, tetapi format penyimpanan harus konsisten agar verifikasi tidak gagal. Kesalahan konfigurasi kecil seperti encoding yang berbeda bisa membuat seluruh sistem authentikasi bermasalah.

Cost factor atau parameter waktu harus diukur di server produksi, bukan di laptop pribadi. Target umum adalah waktu verifikasi sekitar 250 hingga 500 milidetik untuk satu kata sandi, tetapi angka ini harus disesuaikan dengan kebutuhan. Jika terlalu lambat, pengguna akan mengalami penundaan dan server bisa kelebihan beban. Jika terlalu cepat, keuntungan keamanan berkurang. Dokumentasikan hasil pengukuran dan jadwal peninjauan ulang.

Parameter memori dan paralelisme pada Argon2 juga harus diuji. Menambah memori dapat memperkuat pertahanan, tetapi juga meningkatkan risiko serangan denial of service jika endpoint login tidak dibatasi. Gunakan pembatasan laju, CAPTCHA bila perlu, dan monitring. Di CTF legal atau lab pribadi, kita bisa mengamati bagaimana perubahan parameter memengaruhi waktu respons tanpa menyerang sistem orang lain.

Kesalahan umum di lab dan CTF

Kesalahan pertama adalah mencampur hash kata sandi dengan hash data biasa. Fungsi untuk checksum tidak cocok untuk kredensial. Kesalahan kedua adalah menyimpan kata sandi dengan enkripsi yang dapat dibalik. Enkripsi dirancang untuk data yang perlu dibaca kembali, sedangkan kata sandi seharusnya diverifikasi, bukan didekripsi. Kesalahan ketiga adalah tidak merencanakan migrasi. Ketika algoritma lama terdeteksi, sistem harus bisa meningkatkan hash saat pengguna login berikutnya.

Kesalahan keempat adalah mengabaikan batas input. Pada bcrypt, kata sandi panjang dipotong,