# Seberapa sering harus ganti kata sandi: hanya kalau ada alasan

> Jawaban yang hampir tak pernah diberikan: jangan pernah menggantinya berdasarkan kalender. Gantilah ketika ada sesuatu yang terjadi. Ini daftar apa saja yang dihitung sebagai «sesuatu», dan apa yang dilakukan sisa waktunya — yaitu hampir sepanjang waktu.

2026-09-02 · David Carrero · password.es
Original: https://password.es/id/blog/seberapa-sering-harus-ganti-kata-sandi/

---

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](/id/blog/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 `X` bocor 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](/id/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](/id/) 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.*
