Bayangkan klien panik karena akun admin WordPress-nya diambil alih, padahal 2FA sudah aktif. Kode OTP ada, password kuat ada, plugin keamanan juga ada. Namun satu halaman login palsu yang rapi bisa cukup untuk mencuri sesi, token, atau backup code.
Passkeys lebih tahan phishing dibanding 2FA berbasis kode karena login terikat ke domain asli, bukan sekadar memasukkan angka. Namun, 2FA masih berguna sebagai lapisan transisi, terutama jika fallback, recovery, dan akses tim dikelola dengan disiplin.
Artikel ini membedah Passkeys vs 2FA WordPress dari sisi keamanan, kenyamanan, risiko fallback, dan keputusan praktis untuk site owner, admin, serta agency.
Passkeys vs 2FA WordPress: Bedanya di Mana?
2FA tradisional biasanya meminta password lalu kode tambahan. Kodenya bisa datang dari aplikasi authenticator, email, SMS, atau hardware token.
Passkeys berbeda. Teknologi ini memakai standar WebAuthn dan kriptografi public key. Jadi, perangkatmu menyimpan private key, sedangkan WordPress hanya memverifikasi public key.
Akibatnya, kamu nggak mengetik password atau kode yang bisa dicuri. Selain itu, passkey mengecek domain asli sebelum login berjalan.
Ringkasnya
- 2FA kode: lebih baik dari password saja, tetapi masih bisa dipancing lewat phishing.
- Passkeys: lebih tahan phishing karena kredensial terikat ke situs asli.
- Hardware security key: sangat kuat, tetapi butuh edukasi tim dan prosedur cadangan.
Kenapa 2FA Masih Bisa Gagal?
2FA sering gagal bukan karena konsepnya buruk. Masalahnya muncul saat implementasi terlalu percaya pada kode satu kali.
Misalnya, penyerang membuat halaman login palsu yang mirip wp-admin. Setelah kamu memasukkan password dan OTP, bot langsung meneruskan data itu ke situs asli. Karena itu, serangan real-time phishing tetap bisa menembus 2FA berbasis kode.
Selain itu, beberapa admin menyimpan backup code di email, Google Drive, atau chat internal. Praktis, tetapi berbahaya jika akun pendukung ikut bocor.
Kenapa Passkeys Lebih Tahan Phishing?
Passkeys tidak mengirim rahasia yang bisa disalin. Saat login, browser dan perangkatmu menandatangani tantangan kriptografi untuk domain tertentu.
Kalau domain palsu mencoba meminta autentikasi, passkey tidak cocok. Dengan begitu, situs tiruan tidak mendapat kode, password, atau token yang bisa dipakai ulang.
Google, Apple, Microsoft, dan FIDO Alliance mendorong pendekatan ini karena passkeys mengurangi ketergantungan pada password. Kamu bisa membaca referensi teknisnya di FIDO Alliance dan dokumentasi web.dev tentang passkeys.
Masalah yang Sering Dilupakan: Fallback Login
Di sinilah banyak site owner salah langkah. Mereka memasang passkeys, lalu merasa selesai. Padahal, jalur cadangan sering menjadi pintu paling lemah.
Kalau passkey kuat tetapi fallback masih password plus email recovery lemah, penyerang akan menyerang fallback. Jadi, ukuran keamananmu bukan teknologi terkuat, melainkan jalur termudah yang masih terbuka.
Pakai Kerangka “Strongest Door, Weakest Key”
Nilai semua jalur masuk admin sebagai pintu berbeda. Setelah itu, cari kunci terlemah.
- wp-admin login
- hosting panel
- email pemilik situs
- akun developer agency
- backup code
- akun Git, DNS, CDN, dan database
Kalau satu pintu memakai passkeys tetapi pintu lain masih password lama, risiko tetap tinggi. Karena itu, baca juga panduan internal tentang MFA enforcement untuk semua pintu WordPress dan risiko fallback passkeys di WordPress.
UX: Passkeys Lebih Nyaman, Tapi Perlu SOP
Untuk admin harian, passkeys terasa lebih cepat. Kamu cukup pakai Face ID, fingerprint, PIN perangkat, atau security key. Karena itu, login jadi lebih mulus dibanding membuka aplikasi authenticator lalu mengetik kode.
Namun, agency perlu aturan jelas. Misalnya, siapa yang boleh mendaftarkan passkey, perangkat apa yang disetujui, dan bagaimana akses dicabut saat staf resign.
Untuk tim kecil, mulai dari admin utama dulu. Setelah stabil, lanjutkan ke editor senior, developer, lalu akun klien yang punya akses sensitif.
Rekomendasi Praktis untuk Admin WordPress
Kalau kamu mengelola situs bisnis, portal konten, atau toko online, jangan pilih passkeys atau 2FA secara emosional. Pilih berdasarkan risiko dan kesiapan operasional.
- Admin utama: gunakan passkeys atau hardware security key.
- Akun agency: wajib MFA, idealnya passkeys dengan perangkat terdaftar.
- Editor biasa: minimal app-based 2FA, bukan SMS.
- Fallback: simpan backup code di password manager, bukan chat atau email.
- Recovery: dokumentasikan prosedur pemulihan sebelum passkeys diwajibkan.
Selain itu, matikan akun lama, batasi percobaan login, audit role user, dan pastikan plugin keamananmu kompatibel dengan WebAuthn. Untuk konteks risiko WordPress yang lebih luas, cek juga 7 lapis proteksi login WordPress.
Kapan 2FA Masih Masuk Akal?
2FA masih masuk akal jika timmu belum siap mengelola perangkat, recovery, dan offboarding. Namun, pilih TOTP via authenticator app, bukan SMS.
SMS rentan SIM swap, social engineering, dan intercept. Karena itu, jadikan SMS sebagai pilihan darurat terakhir, bukan standar keamanan admin.
Jika situsmu memproses transaksi, data pelanggan, atau akun membership, naikkan standar lebih cepat. Dalam kasus seperti itu, passkeys untuk admin bukan fitur mewah, melainkan kontrol risiko.
FAQ Passkeys vs 2FA WordPress
Apakah passkeys menggantikan 2FA sepenuhnya?
Bisa, jika plugin, perangkat, dan prosedur recovery sudah matang. Namun, banyak situs lebih aman memakai fase transisi: passkeys untuk admin utama, 2FA untuk role lain.
Apakah 2FA WordPress masih aman?
Masih, terutama TOTP app atau hardware token. Namun, 2FA berbasis kode tetap lebih mudah dipancing dibanding passkeys.
Apa risiko terbesar saat memakai passkeys?
Risiko terbesar biasanya fallback login yang lemah, bukan passkey itu sendiri. Karena itu, backup code, email recovery, dan akses hosting harus diamankan juga.
Kesimpulan: Jangan Cuma Tambah Faktor, Tutup Jalur Lemah
Dalam debat Passkeys vs 2FA WordPress, passkeys unggul untuk phishing resistance dan UX. Namun, 2FA tetap berguna sebagai jembatan, terutama untuk tim yang belum siap migrasi penuh.
Mulailah dari akun admin paling berisiko, rapikan fallback, lalu perluas ke seluruh ekosistem login. Kalau kamu mengelola banyak situs klien, jadikan ini checklist audit bulanan, bukan proyek sekali jalan.
