Passkey Aktif, Login WordPress Masih Bisa Dihajar Bot

Passkey bikin phishing jauh lebih susah, tetapi bot brute-force masih bisa membakar endpoint login-mu setiap menit. Masalahnya bukan cuma password yang ditebak. Masalahnya adalah permukaan serangan yang masih terbuka: /wp-login.php, XML-RPC, REST auth flow, halaman recovery, dan fallback CAPTCHA yang salah desain.

Kenapa Passkey Belum Cukup untuk Mengamankan Login WordPress?

Passkey menyelesaikan masalah besar: password reuse, phishing, dan credential stuffing klasik. Namun, setelah itu, penyerang biasanya pindah target. Mereka menyerang endpoint, bukan lagi password.

Akibatnya, server tetap menerima ribuan request login gagal, request XML-RPC, probing user enumeration, dan percobaan recovery akun. Jadi, fokusmu harus bergeser dari “membuat password aman” ke “membuat endpoint login mahal untuk diserang”.

Framework 3R: Reduce, Route, Respond

Pakai framework sederhana ini untuk audit cepat:

• Reduce: kurangi jalur login yang nggak perlu, terutama XML-RPC jika tidak dipakai.
• Route: arahkan user berisiko rendah ke passkey tanpa friksi, lalu tambahkan challenge hanya saat sinyal risiko naik.
• Respond: log, alert, dan blokir pola abuse sebelum server ikut ngos-ngosan.

Bagian yang sering keliru: banyak admin menaruh CAPTCHA di depan semua orang. Padahal, setelah passkey aktif, CAPTCHA global justru menambah friksi tanpa banyak nilai keamanan. Lebih aman, CAPTCHA muncul hanya saat risiko naik.

Rate Limit yang Benar Setelah Passkey Adoption

Login endpoint hardening harus mulai dari rate limit. Namun, jangan hanya membatasi per IP. Bot modern memakai residential proxy, rotasi ASN, dan pola request lambat agar terlihat normal.

Gunakan Multi-Key Rate Limit

Buat beberapa bucket limit sekaligus:

• Per IP: contoh 10 attempt per 10 menit.
• Per username/email: contoh 5 attempt per 15 menit.
• Per subnet/ASN: berguna saat serangan datang dari jaringan serupa.
• Per endpoint: pisahkan /wp-login.php, XML-RPC, REST login, dan recovery.

Dengan pola ini, satu bot yang ganti IP tetap kena rem saat menyerang username yang sama. Sebaliknya, user asli dari kantor besar tidak langsung terkunci hanya karena banyak orang berbagi IP.

Contoh Nginx untuk wp-login.php

limit_req_zone $binary_remote_addr zone=wplogin:10m rate=5r/m;

location = /wp-login.php {
    limit_req zone=wplogin burst=10 nodelay;
    include fastcgi_params;
    fastcgi_pass php-fpm;
}

Ini baseline, bukan final. Setelah itu, tambahkan proteksi di aplikasi atau WAF agar limit bisa membaca username, user-agent, negara, dan status auth.

CAPTCHA Sebaiknya Jadi Fallback, Bukan Gerbang Utama

CAPTCHA sering dipasang seperti pagar depan rumah. Namun, untuk situs yang sudah memakai passkey, pendekatan itu mulai usang. Kamu bisa memberi pengalaman login yang cepat untuk user normal, lalu menambah challenge saat sinyal mencurigakan muncul.

Kapan CAPTCHA Muncul?

• Login gagal berulang dari IP atau username sama.
• Perangkat baru mencoba recovery akun.
• Request datang dari ASN hosting atau proxy murah.
• User-agent kosong, aneh, atau berubah cepat.
• XML-RPC ping login meningkat tiba-tiba.

Dengan begitu, passkey tetap terasa mulus. Sementara itu, bot harus membayar biaya tambahan saat pola mereka mulai terlihat.

XML-RPC: Jalur Lama yang Sering Lupa Ditutup

XML-RPC masih sering jadi jalan pintas brute force WordPress, terutama lewat system.multicall. Satu request bisa membawa banyak percobaan login, sehingga rate limit biasa di halaman login tidak cukup.

Kalau kamu tidak memakai Jetpack, aplikasi mobile WordPress lama, atau integrasi remote publishing, matikan XML-RPC. Kalau masih butuh, batasi method-nya.

Blokir XML-RPC di Nginx

location = /xmlrpc.php {
    return 403;
}

Blokir XML-RPC di Apache

<Files xmlrpc.php>
    Require all denied
</Files>

Butuh referensi teknis? Cek dokumentasi resmi WordPress Developer Resources, panduan autentikasi modern dari W3C WebAuthn, dan rekomendasi identitas digital dari NIST SP 800-63B.

Jangan Lupakan Account Recovery

Setelah passkey aktif, jalur recovery sering menjadi pintu paling lemah. Penyerang mungkin tidak bisa mencuri passkey, tetapi mereka bisa mencoba reset akun, social engineering, atau membuka tiket palsu.

Karena itu, samakan level proteksi recovery dengan login utama. Minimal, aktifkan rate limit, audit log, notifikasi email, dan review manual untuk role admin.

Checklist Praktis untuk WP Admin

• Aktifkan passkey untuk admin, editor, dan akun privileged.
• Terapkan rate limit per IP, username, ASN, dan endpoint.
• Jadikan CAPTCHA fallback berbasis risiko.
• Matikan XML-RPC jika tidak dipakai.
• Batasi system.multicall jika XML-RPC masih perlu.
• Pasang alert untuk lonjakan login gagal.
• Audit halaman reset password dan recovery admin.
• Review plugin security agar tidak dobel fungsi dan bikin situs lambat.

Untuk lapisan tambahan, baca juga panduan internal tentang 7 lapis proteksi login WordPress dan cara memilih plugin keamanan WordPress tanpa bikin lemot.

FAQ

Apakah passkey menghapus kebutuhan rate limit?

Tidak. Passkey melindungi autentikasi, sedangkan rate limit melindungi endpoint dari abuse, scanning, dan resource exhaustion.

Apakah CAPTCHA masih perlu setelah passkey aktif?

Masih perlu, tetapi sebagai fallback berbasis risiko. Jangan tampilkan CAPTCHA ke semua user jika sinyal login normal.

Apakah XML-RPC aman dibiarkan aktif?

Aman hanya jika kamu benar-benar membutuhkannya dan membatasi method berisiko. Jika tidak dipakai, lebih baik blokir.

Kesimpulan

Passkey adalah lompatan besar untuk keamanan WordPress, tetapi bukan akhir dari hardening. Setelah passkey adoption, tugas berikutnya adalah mengecilkan permukaan brute force dengan rate limit pintar, CAPTCHA fallback, dan kontrol XML-RPC.

Kalau kamu mengelola situs penting, jangan tunggu sampai log login penuh serangan. Audit endpoint login-mu minggu ini, lalu bagikan temuanmu di komentar.