Passkey Lebih Tahan Phishing daripada OTP, Mengapa?

Intinya: Menurut pedoman identitas digital NIST SP 800-63B-4, kode sekali pakai yang diketik manual (OTP) bukan autentikasi yang tahan phishing. Passkey berbasis WebAuthn dapat mengikat autentikasi pada domain layanan yang sah, sehingga kode tidak mudah diteruskan ke situs penipu. Namun passkey bukan jaminan seluruh serangan akun berhenti.

Masalah mendasar OTP: dapat diteruskan

Serangan phishing tidak selalu memerlukan pencurian password permanen. Situs tiruan dapat meminta kode OTP lalu segera meneruskannya ke situs asli. Jika korban sedang berinteraksi dengan penipu, kode yang valid dapat dipakai sebelum kedaluwarsa. NIST menyatakan autentikator yang memerlukan input manual output, termasuk OTP, tidak memenuhi definisi phishing-resistant karena output itu tidak terikat pada sesi dan verifier yang benar.

Passkey menggunakan mekanisme kriptografi kunci publik. Situs asli menyimpan kunci publik, sedangkan kunci privat berada pada autentikator pengguna, sering kali dilindungi sistem operasi atau perangkat. Ketika login, autentikator menandatangani tantangan yang dikaitkan dengan identitas layanan. Pada WebAuthn, pengikatan nama verifier membuat passkey untuk domain asli tidak dapat begitu saja dipakai pada domain tiruan.

Pedoman NIST 800-63 revisi 4 diterbitkan pada 2025. Ini standar teknis AS yang dapat menjadi rujukan internasional, bukan peraturan yang otomatis berlaku untuk setiap organisasi Indonesia. Keputusan implementasi tetap memerlukan analisis ancaman, kebutuhan pengguna, dan ketentuan lokal.

Perbandingan berdasarkan jenis serangan

Perbedaan utama bukan ‘passkey selalu aman, OTP selalu gagal’. OTP yang dipakai bersama kontrol lain tetap meningkatkan keamanan dibanding password saja pada banyak skenario. Namun untuk serangan real-time adversary-in-the-middle, passkey berbasis domain binding memberikan properti kriptografis yang OTP manual tidak punya.

Passkey yang disinkronkan melalui penyedia sistem operasi memerlukan pemeriksaan tambahan atas keamanan akun sinkronisasi dan proses pemulihan. Autentikator perangkat keras dengan kunci yang tidak dapat diekspor menawarkan karakter risiko berbeda. NIST membedakan tingkat assurance dan kondisi penggunaan; satu konfigurasi tidak otomatis cocok untuk seluruh kelas sistem.

Simulasi 10.000 percobaan login

Untuk memahami perbedaan risiko, buat model hipotetis. Misalkan ada 10.000 login per bulan dan 1% pengguna diarahkan ke halaman phishing, yakni 100 kejadian. Jika pada skenario OTP 20% korban menyerahkan kode dan penyerang berhasil menggunakannya, ada 20 kompromi potensial. Jika pada passkey 0 kejadian berhasil karena hanya domain tiruan yang dicoba, itu menggambarkan perlindungan terhadap satu vektor spesifik, bukan tingkat keamanan passkey universal.

Rumus: kompromi yang diperkirakan = total login × proporsi diarahkan phishing × peluang kompromi bersyarat. Semua persentase contoh ini merupakan asumsi editorial, bukan statistik NIST atau hasil pengukuran insiden Indonesia. Pengujian nyata harus mengukur tingkat phishing, tingkat adopsi, kesalahan pengguna, dan insiden pemulihan akun secara terpisah.

Tambahkan biaya implementasi dan dukungan pelanggan. Jika 5% pengguna tidak dapat mengaktifkan passkey karena perangkat lama atau kebutuhan aksesibilitas, organisasi harus menyediakan jalur alternatif yang aman. Jalur alternatif yang hanya memakai SMS dapat menjadi titik terlemah sistem jika penyerang sengaja memilihnya.

Rencana migrasi tanpa mengunci pengguna

Langkah pertama: pilih akun berisiko tinggi—administrator, keuangan, pengelola domain, pengelola WordPress, dan operator pembayaran. Terapkan passkey pada kelompok kecil dan ukur keberhasilan login, waktu pemulihan, serta jumlah permintaan bantuan. Jangan menghapus semua metode pemulihan sebelum pengguna memiliki autentikator cadangan.

Langkah kedua: dokumentasikan kebijakan perangkat hilang, pergantian nomor telepon, pegawai keluar, dan akses darurat. Pemulihan akun perlu identifikasi yang sepadan dengan tingkat risiko. Langkah ketiga: pantau domain palsu, perubahan email pemulihan, login perangkat baru, dan penambahan autentikator. Autentikasi yang kuat tidak menghapus kebutuhan deteksi insiden.

Langkah keempat: berikan pelatihan sederhana. Pengguna tidak perlu memahami detail kriptografi untuk tahu bahwa passkey seharusnya tidak meminta mereka mengirim kode ke petugas melalui chat. Ajarkan bahwa permintaan transfer dana mendadak tetap perlu verifikasi melalui kanal kedua, sekalipun pengirim terlihat sebagai atasan.

Batas perlindungan untuk organisasi Indonesia

Bank, media, instansi pemerintah, dan UMKM menghadapi profil risiko berbeda. Portal publik yang melayani pengguna dengan ponsel lama perlu menyeimbangkan keamanan dengan aksesibilitas. Akun redaksi dan administrator website lebih mudah diwajibkan memakai autentikasi kuat karena jumlah penggunanya terbatas dan risiko pengambilalihan tinggi.

Organisasi harus menilai keamanan aplikasi setelah login: pengelolaan sesi, akses berbasis peran, pencatatan tindakan, dan persetujuan transaksi bernilai besar. Penipu yang sudah menguasai sesi atau berhasil membujuk korban menyetujui transaksi tidak otomatis dihentikan oleh passkey. Autentikasi adalah satu lapisan dari pertahanan berlapis.

Phishing-resistant bukan berarti bebas rekayasa sosial

Passkey membantu melindungi proses autentikasi terhadap situs login tiruan, tetapi penyerang dapat mengubah strategi. Mereka mungkin membujuk pengguna menambahkan perangkat baru, memulai pemulihan akun, memberikan akses aplikasi pihak ketiga, atau menyetujui transaksi palsu. Karena itu organisasi harus mengamankan seluruh siklus identitas: pendaftaran, autentikasi, penambahan autentikator, pemulihan, dan pencabutan akses.

Untuk akun administrator, prosedur pemulihan sebaiknya melibatkan verifikasi identitas yang kuat dan jejak persetujuan. Mengizinkan helpdesk mengganti seluruh passkey hanya berdasarkan telepon yang terdengar seperti suara atasan akan melemahkan kontrol kriptografi. Gunakan kanal yang sudah terdaftar sebelumnya dan pengesahan berlapis untuk tindakan berisiko tinggi.

Perlu pula membedakan phishing-resistant authentication dari transaction signing. Pengguna yang berhasil login dengan passkey masih bisa ditipu agar mentransfer dana ke rekening penipu. Pada pembayaran bernilai tinggi, tampilan detail penerima dan nominal yang harus disetujui secara terpisah menjadi lapisan penting. Jangan menyebut passkey sebagai obat universal penipuan digital.

Bagaimana mengukur keberhasilan migrasi passkey

Selain persentase akun yang mendaftarkan passkey, ukur proporsi login yang benar-benar menggunakan passkey, jumlah fallback ke OTP, tingkat kegagalan login sah, waktu pemulihan akun, dan insiden autentikasi. Jika 90% pengguna punya passkey tetapi 60% login tetap memakai OTP, paparan terhadap phishing real-time belum turun sebanyak angka adopsi terlihat.

Simulasi: dari 5.000 pengguna, 4.500 mendaftarkan passkey (90%). Namun bila hanya 2.000 dari 10.000 login bulanan memakai passkey, tingkat penggunaan aktual hanya 20%. Kedua indikator benar secara aritmetika, tetapi menjawab pertanyaan berbeda. Pengukuran perlu dilakukan pada periode yang sama dan disegmentasi menurut peran serta risiko akun.

Pelatihan sebaiknya menjelaskan bagaimana mengenali permintaan login yang tidak dimulai sendiri, apa yang dilakukan saat perangkat hilang, dan mengapa petugas resmi tidak memerlukan kode rahasia yang dikirim lewat chat. Sediakan bantuan aksesibilitas dan alternatif aman untuk pengguna yang perangkatnya tidak mendukung teknologi baru.

Perbedaan passkey tersinkron dan kunci perangkat keras

Passkey tersinkron dapat memberi pengalaman pengguna lebih mudah karena tersedia pada perangkat yang masuk ke akun ekosistem yang sama. Tetapi keamanan bergantung pula pada proses pemulihan akun sinkronisasi. Kunci keamanan perangkat keras yang tidak mengekspor kunci privat memiliki karakter perlindungan berbeda, namun dapat meningkatkan biaya dan kebutuhan pengelolaan perangkat cadangan. Organisasi harus memilih berdasarkan tingkat risiko, bukan tren produk.

NIST membedakan tingkat assurance autentikasi AAL1, AAL2, dan AAL3. Pada AAL2, penyedia layanan harus menawarkan setidaknya satu opsi autentikasi yang tahan phishing dalam kerangka yang dijelaskan standar; AAL3 memiliki persyaratan lebih ketat termasuk karakter autentikator. Jangan mengklaim semua passkey otomatis memenuhi AAL3. Implementasi, perlindungan kunci, dan proses autentikasi harus diperiksa.

Untuk organisasi dengan staf lapangan, persoalan praktis meliputi ponsel hilang, perangkat bersama, perubahan nomor, koneksi internet buruk, dan aksesibilitas. Migrasi perlu menyediakan prosedur yang dapat dijalankan helpdesk tanpa melemahkan keamanan. Jika alternatif pemulihan terlalu mudah, penyerang akan mengincar alternatif itu alih-alih mekanisme kriptografi utama.

Langkah khusus untuk akun redaksi dan bisnis

Pada situs WordPress, aktifkan autentikasi kuat untuk administrator dan editor, kurangi jumlah akun dengan hak instalasi plugin, serta audit sesi aktif setelah pergantian staf. Jangan membagikan satu akun administrator kepada banyak orang. Untuk rekening bisnis, gunakan persetujuan transaksi berlapis dan verifikasi perubahan rekening tujuan melalui kanal kedua. Passkey mengamankan login, bukan menggantikan kontrol otorisasi pembayaran.

Bila organisasi memakai SSO, periksa apakah passkey diterapkan pada identity provider utama atau hanya pada satu aplikasi. Satu aplikasi yang menggunakan passkey tetapi masih menerima sesi dari SSO lemah dapat memiliki jalur serangan yang tidak disadari. Inventarisasi semua jalur masuk dan pemulihan menjadi bagian dari penilaian risiko.

Pelaporan hasil migrasi harus menyebut periode observasi dan denominasi. Klaim ‘phishing turun 80%’ tanpa jumlah insiden awal, definisi insiden, dan perubahan kanal pelaporan tidak dapat dinilai. Ukur dampak pada serangan yang benar-benar ditargetkan passkey dan hindari menyamakan korelasi dengan sebab-akibat.

Checklist pengujian passkey sebelum peluncuran

Uji login pada perangkat Android, iOS, Windows, dan macOS yang benar-benar digunakan organisasi. Periksa akun dengan lebih dari satu perangkat, perubahan perangkat, dan sinkronisasi lintas ekosistem. Simulasikan perangkat hilang tanpa mengorbankan akun nyata. Catat jalur recovery, waktu bantuan, dan kebutuhan autentikator cadangan.

Lakukan uji phishing terkontrol pada domain uji milik organisasi untuk memastikan passkey tidak dapat dipakai pada domain tiruan. Jangan menguji dengan menipu pengguna di luar cakupan izin. Pastikan sistem tidak diam-diam jatuh kembali ke password dan OTP ketika login passkey gagal. Jika fallback diperlukan, terapkan pengendalian risiko tambahan.

Periksa integrasi dengan SSO dan aplikasi lama. Sebuah sistem mungkin mendukung passkey pada halaman utama, tetapi aplikasi legacy tetap menerima password melalui endpoint lain. Hasil audit harus menyebut jalur yang belum terlindungi, bukan hanya status fitur ‘passkey enabled’.

Bagaimana menjelaskan risiko kepada pengguna awam

Gunakan contoh yang sederhana: kode OTP adalah angka yang bisa disalin penipu; passkey adalah bukti kriptografis yang dibuat khusus untuk layanan yang benar. Analogi itu membantu, tetapi jangan mengatakan passkey tidak mungkin disalahgunakan. Akun masih bisa terganggu oleh malware, pemulihan yang lemah, atau tindakan pengguna yang ditipu setelah login.

Untuk komunikasi organisasi, hindari pesan ‘OTP sudah tidak aman sama sekali’. Lebih tepat menjelaskan bahwa OTP lebih baik daripada password saja dalam banyak situasi, tetapi tidak dirancang menahan phishing real-time. Pengguna yang belum memiliki perangkat kompatibel harus tetap memperoleh jalur akses yang wajar dan aman.

Tim keamanan dapat menetapkan tiga prioritas: melindungi administrator dan petugas keuangan terlebih dahulu; mengamankan proses recovery; dan mengurangi login OTP pada aplikasi yang mendukung WebAuthn. Pelaksanaan bertahap memudahkan pengukuran masalah kompatibilitas tanpa mengorbankan seluruh pengguna sekaligus.

Perhatikan pula risiko notifikasi login yang tidak diminta. Pengguna perlu diajari untuk menolak permintaan autentikasi yang muncul tanpa tindakan mereka sendiri. Meskipun passkey mengurangi kemampuan situs tiruan mencuri kredensial, pelaku masih dapat mencoba membuat korban menyetujui tindakan di aplikasi yang sah. Karena itu edukasi harus mencakup penolakan permintaan mendadak, pelaporan insiden, dan pemeriksaan aktivitas akun setelah ada tanda mencurigakan.

Untuk organisasi dengan ribuan akun, gunakan migrasi bertahap dan ukur dukungan teknis per seratus pengguna. Dokumentasikan perangkat yang gagal, versi sistem operasi, dan jalur pemulihan yang dipakai. Jika satu kelompok pengguna mengalami kegagalan tidak proporsional, perbaiki dukungan akses sebelum memperluas kewajiban. Keamanan tidak efektif bila pengguna terpaksa mencari jalan pintas yang lebih lemah.

Setiap perubahan kebijakan autentikasi juga perlu dicatat tanggal berlakunya dan dievaluasi kembali setelah ada pembaruan standar atau temuan insiden baru.

Pelaksanaan harus tetap mempertimbangkan kemampuan pengguna, biaya dukungan, dan ancaman nyata organisasi.

Kesimpulan

NIST memberi alasan teknis yang jelas: OTP manual dapat diteruskan, sedangkan passkey WebAuthn mengikat autentikasi pada domain yang sah. Prioritaskan passkey untuk akun kritis, tetapi perkuat pemulihan, sesi, dan persetujuan transaksi agar risiko tidak sekadar berpindah tempat.

Sumber dan bacaan terkait

• NIST SP 800-63B-4, autentikator dan phishing resistance (2025)
• NIST SP 800-63-4, Digital Identity Guidelines
• NIST, tingkat jaminan autentikasi
• Bacaan AIGEO: Consent phishing pada aplikasi cloud
• Bacaan AIGEO: Risiko prompt injection dalam RAG