DTI — dtisolution.id

YubiKey vs Google Authenticator: Mana untuk Enterprise?

YubiKey vs Google Authenticator untuk enterprise: bandingkan ketahanan phishing, biaya, deployment, dan recovery bagi organisasi teregulasi di Indonesia.

Jawaban singkat: YubiKey dan Google Authenticator sama-sama menyediakan autentikasi multifaktor, tetapi berbeda model keamanan. Google Authenticator memakai kode TOTP yang masih bisa diketik ulang di situs palsu, sedangkan YubiKey memakai FIDO2/WebAuthn yang mengikat kredensial ke domain asli sehingga tahan phishing. Untuk akun berisiko tinggi di organisasi teregulasi, security key hardware lebih tepat.

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.

Ilustrasi YubiKey — YubiKey vs Google Authenticator: Mana untuk Enterprise?
YubiKey dari DTI.

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.

Dua model keamanan — TOTP (rahasia bersama) vs FIDO2 (kunci publik)
Google Authenticator — TOTP
1Server membangkitkan seed rahasia; disalin ke ponsel via QR code
2Seed yang sama tersimpan di dua tempat: basis data server dan ponsel
3Kode 6 digit dihitung ulang setiap 30 detik
4✗ Kode bisa dibaca, dibacakan, dan diketik ulang di situs palsu
Verifikasi tidak mengenali situs yang meminta kode
YubiKey — FIDO2/WebAuthn
1Kunci privat dibuat dan tersimpan di secure element — tidak dapat diekspor
2Server hanya menyimpan kunci publik
3Login = tanda tangan kriptografis atas challenge + origin (domain asli)
4✓ Situs palsu di domain berbeda — tanda tangan ditolak
Tanda tangan terikat domain (origin binding)

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.

Butuh security key hardware untuk organisasi Anda?
Pelajari YubiKey security key resmi dari DTI.

Add comment