Ketika tim keamanan menyusun roadmap multi-factor authentication (MFA), pertanyaan yang hampir selalu muncul adalah yubikey vs google authenticator: mana yang lebih tepat untuk organisasi teregulasi di Indonesia? Keduanya sah disebut MFA dan keduanya jauh lebih baik daripada password tunggal. Namun model keamanan, struktur biaya, dan beban operasionalnya berbeda secara fundamental. Artikel ini membandingkan keduanya pada empat dimensi yang paling menentukan keputusan pengadaan: ketahanan phishing, biaya total kepemilikan, kemudahan deployment, dan skenario recovery.

YubiKey vs Google Authenticator: dua model keamanan yang berbeda
Google Authenticator: rahasia bersama yang bisa diketik ulang
Google Authenticator mengimplementasikan TOTP (Time-based One-Time Password, RFC 6238). Saat pendaftaran, server membangkitkan sebuah seed rahasia yang disalin ke ponsel melalui QR code. Sejak itu, server dan ponsel menghitung kode enam digit yang sama setiap 30 detik dari seed plus jam sistem. Konsekuensinya ada tiga: rahasia yang sama tersimpan di dua tempat (basis data server dan perangkat pengguna), kode berbentuk angka yang dapat dibaca dan diketik ulang oleh manusia, dan verifikasi tidak mengetahui situs mana yang meminta kode tersebut. Google Authenticator juga menyediakan sinkronisasi opsional ke Akun Google — nyaman bagi pengguna, tetapi memindahkan sebagian risiko ke keamanan akun cloud tersebut, sesuatu yang perlu dinilai eksplisit dalam kajian risiko organisasi.
YubiKey: kunci privat yang terikat pada domain
YubiKey menyimpan kunci privat di dalam secure element yang tidak dapat diekspor. Pada protokol FIDO2/WebAuthn, otentikasi berlangsung sebagai tantangan-jawaban kriptografis: browser menyertakan origin (domain sebenarnya) ke dalam data yang ditandatangani kunci. Tidak ada kode yang bisa dibacakan lewat telepon, tidak ada seed di sisi server yang bisa dicuri, dan tanda tangan hanya valid untuk domain tempat kredensial didaftarkan. Mekanisme ini kami bahas rinci pada artikel FIDO2 WebAuthn: cara kerja dan kenapa lebih aman dari OTP. Perlu dicatat, YubiKey bukan perangkat FIDO2 saja: satu unit umumnya juga mendukung PIV/smart card, OpenPGP, dan OATH-TOTP, sehingga dapat menampung aplikasi lawas yang belum mendukung WebAuthn.
Rujukan standar: NIST SP 800-63B menempatkan authenticator perangkat keras yang tahan peniruan verifier pada tingkat jaminan tertinggi (AAL3); aplikasi TOTP berada pada tingkat menengah.
NIST SP 800-63B adalah rujukan teknis internasional, bukan kewajiban regulasi Indonesia.
Ketahanan phishing: titik pemisah yang paling menentukan
Serangan yang relevan hari ini bukan lagi penebakan password, melainkan adversary-in-the-middle (AiTM): halaman login palsu yang bertindak sebagai proxy ke situs asli. Pengguna memasukkan password, lalu memasukkan kode TOTP; penyerang meneruskan keduanya dalam hitungan detik dan memanen cookie sesi. Karena jendela validitas TOTP mencapai 30 detik dan kode tidak terikat domain, Google Authenticator tidak memberi perlindungan berarti terhadap pola serangan ini. Rekayasa sosial melalui telepon — meminta korban membacakan enam digit — juga tetap efektif.
Pada YubiKey dengan FIDO2, browser menolak menandatangani tantangan untuk domain yang berbeda dari domain pendaftaran. Situs palsu tidak memperoleh apa pun yang dapat diputar ulang. Inilah alasan NIST SP 800-63B menempatkan verifier impersonation resistance dan authenticator berbasis perangkat keras sebagai syarat tingkat tertinggi (AAL3), sementara aplikasi TOTP berhenti di tingkat menengah. Perbandingan serupa terhadap kanal OTP lain dapat Anda baca pada ulasan security key vs OTP SMS.
Perbandingan empat dimensi keputusan
| Dimensi | Google Authenticator (TOTP) | YubiKey (FIDO2/PIV) |
|---|---|---|
| Ketahanan phishing AiTM | Rendah — kode dapat direlay | Tinggi — tanda tangan terikat origin |
| Risiko rahasia di sisi server | Ada — basis data seed bernilai tinggi | Tidak ada — server hanya menyimpan kunci publik |
| Ketergantungan perangkat pribadi | Tinggi (BYOD, ponsel karyawan) | Rendah — token milik organisasi |
| Biaya perangkat | Nol | Ada, per unit, umumnya dua unit per pengguna |
| Kecepatan rollout awal | Cepat, self-enrollment via QR | Lebih lambat: pengadaan, distribusi, pendaftaran |
| Jejak audit perangkat | Lemah — sulit membuktikan perangkat mana | Kuat — nomor seri dan atestasi FIDO |
| Beban helpdesk berulang | Tinggi (ganti ponsel, hilang, reset) | Rendah bila backup key terdaftar |
Biaya: lisensi nol bukan berarti biaya nol
Google Authenticator gratis, dan itu argumen yang wajar untuk populasi besar berisiko rendah. Namun perhitungan biaya total harus memasukkan komponen yang tidak muncul di faktur: tiket helpdesk setiap kali karyawan mengganti ponsel, waktu verifikasi identitas manual sebelum reset, produktivitas yang hilang saat pengguna terkunci, serta biaya insiden bila satu akun istimewa berhasil di-phishing. Untuk institusi keuangan atau kesehatan, satu insiden pengambilalihan akun administrator dapat memicu kewajiban notifikasi, audit forensik, dan remediasi yang nilainya jauh melampaui anggaran token.
YubiKey membalik pola tersebut: belanja modal di depan (perangkat per pengguna, praktik terbaiknya dua unit — satu harian, satu cadangan), lalu biaya operasional yang relatif datar karena perangkat keras tidak diganti setiap dua tahun seperti ponsel. Pertimbangkan pula bahwa token adalah aset organisasi, bukan perangkat pribadi karyawan — relevan bagi organisasi yang membatasi penggunaan ponsel pribadi di area kerja tertentu. Pemilihan model, konektor, dan varian FIPS dibahas pada panduan memilih YubiKey untuk perusahaan.
Deployment: kecepatan versus kendali
TOTP menang telak pada kecepatan rollout awal. Pengguna memindai QR, selesai, tanpa logistik fisik. YubiKey menuntut rantai proses tambahan: pengadaan, penomoran aset, distribusi ke kantor cabang, verifikasi identitas saat pendaftaran, dan pencatatan nomor seri. Bagi organisasi dengan puluhan lokasi, distribusi ini adalah pekerjaan proyek tersendiri, bukan sekadar konfigurasi identity provider.
Sebaliknya, YubiKey memberi kendali yang tidak dimiliki TOTP. Anda dapat membuktikan dalam audit bahwa autentikator adalah perangkat keras bersertifikasi tertentu melalui atestasi FIDO, mencocokkan kepemilikan token dengan daftar aset, dan mencabut akses dengan menghapus kredensial saat karyawan keluar. Dengan TOTP, seed berada di ponsel yang tidak Anda kelola.
Recovery: skenario yang paling sering diabaikan
Kelemahan terbesar TOTP justru ada di jalur pemulihan. Ketika ponsel hilang, jalur reset biasanya kembali ke email atau verifikasi helpdesk — dan jalur inilah yang menjadi sasaran rekayasa sosial. MFA sekuat apa pun akan runtuh bila prosedur recovery-nya lemah.
Untuk YubiKey, desain pemulihan yang sehat mencakup: mendaftarkan dua kunci per pengguna sejak awal, menyimpan kunci cadangan di lokasi terkendali, menyiapkan akun break-glass dengan kunci yang disegel secara fisik dan dipantau, serta prosedur penggantian dengan verifikasi identitas tatap muka atau setara. Untuk pengguna berisiko tinggi, hindari fallback ke TOTP atau OTP SMS — karena tingkat keamanan sistem ditentukan oleh metode terlemah yang masih diterima.
Posisi regulasi Indonesia
Perlu ditegaskan: tidak ada regulasi Indonesia yang secara eksplisit mewajibkan FIDO2 maupun melarang aplikasi TOTP. Yang diatur adalah kewajiban hasil. UU 27/2022 tentang Pelindungan Data Pribadi mewajibkan pengendali data melindungi dan memastikan keamanan data pribadi yang diprosesnya, serta memberitahukan kegagalan pelindungan dalam 3×24 jam. PP 71/2019 mewajibkan penyelenggara sistem elektronik menyelenggarakan sistem yang andal, aman, dan bertanggung jawab, sejalan dengan UU ITE. Di sektor perbankan, POJK 11/2022 tentang Penyelenggaraan Teknologi Informasi oleh Bank Umum menuntut manajemen risiko TI dan pengendalian akses yang proporsional terhadap risiko — pendekatan berbasis risiko ini kami uraikan pada artikel MFA berbasis risiko perbankan POJK 11/2022. Untuk fasilitas kesehatan, Permenkes 24/2022 tentang Rekam Medis Elektronik mengatur pengamanan dan pembatasan hak akses terhadap data rekam medis elektronik.
Implikasinya: regulator menilai kecukupan kontrol, bukan merek. Namun ketika Anda harus menjelaskan kepada auditor mengapa akun administrator inti dilindungi metode yang secara teknis dapat direlay oleh proxy phishing, argumen “sudah pakai MFA” tidak selalu memadai.
Rekomendasi: segmentasi, bukan pilihan tunggal
Bagi sebagian besar organisasi teregulasi, jawaban paling realistis bukan memilih salah satu, melainkan memetakan metode terhadap tingkat risiko:
- Wajib security key hardware — administrator domain dan cloud, akses ke basis data produksi, pembuat/penyetuju transaksi keuangan, akun berkemampuan mengubah kebijakan keamanan, serta personel yang menangani data pribadi dalam skala besar.
- Security key untuk kelompok berisiko menengah — direksi dan pejabat yang menjadi target whaling, tim keuangan, tim SDM, tenaga kesehatan dengan akses luas ke rekam medis elektronik.
- TOTP dapat diterima sementara — aplikasi internal berisiko rendah, kontraktor jangka pendek, atau sistem lawas yang belum mendukung WebAuthn, disertai target migrasi yang jelas.
- Arah jangka panjang — hilangkan password sebagai faktor utama untuk kelompok berisiko tinggi, sebagaimana dibahas pada panduan lengkap MFA tahan phishing.
Mulailah dari 5–10% populasi dengan hak akses paling istimewa. Di sanalah selisih keamanan antara kedua metode paling mahal bila diabaikan, dan di sanalah investasi perangkat keras paling mudah dijustifikasi.
Pertanyaan yang sering diajukan
Apakah Google Authenticator tidak aman dan harus segera ditinggalkan? Tidak. Google Authenticator tetap jauh lebih baik daripada password tunggal dan layak dipertahankan untuk populasi berisiko rendah. Yang perlu dipahami adalah batasnya: TOTP tidak dirancang untuk menahan phishing AiTM. Karena itu, prioritaskan migrasi pada akun istimewa terlebih dahulu, bukan mencabut TOTP secara serentak.
Apakah regulasi Indonesia mewajibkan penggunaan YubiKey atau FIDO2? Tidak ada ketentuan yang menyebut merek atau protokol tertentu sebagai kewajiban. UU PDP, PP 71/2019, POJK 11/2022, dan Permenkes 24/2022 mewajibkan pengamanan akses serta manajemen risiko yang memadai dan proporsional. Pemilihan teknologi diserahkan pada hasil kajian risiko organisasi, yang harus terdokumentasi dan dapat dipertanggungjawabkan saat audit.
Bagaimana jika beberapa aplikasi internal belum mendukung WebAuthn? YubiKey dapat menyimpan kredensial OATH-TOTP melalui aplikasi Yubico Authenticator, sehingga kode enam digit hanya muncul saat token terhubung. Skema ini tidak menambah ketahanan phishing pada aplikasi tersebut, tetapi memindahkan seed dari ponsel pribadi ke perangkat keras milik organisasi sambil menunggu aplikasi dimodernisasi.
Berapa banyak kunci yang perlu dibeli per pengguna? Praktik yang lazim adalah dua unit per pengguna: satu untuk penggunaan harian dan satu cadangan yang disimpan aman. Tambahkan beberapa unit cadangan terpusat untuk akun break-glass dan penggantian darurat. Tanpa kunci cadangan terdaftar, organisasi cenderung kembali ke jalur pemulihan lemah yang justru menghapus manfaat keamanannya.
Pelajari YubiKey security key resmi dari DTI.





Add comment