Mari mulai dari akhirnya, karena jawabannya pendek dan hampir tidak ada yang memberikannya utuh: kalau ada alasan. Bukan tiap sembilan puluh hari.
Kebiasaan mengganti kata sandi menurut kalender begitu mendarah daging sampai terasa seperti kebersihan, seperti menyikat gigi. Padahal itu anjuran dengan tanggal kedaluwarsa, dan tanggalnya sudah lewat: NIST Amerika menulisnya pada 2003, mencabutnya pada 2017, dan penulis dokumen itu meminta maaf di depan umum pada tahun yang sama. Kisah itu kami ceritakan lengkap di apa itu kata sandi; di sini yang penting adalah hal lain, yang hampir tak pernah dijelaskan: apa yang kamu lakukan, hari ini, dengan kata sandimu.
Kalender tidak tahu apakah ada yang dicuri darimu
Masalah mengganti berdasarkan tanggal adalah bahwa tanggal tidak membawa informasi apa pun.
Kalau seseorang mendapatkan kata sandimu pada suatu Selasa di bulan Februari, menggantinya pada 1 April karena memang jadwalnya berarti memberi dia hadiah satu setengah bulan akses. Dan kalau tidak ada yang menyentuhnya, menggantinya tidak melindungimu dari apa pun: kamu menukar kata sandi yang bagus dengan yang kemungkinan besar lebih buruk, karena kata sandi yang ditulis karena kewajiban ditulis dengan malas.
Di situlah seluruh mekanisme kegagalannya. Rotasi paksa tidak menghasilkan kata
sandi baru, ia menghasilkan variasi. Musim2026! menjadi Panas2026! lalu
Hujan2026!, dan penyerangmu tahu itu, karena deret tersebut sama mudah
ditebaknya dengan kalender dinding asalnya. Sistem merasa puas — kata sandinya
«sudah berubah» — dan keamanan yang sebenarnya turun, bukan naik.
Karena itu NIST, dalam SP 800-63B, mengatakan dua hal sekaligus: jangan mengganti secara sembarang menurut waktu, dan paksakan penggantian begitu ada indikasi kebocoran. Bukan berarti mengganti itu tidak penting. Yang penting, pemicunya harus berupa fakta, bukan tanggal.
Alasan yang benar-benar dihitung
Ini daftarnya. Kalau salah satu dari hal berikut terjadi padamu, kata sandi diganti hari ini, bukan bulan depan:
- Muncul dalam kebocoran data. Dari layanan itu, atau dari layanan lain mana pun tempat kamu memakai kata sandi yang sama.
- Kamu memakainya ulang. Kalau
Xbocor dan kamu pasang juga di empat situs lain, ada lima kata sandi yang harus diganti, bukan satu. - Kamu mengetiknya di situs yang ternyata bukan situs itu. Sebuah surel yang terburu-buru, sebuah tautan, sebuah formulir yang mirip. Tidak penting kamu sadar dua detik kemudian: kamu sudah mengirimkannya.
- Kamu membagikannya. Ke pasangan, ke rekan kerja, di obrolan kantor, di secarik kertas. Kata sandi yang pernah melewati saluran tempat kamu tidak mengendalikan siapa yang membaca sudah bukan milikmu lagi.
- Kamu melihat aktivitas aneh. Masuk dari tempat yang tak pernah kamu datangi, surel penyetelan ulang yang tidak kamu minta, pesan terkirim yang tidak kamu tulis.
- Perangkatnya pernah disusupi. Komputer dengan perangkat perusak, ponsel hilang, laptop yang mampir ke tempat servis yang tidak kamu kenal.
- Layanannya memperingatkanmu. Ketika sebuah perusahaan mengirim surel itu, tanggapi hari itu juga. Itu betul-betul kasus yang dimaksud SP 800-63B.
- Sebuah kehidupan bersama berakhir. Mantan pasangan, rumah bersama, rekan usaha. Akun yang tadinya milik berdua dan sekarang milik satu orang.
Perhatikan kesamaannya: semuanya adalah kejadian. Tidak ada satu pun yang berbunyi «sudah lewat sembilan puluh hari».
Untuk yang pertama ada alatnya. Kalau ingin tahu apakah sebuah kata sandi tertentu ada di daftar yang sudah beredar, sekalian berapa lama ia bertahan, jalankan lewat pemeriksa: ia dianalisis di peramban kamu dan tidak keluar dari sana.
Kalau ada alasan, urutannya penting
Mengganti kata sandi adalah langkah yang jelas, dan sering kali bukan langkah pertama. Ini urutan yang menghindarkanmu mengerjakan hal yang sama dua kali:
Pertama, perangkatnya. Kalau kamu curiga ada sesuatu terpasang yang membaca apa yang kamu ketik, mengganti kata sandi dari mesin yang sama sama saja dengan menyerahkan yang baru. Bersihkan dulu, atau pakai perangkat lain.
Lalu, surelnya. Akun surelmu bukan akun biasa: ia yang menerima tautan «lupa kata sandi» dari semua akun lain. Siapa yang menguasai surel menguasai sisanya lewat pintu depan. Kalau ada satu kata sandi untuk dimulai, itulah dia.
Berikutnya, tutup sesi yang terbuka. Mengganti kata sandi tidak selalu mengusir orang yang sudah ada di dalam. Cari di pengaturan akun opsi untuk keluar dari semua perangkat dan pakai: kalau tidak, penyusup tetap terhubung lewat sesi yang sama sekali tidak lagi membutuhkan kata sandimu.
Dan terakhir, periksa apa yang dia tinggalkan. Ini langkah yang paling banyak dilewati orang. Yang masuk ke sebuah akun tidak sekadar melihat: dia mengubah alamat pemulihan, menambahkan nomor telepon, menyalakan faktor kedua miliknya sendiri, menghubungkan sebuah aplikasi, memasang aturan penerusan di kotak surat. Kalau kamu mengganti kata sandi tanpa memeriksa itu, besok dia masuk lagi lewat pintu yang masih terbuka lebar. Tinjau metode pemulihan, perangkat yang diizinkan, aplikasi yang terhubung, dan aturan penerusan.
Satu hal lagi, jelas dan justru karena itu paling sering diabaikan: ketika mengganti, yang baru harus benar-benar baru. Bukan yang biasa dengan angka lain. Buat di generator dan simpan di tempat yang tidak bergantung pada ingatanmu.
Apa yang kamu lakukan pada tiga ratus enam puluh hari lainnya
Kalau pemicunya adalah fakta dan fakta itu jarang, pertanyaannya jadi lain: berarti tidak ada yang perlu dilakukan? Sebaliknya. Apa yang coba diselesaikan rotasi dengan buruk diselesaikan dengan baik oleh empat hal, dan semuanya cukup sekali.
Buat panjang. SP 800-63B menaruh panjang di depan kerumitan: kata sandi panjang lebih berharga daripada yang pendek penuh simbol. Di situ letak sebagian besar pekerjaannya.
Buat berbeda di setiap situs. Inilah yang mengubah kebocoran milik orang lain menjadi insiden kecil, bukan kebakaran. Kalau tiap akun punya miliknya sendiri, bocornya satu tidak menyentuh yang lain; kalau kamu berbagi kata sandi, sebuah layanan yang kamu sendiri tak ingat pernah pakai menentukan keamanan bankmu.
Cocokkan dengan daftar kata sandi bocor. Itulah pertukaran persis yang dilakukan NIST: alih-alih menuntut simbol, memeriksa bahwa kata sandimu belum beredar. Pemeriksaan itu memang kedaluwarsa — kata sandi yang hari ini tidak ada di daftar bisa ada tahun depan — dan karena itu pengelola yang baik mengulanginya sendiri dan memberitahumu.
Nyalakan faktor kedua di mana pun bisa. Dengan faktor kedua terpasang, kata sandi yang dicuri berhenti menjadi kunci dan menjadi setengah kunci.
Keempatnya bersama melakukan sesuatu yang tak pernah dilakukan rotasi: mereka mengganti kata sandi tepat ketika ada alasan, karena kamu jadi tahu bahwa alasannya ada. Pengelola yang mengawasi daftar adalah sistem peringatan; kalender tidak memperingatkan apa pun, ia hanya berlalu.
Dan kalau kantormu mewajibkannya tiap sembilan puluh hari
Ini terjadi, dan sering, karena ada kebijakan yang ditulis lima belas tahun lalu dan sejak itu tidak pernah dibuka lagi. Dua hal.
Pertama, praktis: kalau kamu harus menggantinya, ganti sungguhan. Buat satu yang benar-benar baru dan simpan di pengelola. Variasi musiman adalah satu-satunya hal yang lebih buruk daripada tidak mengganti, karena ia memberi perasaan sudah melakukan sesuatu.
Kedua, bagi yang bisa menggeser kebijakan: argumennya tidak perlu dikarang. Ada di SP 800-63B, itu panduan resmi NIST, dan di situ tertulis jelas bahwa penggantian kata sandi secara berkala tidak boleh diwajibkan, dan bahwa penggantian harus dipaksakan ketika ada indikasi kebocoran. Siapa pun yang hari ini mempertahankan aturan sembilan puluh hari sedang mengikuti dokumen yang sudah diganti bertahun-tahun lalu oleh lembaga yang menerbitkannya sendiri.
Jawaban pendeknya, sekali lagi
Seberapa sering harus ganti kata sandi? Ketika ada sesuatu yang terjadi.
Dan karena «ketika ada sesuatu yang terjadi» hanya berfungsi kalau kamu tahu bahwa itu terjadi, jawaban panjangnya: pastikan setiap kata sandi panjang, berbeda, dan diawasi — sehingga pada hari salah satunya harus diganti kamu akan tahu, hanya ada satu, dan cuma perlu dua menit.
Sisanya hanyalah mencentang kotak di kalender supaya merasa aman.
Sumber: NIST SP 800-63, «Electronic Authentication Guideline» (2003), tempat aturan komposisi dan penggantian berkala muncul · NIST SP 800-63B, «Digital Identity Guidelines: Authentication and Lifecycle Management» (2017): panjang di atas kerumitan, tanpa penggantian berkala yang sembarang, penggantian yang dipaksakan saat ada indikasi kebocoran, dan pencocokan dengan daftar kata sandi yang telah bocor · pernyataan Bill Burr, penulis panduan 2003, kepada Wall Street Journal pada Agustus 2017.
Foto oleh Hatice Baran · Pexels