Kebijakan kata sandi seharusnya membuat akun lebih sulit diretas tanpa membuat perilaku aman menjadi tidak perlu rumit. Kebijakan terbaik bersifat jelas, praktis, dan selaras dengan cara orang benar-benar bekerja. Kebijakan ini mendorong kata sandi yang panjang dan unik, mendukung penggunaan pengelola kata sandi, mewajibkan autentikasi multi-faktor jika sesuai, serta menghilangkan aturan kuno yang memaksa pengguna berperilaku bisa ditebak.
\nArtikel ini menjelaskan yang boleh dan tidak boleh dalam kebijakan kata sandi modern, apa yang harus dihindari, praktik terbaik yang harus diikuti, serta template siap pakai yang dapat Anda sesuaikan untuk organisasi Anda.
\nKebijakan kata sandi adalah seperangkat aturan yang mendefinisikan bagaimana kata sandi dibuat, disimpan, digunakan, dibagikan, diubah, dan dilindungi. Ini berlaku untuk karyawan, kontraktor, administrator, akun layanan, dan terkadang pelanggan, tergantung sistem yang dibahas.
\nKebijakan kata sandi yang baik harus menjawab pertanyaan praktis berikut:
\nTujuannya bukan membuat aturan yang paling rumit. Tujuannya adalah mengurangi risiko nyata.
\nPanjang adalah salah satu pertahanan terkuat terhadap penebakan dan serangan brute-force. Satu aturan panjang minimum secara organisasi biasanya lebih mudah dipahami orang dan ditegakkan tim TI dibanding aturan terpisah untuk pengguna biasa, administrator, dan kasus khusus. Standar praktis adalah mewajibkan minimal 16 karakter untuk semua akun pengguna manusia. Makin panjang, makin baik, apalagi jika pengguna mengandalkan pengelola kata sandi atau frasa acak.
\nPengguna harus dapat membuat kata sandi yang jauh lebih panjang dari minimum. Hindari batas maksimum rendah seperti 16 atau 20 karakter. Panjang maksimum minimal 64 karakter adalah standar masuk akal, dan banyak sistem dapat mendukung lebih dari ini secara aman.
\nFrasa sandi (passphrase) boleh digunakan asal cukup panjang dan tidak didasarkan pada kutipan umum, lirik lagu, nama perusahaan, atau frasa yang mudah ditebak. Misalnya, passphrase dari beberapa kata acak biasanya lebih baik daripada kata sandi pendek dengan penggantian paksa.
\nSetiap akun harus punya kata sandi unik. Pengulangan kata sandi adalah alasan utama terjadinya pengambilalihan akun di layanan berbeda setelah satu kebocoran. Pengelola kata sandi membuat keunikan ini jadi praktis karena pengguna tak perlu mengingat semua kredensial.
\nKebijakan Anda harus secara eksplisit mengizinkan dan mendorong penggunaan pengelola kata sandi yang disetujui. Pengguna harus diperbolehkan menempel (paste) kata sandi ke formulir login, menggunakan autofill, dan membuat kata sandi acak. Pemblokiran fitur paste memang terasa melindungi, tapi justru sering menghambat penggunaan pengelola kata sandi secara benar.
\nKata sandi harus ditolak jika muncul dalam daftar kebocoran yang sudah diketahui, daftar kata sandi umum, atau daftar merah spesifik organisasi. Ini lebih berguna ketimbang memaksa pengguna memakai satu huruf besar, satu angka, dan satu simbol.
\nAutentikasi multi-faktor harus diaktifkan di mana pun secara teknis memungkinkan, terutama untuk administrator, akses jarak jauh, layanan cloud, email, pengelola kata sandi, sistem keuangan, dan sistem bernilai tinggi lain. MFA tidak menggantikan kata sandi kuat, tapi mengurangi dampak jika kredensial dicuri.
\nLebih utamakan MFA yang tahan phishing seperti passkey, kunci keamanan perangkat keras, atau authenticator perangkat. Authenticator berbasis aplikasi umumnya lebih baik daripada SMS. MFA berbasis SMS tidak boleh digunakan jika metode MFA lain secara teknis memungkinkan karena nomor telepon dapat disadap, SIM-swap, dialihkan, atau disalahgunakan lewat proses pemulihan akun.
\nIni bukan cuma teori. Pada 2018, Reddit mengungkap penyerang berhasil menyadap 2FA berbasis SMS dan mengakses sistem internal: https://www.reddit.com/r/announcements/comments/93qnm5/wehadasecurityincidenthereswhatyouneed_to/. Pada 2021, Coinbase melaporkan hacker mencuri uang pelanggan (aset kripto) setelah mengakali kredensial dan memanfaatkan kelemahan SMS recovery: https://www.reuters.com/technology/coinbase-says-hackers-stole-cryptocurrency-least-6000-customers-2021-10-01/.
\nKata sandi harus segera diganti jika ada bukti atau kecurigaan kompromi. Contohnya: pengguna kena phishing, perangkat kena malware, kredensial bocor dalam pelanggaran data, aktivitas login mencurigakan, atau pengungkapan tidak sengaja.
\nKata sandi bersama harus dihindari jika memungkinkan penggunaan akun pribadi. Jika tak terelakkan, kredensial bersama harus disimpan di pengelola kata sandi yang disetujui, akses dibatasi hanya untuk yang berwenang, dan proses berbagi dilog secara aman jika memungkinkan.
\nReset kata sandi sering jadi titik terlemah keamanan akun. Prosedur reset harus memverifikasi identitas, mengekspirasikan tautan reset dengan cepat, menggunakan token sekali pakai, dan memberi notifikasi bila terjadi pergantian kata sandi.
\nPenggantian kata sandi wajib setiap 30, 60, atau 90 hari sering membuat kata sandi jadi lemah. Pengguna akan membuat perubahan kecil dan mudah ditebak seperti menambah angka atau mengganti nama musim. Pedoman Identitas Digital NIST telah mencoret perubahan kata sandi berkala tanpa bukti kompromi (lihat bagian 3.1.1.2: https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver). Wajibkan penggantian kata sandi hanya jika ada kecurigaan kompromi, perubahan peran, pemulihan akun, atau kalau kata sandi sudah tidak sesuai kebijakan.
\nAturan seperti \"harus ada huruf besar, kecil, angka, dan simbol\" tidak menjamin kekuatan. Password1! memenuhi banyak aturan kompleksitas tapi tetap lemah. Utamakan panjang, keunikan, keacakan, dan pengecekan terhadap kebocoran.
Memblokir paste membuat pengelola kata sandi sulit digunakan. Ini mendorong pengguna memilih kata sandi pendek yang mudah diketik. Izinkan paste dan autofill kecuali ada alasan keamanan khusus yang terdokumentasi.
\nPetunjuk/hint kata sandi sering membocorkan terlalu banyak. Jika pengguna bisa menebak jawabannya dari hint, penyerang pun bisa. Gunakan prosedur reset yang aman.
\nSistem tidak pernah boleh menyimpan kata sandi dalam bentuk teks biasa atau enkripsi yang dapat dibalik. Kata sandi harus di-hash dengan algoritma kuat dan lambat serta memakai salt, seperti Argon2id, bcrypt, scrypt, atau PBKDF2, sesuai kebutuhan sistem dan regulasi.
\nHash fungsi umum dan cepat seperti MD5, SHA-1, SHA-256, atau SHA-512 tidak cocok sebagai algoritma hash kata sandi utama. Algoritma ini terlalu cepat, sehingga serangan brute-force ofline pasca kebocoran database jadi lebih mudah. Baca lebih lanjut di artikel kami tentang evolusi password hashing.
\nKata sandi tidak boleh dikirim lewat email, chat, tiket dukungan, dokumen, atau screenshot. Gunakan pengelola kata sandi dengan fitur berbagi dan kontrol akses yang aman.
\nKata sandi tidak boleh mengandung nama, tanggal lahir, nama perusahaan, pola keyboard, karakter berulang, atau penggantian umum seperti @ untuk a dan 0 untuk o. Pola-pola ini biasanya dicoba lebih dulu oleh peretas.
Gunakan aturan yang mudah dipahami:
\nAkun administrator, layanan, dan akses produksi butuh kontrol lebih ketat. Wajibkan kata sandi lebih kuat, MFA, akses terbatas, pemantauan, dan rotasi segera setelah ada perubahan akses.
\nKata sandi kuat tidak bisa memperbaiki kelemahan jika hak akses pengguna terlalu luas. Pengguna hanya boleh mengakses sistem dan rahasia sesuai perannya.
\nDeteksi pola login aneh, perjalanan tak mungkin, percobaan gagal berulang, login dari negara baru, dan akses di luar jam kerja normal. Kebijakan kata sandi mesti didukung dengan pemantauan dan respons insiden.
\nPelatihan harus fokus pada bahaya penggunaan ulang kata sandi, phishing, halaman login palsu, fatigue MFA, berbagi kata sandi aman, dan cara melaporkan kompromi. Jangan menyalahkan pengguna. Buat perilaku aman jadi mudah.
\nKebijakan kata sandi harus mudah dipahami. Jika terlalu panjang, kabur, atau terlalu ketat, orang akan mencari celahnya. Kebijakan terbaik adalah yang benar-benar bisa diterapkan dan diikuti.
\nGunakan template di bawah ini sebagai titik awal. Sesuaikan bagian dalam kurung agar sesuai organisasi, sistem, tingkat risiko, dan syarat hukum Anda.
\nKebijakan Kata Sandi\n\nVersi: [1.0]\nPemilik: [Departemen Keamanan / TI]\nTanggal berlaku: [YYYY-MM-DD]\nSiklus tinjauan: [Setiap 12 bulan]\n\n1. Tujuan\n\nKebijakan ini mendefinisikan persyaratan pembuatan, penggunaan, penyimpanan, berbagi, dan perubahan kata sandi untuk [Nama Organisasi]. Tujuannya adalah mengurangi risiko akses tidak sah, pencurian kredensial, pengambilalihan akun, dan kehilangan data.\n\n2. Cakupan\n\nKebijakan ini berlaku untuk seluruh karyawan, kontraktor, staf sementara, penyedia layanan, dan setiap pengguna yang mengakses sistem, aplikasi, jaringan, layanan cloud, atau data [Nama Organisasi].\n\nKebijakan ini berlaku untuk akun pengguna standar, akun istimewa, akun layanan, akun bersama, dan sistem lain di mana kata sandi digunakan untuk autentikasi.\n\n3. Persyaratan pembuatan kata sandi\n\nSemua kata sandi harus memenuhi syarat berikut:\n\n- Akun pengguna manusia wajib menggunakan kata sandi minimal 16 karakter.\n- Kata sandi harus unik dan tidak boleh digunakan ulang pada akun kerja maupun pribadi lainnya.\n- Kata sandi tidak boleh memuat nama, nama pengguna, nama perusahaan, tanggal lahir, pola keyboard, karakter berulang, atau informasi yang mudah ditebak lainnya.\n- Kata sandi tidak boleh berbasis frasa umum, kutipan, lirik lagu, atau penggantian yang mudah ditebak.\n- Kata sandi tidak boleh muncul di daftar kebocoran kata sandi maupun daftar kata sandi umum.\n- Kata sandi boleh memuat spasi, simbol, angka, huruf kapital, dan huruf kecil.\n- Passphrase (frasa sandi) diperbolehkan jika panjang, unik, dan tidak berbasis frasa publik atau mudah ditebak.\n\n4. Pengelola kata sandi\n\n[Nama Organisasi] mewajibkan atau sangat menganjurkan penggunaan pengelola kata sandi yang disetujui untuk membuat, menyimpan, dan berbagi kata sandi.\n\nPengguna boleh menggunakan fitur generator, autofill, dan copy-paste dari pengelola yang disetujui. Pengguna tidak boleh menyimpan kata sandi di browser, spreadsheet, dokumen, aplikasi catatan, email, chat, screenshot, atau alat tidak sah lain.\n\n5. Autentikasi multi-faktor\n\nMFA harus diaktifkan di mana pun memungkinkan secara teknis, termasuk namun tidak terbatas pada:\n\n- Akun email\n- Sistem akses jarak jauh\n- Akun pengelola kata sandi\n- Layanan cloud\n- Akun administrator\n- Sistem keuangan, SDM, dan lainnya yang berisiko tinggi\n- Sistem apa pun yang diklasifikasikan sebagai [rahasia/kritikal]\n\nJika tersedia, pengguna wajib memakai MFA tahan phishing seperti passkey, kunci keamanan perangkat keras, atau authenticator perangkat. Aplikasi authenticator lebih disarankan daripada SMS. MFA berbasis SMS dilarang bila ada opsi MFA lain yang lebih kuat secara teknis dan hanya boleh digunakan jika tidak ada opsi MFA lain yang tersedia.\n\n6. Perubahan kata sandi\n\nKata sandi harus segera diganti apabila:\n\n- Kata sandi diketahui atau dicurigai telah dikompromikan.\n- Pengguna memasukkan kata sandi ke situs phishing.\n- Kata sandi dibagikan ke orang tidak berwenang.\n- Ditemukan malware atau akses tidak sah pada perangkat pengguna.\n- Kata sandi muncul dalam insiden kebocoran data.\n- Perubahan peran akun istimewa atau status kepegawaian.\n- TI atau Keamanan memerintahkan penggantian kata sandi.\n\nPenggantian kata sandi rutin tidak diwajibkan kecuali dimandatkan oleh hukum, regulasi, kontrak, atau keterbatasan sistem. Perubahan kata sandi tidak boleh hanya dengan perubahan kecil yang mudah ditebak dari kata sandi sebelumnya.\n\n7. Pembagian kata sandi\n\nKata sandi tidak boleh dibagikan melalui email, chat, tiket, dokumen, screenshot, telepon, maupun percakapan lisan.\n\nKredensial bersama hanya boleh digunakan jika akun pribadi tidak memungkinkan secara teknis atau dengan persetujuan [Keamanan / TI]. Kredensial bersama yang disetujui wajib disimpan dan dibagikan melalui pengelola kata sandi yang disetujui, dengan akses hanya untuk pengguna yang berwenang.\n\n8. Akun istimewa\n\nAkun istimewa harus menggunakan kata sandi unik yang tidak digunakan pada akun pengguna standar mana pun. Akun istimewa wajib memakai MFA di mana pun secara teknis memungkinkan dan harus ditinjau secara berkala.\n\nKata sandi akun istimewa harus diganti bila administrator keluar dari organisasi, pindah peran, tidak lagi butuh akses, atau ada dugaan kompromi.\n\n9. Akun layanan dan rahasia aplikasi\n\nKata sandi akun layanan, API key, token, dan rahasia aplikasi harus disimpan pada sistem pengelolaan rahasia atau pengelola kata sandi yang disetujui.\n\nKredensial akun layanan tidak boleh disisipkan pada kode sumber, file konfigurasi, gambar, dokumentasi, atau skrip kecuali dilindungi lewat proses manajemen rahasia yang disetujui.\n\n10. Reset kata sandi dan pemulihan akun\n\nProses reset kata sandi harus memverifikasi identitas pengguna sebelum akses dipulihkan. Tautan reset dan kata sandi sementara wajib sekali pakai, cepat kedaluwarsa, dan dikirim via jalur yang sah.\n\nPengguna harus diberi notifikasi setiap kali kata sandinya diubah atau direset. Kata sandi sementara harus diganti saat login pertama.\n\n11. Kontrol teknis\n\nSistem yang menyimpan atau memproses kata sandi harus:\n\n- Tidak pernah menyimpan kata sandi dalam teks biasa.\n- Melakukan hash kata sandi menggunakan algoritma hash salted modern yang disetujui: PBKDF2, scrypt, bcrypt, atau Argon2.\n- Tidak menggunakan MD5, SHA-1, SHA-256, SHA-512, atau hash cepat umum lain sebagai algoritma hash kata sandi utama.\n- Melindungi endpoint autentikasi dengan rate limiting atau kontrol setara.\n- Menolak kata sandi yang umum, lemah, dan sudah diketahui dikompromikan.\n- Mengizinkan pengguna menempel (paste) kata sandi dari pengelola kata sandi.\n- Mendukung panjang kata sandi yang wajar, setidaknya 64 karakter jika memungkinkan.\n- Mencatat log peristiwa autentikasi penting terkait keamanan.\n\n12. Pelaporan dugaan kompromi\n\nPengguna wajib melaporkan dugaan kompromi kata sandi, phishing, prompt login mencurigakan, prompt MFA yang tidak mereka lakukan, atau pengungkapan kata sandi tak sengaja ke [kontak Keamanan / TI] segera.\n\n13. Pengecualian\n\nPengecualian kebijakan ini harus didokumentasikan, dinilai risikonya, dibatasi waktunya, dan disetujui oleh [pimpinan Keamanan/TI]. Kontrol kompensasi wajib diterapkan jika memungkinkan.\n\n14. Penegakan\n\nKegagalan mematuhi kebijakan ini dapat mengakibatkan pencabutan akses, pelatihan keamanan wajib, sanksi disiplin, atau langkah lain sesuai kebijakan [Nama Organisasi] dan hukum berlaku.\n\n15. Tinjauan\n\nKebijakan ini harus ditinjau minimal setahun sekali atau setelah perubahan besar pada sistem, ancaman, regulasi, atau aktivitas bisnis.\nKebijakan kata sandi yang kuat bukan soal membuat aturan menyulitkan. Intinya adalah menghilangkan kebiasaan lemah, mendukung pengelola kata sandi, menggunakan MFA, dan merespons cepat saat kredensial terekspos. Jaga kebijakan tetap praktis, dapat ditegakkan, dan fokus pada serangan nyata seperti phishing, credential stuffing, penggunaan ulang kata sandi, serta akun yang diretas.
","frontmatter":{"date":"May 07, 2026","slug":"password-policy-dos-donts-best-practices","title":"Kebijakan Kata Sandi: Yang Harus dan Tidak, Praktik Terbaik, dan Template Siap Pakai","description":"Pelajari apa saja yang seharusnya diminta oleh kebijakan kata sandi modern, aturan kuno yang harus dihindari, serta salin template praktis untuk organisasi Anda.","author":"Sascha Pfeiffer","featuredImage":null}}},"pageContext":{"slug":"password-policy-dos-donts-best-practices","lang":"id","langPathPrefix":"/id"}},"staticQueryHashes":["2149092236","3128451518","3192060438"]}