{"id":5688,"date":"2026-10-28T08:32:45","date_gmt":"2026-10-28T01:32:45","guid":{"rendered":"https:\/\/dtisolution.id\/blog\/?p=5688"},"modified":"2026-10-28T08:32:45","modified_gmt":"2026-10-28T01:32:45","slug":"account-takeover-cara-mencegah-dengan-hardware-security-key","status":"publish","type":"post","link":"https:\/\/dtisolution.id\/blog\/account-takeover-cara-mencegah-dengan-hardware-security-key\/","title":{"rendered":"Account Takeover: Apa Itu, Modusnya, dan Cara Mencegahnya"},"content":{"rendered":"<div class=\"dti-snippet-answer\" style=\"margin:0 0 24px;padding:16px 20px;border-left:4px solid #E85A5A;background:#fdf6f6;border-radius:6px\"><strong>Jawaban singkat:<\/strong> Account takeover adalah pengambilalihan akun oleh penyerang yang masuk memakai identitas sah pengguna, biasanya lewat phishing, credential stuffing, atau SIM swap. Hardware security key berbasis FIDO2 mencegahnya karena tanda tangan kriptografisnya terikat pada domain asli dan butuh sentuhan fisik, sehingga kredensial yang dicuri lewat situs palsu atau dari jarak jauh tidak bisa dipakai.<\/div>\n<p>Laporan insiden di bank dan fintech jarang dibuka dengan kata &#8220;peretasan canggih&#8221;. Isinya lebih sering berbunyi seperti ini: nasabah memasukkan kode OTP di situs yang mirip aslinya, atau staf keuangan menyetujui notifikasi login yang tidak pernah ia minta. Begitulah account takeover (ATO) terjadi sehari-hari. Penyerang tidak membobol sistem. Ia masuk dengan identitas pengguna yang sah, dan sistem Anda menyambutnya seperti pengguna biasa. Artikel ini membahas di titik mana hardware security key memutus rantai account takeover, di mana efektivitasnya berhenti, dan kontrol apa yang perlu menemaninya.<\/p>\n<figure style=\"margin:20px 0\"><img decoding=\"async\" src=\"https:\/\/dtisolution.id\/blog\/wp-content\/uploads\/2026\/10\/dti-weekly-1791511284-yubikey-bio.png\" alt=\"Ilustrasi YubiKey \u2014 Account Takeover: Apa Itu, Modusnya, dan Cara Mencegahnya\" style=\"max-width:100%;height:auto;border-radius:8px\" title=\"\"><figcaption style=\"font-size:13px;color:#5B6B85;margin-top:6px\">YubiKey dari DTI.<\/figcaption><\/figure>\n<h2>Bagaimana account takeover biasanya terjadi<\/h2>\n<p>ATO hampir tidak pernah bergantung pada satu teknik saja. Penyerang menggabungkan beberapa cara, lalu memilih yang paling murah untuk target tertentu. Dari pola insiden yang umum ditemui di sektor keuangan dan kesehatan, ada enam jalur yang paling sering dipakai:<\/p>\n<ul>\n<li><strong>Credential stuffing.<\/strong> Pasangan email dan kata sandi yang bocor dari layanan lain dicoba secara massal ke portal Anda. Cara ini berhasil karena banyak orang memakai kata sandi yang sama di berbagai tempat.<\/li>\n<li><strong>Phishing adversary-in-the-middle.<\/strong> Situs palsu bertindak sebagai proxy ke situs asli. Kata sandi dan OTP diteruskan saat itu juga, lalu cookie sesi yang sudah terautentikasi dicuri. Toolkit siap pakai membuat teknik ini murah dan bisa dijalankan siapa saja.<\/li>\n<li><strong>SIM swap.<\/strong> Nomor ponsel korban dipindahkan ke kartu milik penyerang, lewat gerai operator atau orang dalam, sehingga OTP SMS jatuh ke tangan yang salah.<\/li>\n<li><strong>MFA fatigue.<\/strong> Notifikasi push dikirim berulang kali sampai korban menekan &#8220;Setujui&#8221;, sering kali disertai telepon dari orang yang mengaku tim IT.<\/li>\n<li><strong>Rekayasa sosial ke helpdesk.<\/strong> Penyerang menelepon service desk, mengaku ponselnya hilang, lalu meminta faktor kedua direset.<\/li>\n<li><strong>Pencurian token sesi oleh infostealer.<\/strong> Malware di laptop korban menyalin cookie browser yang masih aktif, sehingga penyerang tidak perlu login sama sekali.<\/li>\n<\/ul>\n<p>Empat dari enam jalur di atas tetap berhasil walaupun organisasi sudah memasang MFA. Karena itu OTP SMS dan push notification tidak lagi memadai untuk akun bernilai tinggi. Perbandingan rincinya bisa Anda baca di ulasan <a href=\"\/blog\/security-key-vs-otp-sms-tahan-phishing\/\">security key vs OTP SMS dari sisi ketahanan terhadap phishing<\/a>.<\/p>\n<h2>Mengapa hardware security key mencegah account takeover<\/h2>\n<p>Security key bekerja dengan protokol FIDO2\/WebAuthn. Saat didaftarkan, kunci membuat pasangan kunci kriptografis yang unik untuk setiap layanan, dan kunci privatnya tidak pernah keluar dari chip. Saat login, server mengirim tantangan acak, lalu kunci menandatanganinya setelah pengguna menyentuh perangkat.<\/p>\n<p>Bedanya dengan OTP ada pada <em>origin binding<\/em>. Browser memasukkan domain yang sedang dibuka ke dalam data yang ditandatangani. Kunci yang terdaftar untuk portal.bank-anda.co.id tidak akan menghasilkan tanda tangan yang valid untuk portal-bank-anda.co, semirip apa pun tampilannya. Pengguna tidak perlu jeli memeriksa alamat situs, karena pemeriksaan itu dilakukan oleh protokol. Mekanismenya dibahas lebih teknis di artikel <a href=\"\/blog\/fido2-webauthn-cara-kerja-lebih-aman-dari-otp-sms\/\">cara kerja FIDO2 WebAuthn dan alasan ia lebih aman dari OTP<\/a>.<\/p>\n<p>Syarat sentuhan fisik menutup jalur lain. Penyerang di negara lain tidak bisa &#8220;menekan setujui&#8221; untuk Anda, dan tidak ada kode yang bisa dibacakan lewat telepon. Perangkat seperti <a href=\"https:\/\/dtisolution.id\/id\/produk\/yubikey-security-key\">YubiKey security key<\/a> juga tidak bergantung pada nomor ponsel, sehingga SIM swap kehilangan nilainya. Beberapa seri tersedia dalam varian bersertifikat FIPS 140 untuk lingkungan yang mensyaratkannya.<\/p>\n<table>\n<thead>\n<tr>\n<th>Jalur serangan<\/th>\n<th>OTP SMS \/ push<\/th>\n<th>Security key FIDO2<\/th>\n<th>Catatan<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Credential stuffing<\/td>\n<td>Tertahan bila MFA diwajibkan<\/td>\n<td>Tertahan<\/td>\n<td>Kata sandi saja tidak cukup untuk masuk<\/td>\n<\/tr>\n<tr>\n<td>Phishing adversary-in-the-middle<\/td>\n<td>Lolos, OTP diteruskan saat itu juga<\/td>\n<td>Tertahan<\/td>\n<td>Domain palsu tidak cocok dengan kredensial<\/td>\n<\/tr>\n<tr>\n<td>SIM swap<\/td>\n<td>Lolos untuk OTP SMS<\/td>\n<td>Tertahan<\/td>\n<td>Tidak ada ketergantungan pada nomor ponsel<\/td>\n<\/tr>\n<tr>\n<td>MFA fatigue<\/td>\n<td>Lolos bila pengguna menyetujui<\/td>\n<td>Tertahan<\/td>\n<td>Butuh sentuhan pada kunci yang dipegang pengguna<\/td>\n<\/tr>\n<tr>\n<td>Rekayasa sosial ke helpdesk<\/td>\n<td>Bergantung prosedur<\/td>\n<td>Bergantung prosedur<\/td>\n<td>Titik lemahnya ada di alur pemulihan<\/td>\n<\/tr>\n<tr>\n<td>Pencurian cookie oleh infostealer<\/td>\n<td>Lolos<\/td>\n<td>Tidak dicegah setelah login<\/td>\n<td>Perlu kontrol sesi dan endpoint<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2>Batas yang perlu Anda pahami<\/h2>\n<p>Dua baris terakhir pada tabel itu sering terlewat dalam presentasi vendor. Security key mengamankan momen autentikasi, bukan seluruh siklus hidup akun.<\/p>\n<h3>Sesi setelah login<\/h3>\n<p>Begitu pengguna berhasil masuk, aplikasi biasanya menerbitkan cookie atau token. Kalau token itu dicuri infostealer, penyerang bisa memakainya tanpa melewati security key. Mitigasinya ada di sisi aplikasi dan endpoint: masa berlaku sesi yang pendek untuk peran sensitif, autentikasi ulang dengan security key sebelum transaksi berisiko (mengubah rekening tujuan, menyetujui transfer di atas ambang tertentu, mengekspor data pasien), pengikatan sesi ke perangkat bila platform Anda mendukungnya, serta EDR di laptop pengguna dengan hak akses tinggi.<\/p>\n<h3>Alur pemulihan akun<\/h3>\n<p>Pintu depan yang kuat tidak banyak berguna kalau pintu belakangnya bisa dibuka lewat satu panggilan telepon. Bila helpdesk bisa mereset faktor kedua hanya dengan nama ibu kandung dan NIP, penyerang akan memilih jalur itu. Berikan dua kunci per pengguna (satu dipakai, satu disimpan) agar kehilangan perangkat tidak otomatis berujung ke reset. Untuk kasus yang benar-benar perlu reset, wajibkan verifikasi identitas tatap muka atau panggilan video dengan pemeriksaan dokumen, beri jeda waktu sebelum faktor baru aktif, dan kirim notifikasi ke atasan langsung.<\/p>\n<h3>Fallback yang dibiarkan aktif<\/h3>\n<p>Banyak organisasi mendaftarkan security key tetapi tetap mengizinkan OTP SMS sebagai alternatif. Penyerang cukup mengklik &#8220;coba cara lain&#8221; di halaman login palsu. Untuk kelompok berisiko tinggi, kebijakan akses harus menerima metode tahan phishing saja.<\/p>\n<h2>Konteks regulasi di Indonesia<\/h2>\n<p>Tidak ada regulasi Indonesia yang secara eksplisit mewajibkan hardware security key. Yang diatur adalah kewajiban mengelola risiko dan melindungi data, dan pilihan metodenya menjadi tanggung jawab organisasi.<\/p>\n<p>Bagi bank umum, POJK 11\/POJK.03\/2022 tentang Penyelenggaraan Teknologi Informasi oleh Bank Umum menuntut pengamanan sistem, termasuk autentikasi, yang sepadan dengan risikonya. Cara menerjemahkan prinsip ini ke tingkatan MFA dibahas di <a href=\"\/blog\/mfa-berbasis-risiko-perbankan-pojk-11-2022\/\">panduan MFA berbasis risiko untuk perbankan sesuai POJK 11\/2022<\/a>. UU Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi mewajibkan pengendali data menjaga keamanan data pribadi dan memberitahukan kegagalan pelindungan secara tertulis paling lambat 3 x 24 jam. Pengambilalihan akun administrator yang bisa membuka data nasabah atau rekam medis sangat mungkin masuk kategori itu. PP 71\/2019 tentang Penyelenggaraan Sistem dan Transaksi Elektronik juga mewajibkan penyelenggara sistem elektronik menjaga keandalan dan keamanan sistemnya.<\/p>\n<p>Sebagai acuan teknis, NIST SP 800-63B menetapkan autentikator kriptografis yang tahan phishing sebagai syarat tingkat jaminan tertinggi (AAL3). Acuan ini berguna saat Anda harus menjelaskan kepada auditor mengapa akun tertentu diperlakukan berbeda.<\/p>\n<h2>Menerapkan secara bertahap<\/h2>\n<p>Membagikan kunci ke seluruh karyawan dalam satu gelombang jarang berhasil. Mulailah dari akun yang paling merugikan bila diambil alih: administrator domain dan identity provider, operator yang bisa memproses transfer dana, akun konsol cloud, engineer dengan akses produksi, dan administrator SIMRS atau arsip PACS di rumah sakit. Kelompok ini biasanya kecil, sehingga Anda bisa menguji alur pendaftaran, pemulihan, dan dukungan helpdesk sebelum memperluasnya ke pengguna umum.<\/p>\n<p>Ukur keberhasilannya dengan angka yang konkret, misalnya persentase akun istimewa yang sudah tidak punya fallback OTP, jumlah permintaan reset per bulan, dan waktu rata-rata penggantian kunci yang hilang. Angka-angka ini juga menjadi bukti yang bisa diperiksa saat audit TI.<\/p>\n<h3>Pertanyaan yang sering diajukan<\/h3>\n<p><strong>Apakah security key menghentikan semua bentuk account takeover?<\/strong><\/p>\n<p>Tidak. Security key menutup jalur yang memanfaatkan pencurian kredensial saat login, seperti phishing, credential stuffing, SIM swap, dan MFA fatigue. Pencurian token sesi setelah login dan rekayasa sosial ke helpdesk harus ditangani dengan kontrol sesi, keamanan endpoint, dan prosedur pemulihan yang ketat.<\/p>\n<p><strong>Bagaimana jika pengguna kehilangan security key?<\/strong><\/p>\n<p>Praktik yang dianjurkan adalah mendaftarkan dua kunci per pengguna, satu untuk dipakai sehari-hari dan satu sebagai cadangan. Kunci yang hilang dicabut dari akun, lalu pengguna masuk dengan kunci cadangan tanpa harus melalui reset yang rawan disalahgunakan.<\/p>\n<p><strong>Apakah regulator di Indonesia mewajibkan hardware security key?<\/strong><\/p>\n<p>Tidak ada ketentuan yang mewajibkannya secara spesifik. POJK 11\/POJK.03\/2022, UU PDP, dan PP 71\/2019 menuntut pengamanan yang sepadan dengan risiko, dan security key adalah salah satu cara yang kuat untuk memenuhi tuntutan itu pada akun berisiko tinggi.<\/p>\n<p><strong>Apakah security key bisa dipakai di aplikasi internal lama?<\/strong><\/p>\n<p>Bisa, bila aplikasi tersebut login melalui identity provider yang mendukung FIDO2\/WebAuthn atau SAML\/OIDC. Aplikasi yang hanya menerima kata sandi lokal biasanya perlu ditempatkan di belakang identity provider atau gateway akses terlebih dahulu.<\/p>\n<div class=\"dti-product-cta\" style=\"margin:28px 0;padding:18px 20px;border-left:4px solid #2C4A7E;background:#f4f6fa;border-radius:6px\"><strong>Butuh security key hardware untuk organisasi Anda?<\/strong><br \/>Pelajari <a href=\"https:\/\/dtisolution.id\/id\/produk\/yubikey-security-key\"><strong>YubiKey security key resmi dari DTI<\/strong><\/a>.<\/div>\n","protected":false},"excerpt":{"rendered":"<p>Account takeover sering lolos dari OTP dan push MFA. Pelajari modusnya, cara hardware security key FIDO2 memutusnya, dan celah yang tetap harus ditutup.<\/p>\n","protected":false},"author":19941,"featured_media":5687,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1466],"tags":[],"coauthors":[1470],"class_list":["post-5688","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-security"],"_links":{"self":[{"href":"https:\/\/dtisolution.id\/blog\/wp-json\/wp\/v2\/posts\/5688","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dtisolution.id\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dtisolution.id\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dtisolution.id\/blog\/wp-json\/wp\/v2\/users\/19941"}],"replies":[{"embeddable":true,"href":"https:\/\/dtisolution.id\/blog\/wp-json\/wp\/v2\/comments?post=5688"}],"version-history":[{"count":1,"href":"https:\/\/dtisolution.id\/blog\/wp-json\/wp\/v2\/posts\/5688\/revisions"}],"predecessor-version":[{"id":5787,"href":"https:\/\/dtisolution.id\/blog\/wp-json\/wp\/v2\/posts\/5688\/revisions\/5787"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/dtisolution.id\/blog\/wp-json\/wp\/v2\/media\/5687"}],"wp:attachment":[{"href":"https:\/\/dtisolution.id\/blog\/wp-json\/wp\/v2\/media?parent=5688"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dtisolution.id\/blog\/wp-json\/wp\/v2\/categories?post=5688"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dtisolution.id\/blog\/wp-json\/wp\/v2\/tags?post=5688"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/dtisolution.id\/blog\/wp-json\/wp\/v2\/coauthors?post=5688"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}