Passkey bisa menutup pintu phishing, tapi bisa juga membuka celah baru kalau tim security nggak melihat siapa yang menambah authenticator, kapan dihapus, dan kenapa recovery dipakai. Untuk managed WordPress provider, masalahnya bukan cuma login berhasil atau gagal. Masalah besarnya adalah perubahan akses yang terlihat “normal”, padahal bisa jadi awal takeover akun.
Kenapa Passkey Tetap Butuh Audit Log?
Passkey memang kuat karena memakai WebAuthn dan kriptografi public key. Namun, keamanan login tidak berhenti saat user berhasil masuk. Justru, momen paling sensitif sering terjadi saat user menambah authenticator baru, menghapus device lama, atau memakai recovery flow.
Tanpa audit log, kamu hanya tahu hasil akhirnya: akun masih bisa login. Namun, kamu nggak tahu apakah admin baru saja menambahkan security key pribadi, apakah helpdesk menghapus passkey tanpa verifikasi kuat, atau apakah recovery dipakai berulang dari lokasi aneh.
Event yang Wajib Dicatat Saat Registration dan Removal
Untuk audit logging passkey yang serius, jangan cuma simpan “passkey added” atau “passkey removed”. Event seperti itu terlalu miskin konteks. Karena itu, setiap perubahan authenticator harus membawa detail yang bisa dipakai untuk investigasi.
1. Saat Passkey Ditambahkan
- User ID, role, email, dan tenant/site ID.
- Credential ID yang sudah di-hash, bukan disimpan mentah.
- Authenticator type, misalnya platform authenticator atau roaming security key.
- IP address, user agent, ASN, country, dan device fingerprint.
- Apakah user login normal, SSO, atau recovery sebelum registrasi.
- Actor yang memicu perubahan, user sendiri, admin, atau helpdesk.
2. Saat Passkey Dihapus
- Siapa yang menghapus, pemilik akun atau admin lain.
- Passkey mana yang dihapus, dengan label device dan credential hash.
- Apakah masih ada passkey lain tersisa.
- Alasan removal, misalnya device hilang, rotasi hardware, offboarding, atau recovery.
- Apakah ada approval tambahan untuk akun privileged.
Framework “Trust Delta”: Cara Membaca Risiko Authenticator
Banyak tim melihat audit log sebagai arsip. Padahal, untuk passkey, audit log harus dibaca sebagai perubahan tingkat trust. Setiap add atau remove authenticator mengubah siapa yang bisa masuk ke akun, jadi nilainya mirip perubahan permission.
Pakai framework sederhana: Trust Delta = Actor + Context + Direction + Blast Radius. Actor menjawab siapa yang melakukan. Context menjawab dari mana dan lewat flow apa. Direction menjawab trust bertambah atau berkurang. Blast radius menjawab dampaknya ke admin, billing, deployment, atau data customer.
Contohnya, editor menambah passkey dari laptop kantor saat login normal mungkin risiko rendah. Namun, super admin menambah roaming key setelah recovery dari IP baru harus memicu review. Selain itu, penghapusan passkey terakhir milik admin harus dianggap hampir setara dengan reset kredensial.
Sinyal Suspicious yang Perlu Alert Otomatis
Audit logging for passkey registration/removal baru terasa kuat kalau log berubah jadi alert yang bisa ditindak. Jadi, jangan tunggu laporan user. Buat rule yang menangkap pola kecil sebelum jadi takeover.
- Authenticator baru setelah recovery: terutama untuk admin, owner, atau developer.
- Removal massal: banyak passkey dihapus dalam waktu pendek.
- Perubahan dari lokasi baru: negara, ASN, atau VPN hosting yang belum pernah terlihat.
- Last passkey removed: akun kembali bergantung ke fallback yang lebih lemah.
- Helpdesk terlalu sering override: bisa menandakan social engineering atau SOP recovery lemah.
- Device label diganti lalu dihapus: sering menyulitkan investigasi setelah kompromi.
Desain Log yang Aman untuk WordPress Provider
Kalau kamu mengelola banyak situs WordPress, audit log harus multi-tenant, tahan manipulasi, dan mudah diekspor. Selain itu, log harus cocok untuk kebutuhan pelanggan enterprise yang sering meminta bukti kontrol akses.
Minimal, gunakan format event yang konsisten. Misalnya passkey.registered, passkey.removed, passkey.recovery_used, dan passkey.recovery_denied. Setelah itu, kirim event penting ke SIEM, webhook security, atau storage append-only.
Untuk referensi teknis, kamu bisa cek dokumentasi W3C WebAuthn, panduan FIDO Alliance tentang passkeys, dan praktik kontrol akses dari OWASP.
Recovery Abuse: Blind Spot yang Sering Diremehkan
Recovery flow sering jadi jalur paling lemah. Karena itu, event recovery harus punya status sendiri, bukan dicampur dengan login biasa. Jika recovery berhasil lalu passkey baru langsung ditambahkan, sistem harus memberi label risiko tinggi.
Untuk akun privileged, pakai approval dua pihak. Misalnya, helpdesk boleh memulai recovery, tetapi security lead harus menyetujui sebelum passkey lama dihapus. Dengan begitu, social engineering jadi lebih sulit.
Checklist Implementasi Cepat
- Catat semua registration, removal, rename, recovery, dan denial.
- Simpan credential ID dalam bentuk hash.
- Tambahkan risk score untuk role sensitif.
- Kirim alert saat last passkey removed atau recovery diikuti registration.
- Batasi retention sesuai regulasi, tetapi jangan terlalu pendek.
- Link-kan event dengan session, IP, user agent, dan actor.
- Review berkala akun admin, owner, developer, dan support.
Kalau kamu sedang memilih plugin WebAuthn, baca juga checklist memilih plugin WebAuthn. Jika fokusmu rollout, lanjutkan ke panduan rollout passkey WordPress tanpa bikin admin terkunci.
FAQ
Apa itu audit logging for passkey registration/removal?
Ini adalah pencatatan detail saat passkey atau authenticator ditambahkan, dihapus, atau dipulihkan. Tujuannya membantu tim security mendeteksi perubahan akses yang mencurigakan.
Apakah passkey masih bisa disalahgunakan?
Passkey sangat tahan phishing, tetapi recovery flow, device hilang, dan admin override tetap bisa jadi celah. Karena itu, audit log tetap wajib.
Event apa yang paling penting untuk di-alert?
Prioritaskan authenticator baru setelah recovery, penghapusan passkey terakhir, removal massal, dan perubahan dari lokasi atau ASN baru.
Kesimpulan
Passkey membuat login jauh lebih kuat, tetapi tanpa audit logging, tim security tetap berjalan dalam gelap. Catat setiap registration, removal, dan recovery sebagai perubahan trust, lalu ubah log menjadi alert yang bisa ditindak.
Mau dapat checklist keamanan WordPress dan passkey berikutnya langsung di inbox? Subscribe newsletter Google kami di bawah ini.
