Panduan Menyusun Kebijakan Kata Sandi Organisasi bersama Kali Linux Indonesia

Catatan lab ini berawal dari obrolan di komunitas Kali Linux Indonesia soal kebijakan kata sandi organisasi yang kerap dibikin terlalu rumit bangeet. Tidak sedikit admin mewajibkan 12 karakter campur huruf besar, angka, dan simbol, lalu memaksa penggantian tiap 30 hari. Beban semacam itu sering bikin pengguna menulis kata sandi di sticky note atau menambah angka 1 di belakang kata sandi lama. Saya menulis panduan ini setelah menguji beberapa hash akun demo di lab pribadi pakai alat bawaan Kali Linux. Tujuannya bukan membobol sistem orang lain, tapi melihat seberapa cepat kebijakan yang buruk bisa ditembus di lingkungan terisolasi.

Mengapa Kebijakan Kata Sandi Perlu Diuji, Bukan Sekadar Ditulis

Kebijakan kata sandi yang cuma berupa dokumen sering tidak menyentuh kenyataan. Standar NIST SP 800-63B , yang terbit 2017 dan diperbarui 2020, menyarankan panjang minimal 8 karakter, maksimal 64 karakter, tanpa kewajiban penggantian berkala kecuali ada bukti kompromi. Rekomendasi ini beda jauh dari praktik lama yang memaksa penggantian tiap 30 hari. Alasan NIST sederhana, pengguna yang dipaksa sering memilih pola yang gampang ditebak. Uji di lab dengan hashcat memperlihatkan kata sandi acak 8 karakter dengan simbol bisa lebih cepat retak dalam sebntar doang daripada frasa sandi 4 kata yang panjangnya 20 karakter, selama frasa itu tidak ada di wordlist umum. Karena itu uji langsung penting.

Komponen Kebijakan Kata Sandi yang Masuk Akal

Untuk organisasi kecil atau tim lab, kebijakan tidak perlu ratusan halaman. Cukup empat hal. Pertama, panjang minimum 12 karakter untuk akun biasa dan 16 untuk admin. Kedua, izinkan frasa sandi, bukan paksaan karakter khusus. Frasa seperti “kuda-biru-makan-rendang” lebih mudah diingat dan punya entropi tinggi. Ketiga, aktifkan MFA untuk semua akun penting, ngga bisa ditawar. MFA menutup celah walau kata sandi bocor. Keempat, periksa kata sandi terhadap daftar bocor publik, misalnya lewat API haveibeenpwned atau alat lokal. Jangan mewajibkan penggantian berkala tanpa alasan. Penggantian hanya perlu setelah insiden atau ada kecurigaan kompromi.

Validasi dengan Hashcat di Lab Terisolasi

Setelah kebijakan ditulis, uji efektivitasnya. Di Kali Linux, saya biasanya menyiapkan beberapa akun demo dengan kata sandi yang mewakili kebijakan lama dan baru. Lalu saya ekstrak hash dari /etc/shadow pada mesin virtual sendiri. Setelah itu hashcat mode 1800 untuk SHA-512 crypt dijalankan dengan wordlist rockyou.txt dan aturan sederhana. Hasilnya sering mengejutkan: kata sandi 8 karakter yang memenuhi kompleksitas sering muncul dalam hitungan menit, sementara frasa 4 kata acak tidak muncul sama sekali dalam sesi 30 menit. Tentu ini bukan pengukuran mutlak, kecepatan bergantung GPU dan wordlist. Yang penting proses