Passkey Sudah Jalan, Kok Fraud Recovery Malah Naik?

Passkey memang bikin phishing klasik makin susah. Namun, di banyak organisasi, itu justru menggeser serangan ke jalur yang lebih lunak, yaitu account recovery, help center, call center, dan proses verifikasi manual. Jadi kalau tim-mu merasa angka login phishing turun, tetapi takeover tetap terjadi, besar kemungkinan penyerang sudah pindah taktik.

Jawaban Singkat. Setelah rollout passkey, banyak pelaku fraud berhenti memaksa user menyerahkan kredensial. Sebaliknya, mereka menyerang proses pemulihan akun, memanipulasi agen support, lalu mengeksploitasi reset flow yang longgar. Karena itu, keamanan pasca-passkey harus fokus ke support channel security, recovery proofing, dan deteksi sinyal social engineering.

Kenapa account recovery fraud naik setelah passkey?

Alasannya simpel. Passkey mengeraskan pintu depan. Maka, penyerang cari pintu samping. Jika login utama sudah tahan phishing, jalur yang paling realistis adalah pemulihan akun, perubahan nomor ponsel, update email, atau override oleh agen support.

Perubahan ini penting buat fraud teams dan trust & safety. Dulu fokus utama ada di halaman login. Sekarang, risiko besar sering muncul di proses yang dianggap sekunder. Padahal, bagi attacker, recovery flow adalah login alternatif.

• Phishing turun, karena passkey lebih tahan credential theft.
• Social engineering naik, karena manusia jadi target utama.
• Support abuse meningkat, karena agen bisa jadi jalur bypass kontrol teknis.
• Reset flow dieksploitasi, terutama jika proof of ownership lemah.

Pola serangan baru yang sering muncul

1. Serang help center, bukan form login

Pelaku datang dengan cerita yang terasa masuk akal. Misalnya, perangkat hilang, nomor mati, email lama terkunci, atau akun penting buat transaksi mendesak. Lalu mereka mendorong agen untuk melakukan pengecualian.

2. Bangun kepercayaan dulu, takeover belakangan

Ini sering terlewat. Attacker tidak selalu langsung meminta reset. Kadang mereka membuka tiket kecil dulu, bertanya soal billing, alamat, atau histori akun. Tujuannya untuk mengumpulkan detail, mengukur SOP agen, lalu memakai informasi itu pada interaksi berikutnya.

3. Manfaatkan recovery fatigue

Saat antrean support penuh, SLA ketat, dan user marah, standar verifikasi cenderung turun. Kondisi operasional seperti ini sering lebih berbahaya daripada bug teknis.

Kesalahan besar yang sering dibuat tim

Banyak perusahaan menganggap passkey rollout sebagai proyek autentikasi. Padahal, seharusnya ini proyek identity assurance end to end. Kalau login diperkuat tetapi recovery tetap longgar, attacker cukup pindah jalur.

Di sinilah ide yang agak berlawanan dengan intuisi muncul. Recovery seharusnya lebih ketat daripada login, bukan lebih mudah. Login normal terjadi tiap hari. Recovery adalah peristiwa berisiko tinggi. Jadi friction tambahan di recovery justru sehat.

• Verifikasi hanya pakai data statis, seperti tanggal lahir atau alamat lama.
• Agen punya terlalu banyak diskresi tanpa approval kedua.
• Perubahan faktor pemulihan berlaku instan, tanpa cooling-off period.
• Tidak ada risk scoring pada tiket support dan jalur call center.

Framework praktis, Treat Recovery as a High-Risk Transaction

Kalau tim-mu butuh model sederhana, pakai kerangka ini. Anggap setiap pemulihan akun sebagai transaksi bernilai tinggi. Jadi, prosesnya harus punya lapisan kontrol, logging, dan pembatasan seperti alur pembayaran sensitif.

Layer 1, Proof

Minta bukti kepemilikan yang sulit disusun ulang oleh attacker. Hindari bergantung pada data yang mudah bocor dari media sosial, data broker, atau email lama.

Layer 2, Context

Lihat sinyal konteks. Contohnya, device baru, geolokasi aneh, perubahan bahasa, pola permintaan mendesak, atau tiket berulang dari kanal berbeda. Sinyal lemah secara tunggal, tetapi kuat saat digabung.

Layer 3, Delay

Jangan semua perubahan berlaku real-time. Cooling-off period 12 sampai 48 jam sering sangat efektif. Ini memberi waktu bagi user asli untuk menerima notifikasi dan membantah perubahan.

Layer 4, Dual control

Untuk override sensitif, gunakan persetujuan dua pihak. Satu agen memproses, satu reviewer menyetujui. Memang sedikit menambah biaya operasi. Namun, efeknya besar untuk menekan abuse.

Layer 5, Auditability

Simpan alasan, bukti, transkrip, dan keputusan. Tanpa jejak audit yang rapi, pola social engineering sulit dikenali, sehingga tim hanya bereaksi per kasus.

Kontrol yang paling berdampak buat support leaders

• Playbook verifikasi berbasis risiko, bukan skrip tunggal untuk semua kasus.
• Larangan override instan untuk penggantian email, nomor, passkey, atau MFA.
• Notifikasi out-of-band ke channel lama sebelum perubahan final.
• Queue khusus high-risk recovery untuk kasus yang menyangkut akun bernilai tinggi.
• Reason codes wajib agar pola abuse bisa dianalisis.
• Red team social engineering ke support desk secara berkala.

Sinyal dini yang wajib dipantau fraud team

Kalau mau menang cepat, jangan hanya lihat fraud rate akhir. Pantau juga leading indicators berikut.

• Lonjakan tiket recovery setelah kampanye passkey atau login hardening.
• Naiknya permintaan perubahan email dan nomor pada akun dormant.
• Ticket hopping, yaitu satu identitas menghubungi banyak kanal support.
• Permintaan urgent yang memaksa agen keluar SOP.
• Rasio recovery sukses yang terlalu tinggi pada segmen berisiko.

Untuk konteks tambahan soal pola manipulasi berbasis identitas sintetis, baca juga artikel internal ini, Suara Bos Bisa Palsu, Workflow-mu Jangan Ikut Palsu.

Referensi eksternal yang layak dibaca

• FIDO Alliance, penjelasan resmi passkeys
• NIST SP 800-63B, panduan autentikasi digital
• OWASP, referensi risiko aplikasi dan kontrol keamanan

FAQ

Apakah passkey gagal jika account recovery fraud naik?

Nggak. Passkey tetap sangat efektif melawan phishing. Masalahnya ada di perimeter lain, yaitu proses recovery dan support yang belum naik level secepat mekanisme login.

Kontrol pertama apa yang paling cepat diterapkan?

Mulai dari cooling-off period, notifikasi out-of-band, dan approval kedua untuk override sensitif. Tiga kontrol ini biasanya memberi dampak besar tanpa harus merombak seluruh stack identitas.

Kenapa support desk harus diperlakukan seperti permukaan serangan?

Karena bagi attacker, agen support bisa menjadi mekanisme bypass. Jika agen dapat mengubah email, nomor, atau faktor login, maka support desk pada praktiknya adalah bagian dari auth system.

Metode verifikasi apa yang sebaiknya dihindari?

Hindari verifikasi yang terlalu mengandalkan data statis dan mudah ditebak, seperti alamat, tanggal lahir, atau empat digit terakhir nomor tertentu. Data seperti ini sering sudah bocor atau bisa dikumpulkan dari banyak sumber.

Penutup

Rollout passkey memang langkah maju. Namun, attacker jarang berhenti, mereka hanya pindah jalur. Jadi, jika tim-mu ingin benar-benar menekan account takeover, fokusnya harus bergeser dari sekadar login security ke recovery security dan support channel integrity.

Kalau kamu sedang membangun playbook untuk account recovery fraud, tulis tantangan tim-mu di kolom komentar. Atau, subscribe dulu lewat blok berikut supaya update taktik fraud dan trust & safety terbaru nggak kelewat.