Pass-ta-key: Arti Sebenarnya Serangan terhadap Passkey Google

Apakah passkey ternyata tidak aman? Pass-ta-key mengangkat pertanyaan itu secara langsung.

Palo Alto Networks Unit 42 menjelaskan tiga rantai serangan yang memungkinkan malware menyalahgunakan passkey yang disinkronkan Google, melewati verifikasi pengguna, dan dalam skenario terburuk mengekstrak seluruh kunci privat passkey sebuah akun.

Ketiga teknik tersebut tidak mematahkan WebAuthn, FIDO2, ataupun kriptografi kunci publik yang digunakan. Semuanya mensyaratkan malware sudah berjalan di PC Windows korban. Ini batasan yang signifikan.

Namun, menyimpulkan bahwa “semuanya sudah hilang pada endpoint yang terkompromi” terlalu menyederhanakan masalah. Varian Golden Pass-ta-key dapat mengubah intrusi lokal menjadi paket permanen dan dapat diekspor yang berisi seluruh passkey tersinkronisasi. Dampaknya melampaui pencurian satu sesi browser.

Ringkasan penilaian

Ya, ini merupakan topik keamanan baru yang berdiri sendiri. Namun, ini bukan alasan untuk menghapus passkey atau kembali hanya mengandalkan kata sandi.

Klasifikasi yang tepat adalah:

• Protokol tetap bertahan: Origin Binding, Challenge-Response, dan kriptografi asimetris tidak dipatahkan.
• Implementasi tertentu yang diserang: Kombinasi yang diteliti Unit 42 adalah Google Password Manager, Chrome, Windows, dan TPM.
• Endpoint harus sudah terkompromi: Situs acak dari internet tidak dapat menjalankan serangan ini terhadap komputer yang bersih.
• Dampaknya tetap dapat sangat besar: Variannya berkisar dari pembuatan Assertion login tanpa terlihat hingga ekstraksi kunci privat seluruh passkey tersinkronisasi.
• Passkey tersinkronisasi dan terikat perangkat memiliki profil risiko berbeda: Keduanya passkey, tetapi bukan tingkat keamanan yang sama.
• Kata sandi tetap menjadi pilihan yang lebih buruk: Kata sandi juga dapat dipancing, digunakan ulang, ditebak, dan dicuri dari basis data server.

Penilaian risiko saya bukan “tidak terjadi apa-apa”, melainkan: cakupan teknis sempit dan prasyarat sulit, tetapi dampaknya berpotensi sangat tinggi jika berhasil.

Cakupan teknis dan bukti

Status bukti per 31 Agustus 2026 mencakup alur serangan Unit 42, spesifikasi WebAuthn, dokumentasi passkey Google, issue Chromium yang terlihat publik, serta persyaratan NIST untuk autentikator yang dapat disinkronkan. Penilaian permukaan serangan juga mencakup Pass-the-Passkey dari SpecterOps, CVE-2026-34348, downgrade FIDO Proofpoint, dan temuan teknis Expel serta SquareX.

Riset dipublikasikan pada 3 Agustus dan diperbarui Unit 42 pada 14 Agustus. Cakupannya secara tegas adalah Google Password Manager di Chrome pada Windows dengan Trusted Platform Module. Browser, sistem operasi, dan penyedia passkey lain mungkin memiliki persoalan arsitektur serupa, tetapi ketiga serangan ini belum membuktikannya.

Belum ada kampanye serangan aktif di dunia nyata yang terdokumentasi untuk teknik khusus ini. Bukti saat ini berupa riset, Proof of Concept, dan Responsible Disclosure. Demonstrasi teknis tidak otomatis berarti eksploitasi massal.

Apa yang sebenarnya dilindungi passkey

Passkey bukan kata sandi yang sangat panjang. Ia adalah kredensial WebAuthn berbasis kriptografi asimetris.

Saat registrasi, autentikator membuat pasangan kunci:

private key -> remains with the authenticator
public key  -> is registered with the online service

Layanan daring, yang disebut “Relying Party” dalam WebAuthn, menyimpan kunci publik bersama Credential-ID dan akun pengguna. Saat login, layanan mengirim Challenge baru yang acak. Autentikator menandatangani data yang mengikat Challenge dan konteks situs pemanggil. Server memverifikasi tanda tangan memakai kunci publik yang tersimpan.

Kunci privat tidak dikirim ke server seperti kata sandi. Kebocoran pada layanan idealnya hanya memberikan kunci publik kepada penyerang, yang tidak dapat digunakan untuk membuat tanda tangan valid.

Pengikatan ke Relying-Party-ID dan Web-Origin juga penting. Passkey untuk example.com tidak akan menghasilkan Assertion valid bagi example.com dari domain phishing yang mirip. Pengguna tidak memiliki rahasia yang dapat diketik di situs yang salah atau dibacakan lewat telepon.

Inilah arti tahan phishing. NIST mendefinisikannya secara ketat: Verifier palsu tidak boleh memperoleh rahasia autentikasi atau respons autentikasi yang dapat dipakai pada layanan asli. WebAuthn mencapainya melalui ikatan kriptografis dengan nama Verifier.

Sifat ini tetap utuh pada Pass-ta-key. Malware tidak membuat situs phishing yang lebih baik. Ia sudah berjalan pada perangkat yang dipercaya pengguna sebagai autentikator.

User Presence dan User Verification bukan hal yang sama

Untuk memahami ketiga serangan, dua sinyal WebAuthn harus dibedakan:

• User Presence, UP: Pengguna melakukan tindakan kehadiran, misalnya menyentuh Security Key atau mengonfirmasi dialog.
• User Verification, UV: Autentikator memverifikasi pengguna secara lokal, misalnya melalui Windows Hello, PIN, atau biometrik.

Assertion WebAuthn mencantumkan hasil tersebut sebagai flag dalam authenticatorData. Server tidak boleh hanya memercayai apa yang diminta saat login dimulai. Jika meminta userVerification: "required", server juga harus memastikan flag UV benar-benar ada dalam respons.

Kontrol tunggal ini sangat penting. Unit 42 tidak dapat menuntaskan serangan Pass-ta-key sederhana terhadap GitHub karena User Verification tidak ada. Pada eBay, login awalnya tetap berhasil walaupun User Verification diminta. eBay memperbaiki validasi sisi server setelah menerima laporan.

Perbedaannya menunjukkan bahwa tanda tangan yang benar secara kriptografis belum tentu menghasilkan autentikasi multifaktor yang benar. Relying Party juga harus memvalidasi kondisi keamanan yang benar-benar dikonfirmasi autentikator.

Mengapa passkey tersinkronisasi menambah wilayah kepercayaan

Passkey terikat perangkat tetap berada pada autentikator tertentu, misalnya Hardware Security Key atau autentikator platform yang dilindungi secara lokal. Passkey tersinkronisasi harus tersedia di beberapa perangkat. Karena itu, material kunci privat harus dicadangkan dalam keadaan terenkripsi, dikirim melalui infrastruktur sinkronisasi, dan dipulihkan pada perangkat sah lainnya.

Perbedaan implementasi ini penting. Sinkronisasi memperluas sistem:

Relying Party
    |
browser and WebAuthn client
    |
local platform authenticator
    |
passkey manager and recovery logic
    |
cloud sync and additional devices

Setiap lapisan memerlukan aturan untuk kepercayaan perangkat, Onboarding, Recovery, enkripsi kunci, dan pencabutan.

NIST karena itu memperlakukan autentikator tersinkronisasi sebagai kategori tersendiri. Autentikator tersebut dapat sesuai hingga Authentication Assurance Level 2. Untuk AAL3, NIST mewajibkan kunci yang tidak dapat diekspor dalam lingkungan yang dilindungi perangkat keras atau autentikator terpisah. Ini bukan berarti passkey tersinkronisasi lemah, tetapi kenyamanan dan portabilitas kunci menghasilkan model Assurance berbeda.

Pass-ta-key menyerang wilayah kepercayaan tambahan ini.

Cakupan tepat riset

Unit 42 menyebut beberapa prasyarat penting:

• Google Password Manager mengelola passkey tersinkronisasi yang terdampak.
• Chrome berjalan pada Windows.
• Perangkat memiliki TPM.
• Malware sudah berjalan dalam konteks pengguna korban.
• Pengguna telah menyiapkan lingkungan Chrome dan Google yang relevan.
• Pada varian tertentu, malware harus membaca data Chrome lokal, memanipulasi berkas status, atau memeriksa memori proses Chrome.

Riset tidak menunjukkan serangan universal terhadap semua passkey. Riset juga tidak menunjukkan penyerang jarak jauh dapat mengambil kunci WebAuthn dari TPM tanpa lebih dahulu mengompromikan endpoint.

Karena itu, klaim “passkey telah dipecahkan” keliru. Pernyataan tepatnya: Unit 42 mendemonstrasikan tiga rantai serangan terhadap mekanisme kepercayaan, Onboarding, dan Recovery passkey Google tersinkronisasi pada endpoint Windows yang terkompromi.

Fase nol: Peta passkey lokal

Sebelum menjalankan salah satu varian, malware membaca basis data sinkronisasi Chrome lokal menurut Unit 42. Di sana terdapat rekaman WebauthnCredentialSpecifics yang antara lain memuat informasi Relying Party, nama pengguna, Credential-ID, dan material kunci privat terenkripsi.

Jalur yang disebut dalam riset adalah:

%LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB

Akses ke data tersebut dalam pengujian tidak memerlukan hak istimewa tinggi. Material kunci privat memang tidak tersedia langsung dalam teks biasa, tetapi metadatanya memberi malware daftar sasaran: layanan mana yang memiliki passkey, akun mana yang terkait, dan Credential-ID mana yang harus dipanggil.

Ini sudah relevan untuk deteksi. Infostealer dapat menginventarisasi terlebih dahulu lalu memilih akun bernilai tinggi.

Pass-ta-key: Assertion valid tanpa tindakan pengguna

Varian pertama menyalahgunakan kunci perangkat yang dipakai Chrome untuk membuktikan identitas perangkat Windows kepada Google Cloud Authenticator.

Chrome membuat Identity Key berbasis TPM. Unit 42 menjelaskan bahwa Chrome tidak menyimpan kunci privat sebagai kunci teks biasa. Chrome mengekspornya melalui Windows CNG sebagai NCRYPT_OPAQUE_KEY_BLOB. TPM melindungi blob tersebut agar dapat diimpor kembali untuk operasi kriptografis pada TPM fisik yang sama.

Ini masuk akal secara kriptografis, tetapi tidak otomatis menyelesaikan masalah otorisasi. Menurut riset, malware dalam konteks pengguna biasa dapat membaca wrapped_identity_private_key yang tersimpan atau mengambilnya dari memori Chrome lalu memanggil fungsi Windows CNG biasa. TPM melakukan tanda tangan karena permintaan secara teknis berasal dari perangkat yang benar. TPM tidak tahu apakah Chrome atau malware yang memanggil API.

Alurnya secara sederhana:

attacker requests a fresh challenge from the online service
    -> malware on the victim PC uses the TPM-bound identity key
    -> Google Cloud Authenticator accepts the device identity
    -> Cloud Authenticator creates a valid passkey assertion
    -> attacker submits the assertion to the online service

Pada varian ini, berkas passkey privat tidak harus diekspor. Malware memakai perangkat terkompromi dan Google Cloud Authenticator sebagai layanan penandatanganan.

Batas alaminya adalah flag UV. Identity Key membuktikan kepemilikan perangkat, bukan PIN atau biometrik yang berhasil. Layanan yang mewajibkan User Verification dan memeriksa hasilnya harus menolak Assertion dengan UV = 0.

Namun, varian ini tidak sepele. Banyak layanan mengatur User Verification hanya sebagai preferred demi kompatibilitas atau UX. Layanan lain memintanya tetapi salah memeriksa respons. Dalam kasus tersebut, login yang dimaksudkan multifaktor praktis menjadi satu faktor: akses ke identitas perangkat.

Silver Pass-ta-key: Penyerang mendaftarkan identitas UV sendiri

Silver Pass-ta-key melewati batas tersebut. Penyerang tidak memecahkan Windows Hello atau biometrik korban, melainkan membuat Cloud Authenticator menerima kunci miliknya sebagai bukti User Verification yang sah.

Titik awalnya adalah proses Re-Onboarding. Menurut riset, malware dapat membuat Cloud Authenticator melupakan status perangkat atau menghapus berkas lokal passkey_enclave_state. Pada operasi passkey berikutnya, Chrome harus mendaftarkan ulang perangkat.

Di Windows, User-Verification-Key tidak selalu dibuat pada langkah pertama. Chrome dapat memakai PIN Recovery Google Password Manager terlebih dahulu dan menetapkan status uv_key_pending. UV-Key dibuat pada penggunaan passkey berikutnya. Tahap peralihan yang mengutamakan kemudahan ini membuka jendela serangan.

Untuk persiapan, korban harus menyelesaikan langkah Recovery atau Re-Onboarding yang dipicu secara tak terduga dan memasukkan PIN GPM. Malware tidak perlu mencuri PIN tersebut. Ia memanfaatkan status uv_key_pending setelahnya. Login berbahaya selanjutnya dapat berlangsung tanpa interaksi tambahan dan tanpa perangkat korban terhubung.

Penyerang membuat pasangan kunci di lingkungannya sendiri dan mengirim kunci publik sebagai UV-Key baru. Menurut hasil Unit 42, Google Cloud Authenticator tidak memvalidasi apakah kunci baru benar-benar berasal dari perangkat keras tepercaya. Sistem menyimpan kunci penyerang bersama identitas perangkat yang sah.

Sejak itu, penyerang dapat menandatangani permintaan dengan kunci privatnya. Cloud Authenticator memperlakukannya sebagai verifikasi pengguna lokal dan membuat Assertion dengan flag UV aktif. PC korban tidak lagi harus daring.

Issue Chromium publik menyebut perilaku ini “GPM Passkeys Are Vulnerable to User Verification Key Abuse” dan saat diperiksa berstatus WAI. Terlepas dari penilaian internal itu, kasus ini menegaskan aturan arsitektur penting: Proses Recovery atau Onboarding yang mengikat kunci tepercaya baru adalah peristiwa autentikasi kritis.

Golden Pass-ta-key: Cloud-Sync menjadi material kunci yang dapat diekspor

Golden Pass-ta-key adalah varian terberat. Sasarannya adalah Security Domain Secret atau SDS, rahasia sepanjang 32 byte yang melindungi kunci privat passkey tersinkronisasi dalam akun Google Password Manager.

Janji arsitekturnya sederhana: Klien hanya memiliki wrapped_secret terenkripsi. Dekripsi terjadi di Cloud Authenticator dengan kunci khusus perangkat, sehingga malware pada klien tidak semestinya mudah memperoleh kunci privat passkey.

Namun, saat Onboarding dan Recovery, infrastruktur sinkronisasi harus memasukkan kembali perangkat ke Security Domain. Unit 42 menemukan bahwa Chrome menerima SDS dalam bentuk yang dapat diakses klien. Awalnya SDS bahkan muncul dalam log diagnostik FIDO Chrome. Google menghapus keluaran log itu setelah laporan, tetapi SDS masih memasuki memori proses Chrome selama proses tersebut.

Karena itu, Golden Pass-ta-key bukan dump memori sembarang kapan saja. Malware terlebih dahulu memaksa jalur Onboarding atau Recovery yang kritis lalu menangkap momen ketika SDS berada dalam proses Chrome. Ini menambah kompleksitas, tetapi tidak mengurangi cakupan rahasia setelah berhasil diekstrak.

Rantai serangannya:

1. Malware memaksa Onboarding baru.
2. Malware menunggu pembuatan ulang atau perubahan status Enclave lokal.
3. Malware membaca memori proses Chrome pada saat tepat dan mencari SDS.
4. Malware menggabungkan SDS dengan rekaman sinkronisasi yang telah dibaca.
5. Malware mendekripsi kunci privat passkey di dalamnya.
6. Autentikator milik penyerang yang tidak bergantung pada perangkat korban kemudian dapat membuat Assertion valid.

Inilah perbedaan kualitatif dari Session-Cookie yang dicuri. Sesi dapat kedaluwarsa atau dicabut server. Golden Pass-ta-key dapat mengekspor kunci privat seluruh passkey yang sudah disinkronkan. Unit 42 juga menyatakan SDS yang sama melindungi passkey tersinkronisasi yang dibuat kemudian, dan pada arsitektur yang diteliti tidak terlihat mekanisme rotasi atau pencabutan SDS.

Pernyataan ini menggambarkan implementasi Google yang diteliti. Ini bukan bukti bahwa semua penyedia passkey memakai rancangan Master-Key yang sama atau Google tidak dapat mengubah arsitekturnya.

Mengapa malware lokal tidak membuat serangan ini sepele

Malware yang dapat berjalan dalam konteks pengguna PC yang sedang login memang memiliki banyak pilihan lebih sederhana: mencuri Session-Cookie, membaca isi browser, memanipulasi transaksi, mengekstrak berkas, atau bertindak langsung dalam akun aktif. Tidak ada metode autentikasi yang dapat sepenuhnya memercayai klien yang telah terkompromi total.

Kelas serangannya juga bukan hal baru. Pencurian rahasia atau sesi aktif dari Password Manager dan browser yang terkompromi sudah lama menjadi alat Infostealer. Pass-ta-key tidak mengubah kompromi endpoint menjadi serangan jarak jauh ajaib.

Namun, menganggapnya tidak penting tetap keliru. Riset ini menghasilkan temuan implementasi konkret:

• Proses tanpa hak istimewa dapat memakai kunci perangkat Chrome yang terikat TPM untuk menandatangani.
• Batas antara kepemilikan perangkat dan User Verification bergantung pada pemeriksaan flag UV oleh Relying Party.
• Status Re-Onboarding memungkinkan pendaftaran UV-Key yang dikontrol penyerang.
• Rahasia sinkronisasi pusat awalnya muncul di log dan kemudian tetap dapat dicapai dalam memori proses menurut riset.
• Jalur terberat membuat kunci privat tersinkronisasi dapat digunakan di luar perangkat asal.
• Passkey tersinkronisasi sering tidak memiliki penghitung tanda tangan klasik sebagai sinyal cloning yang andal karena beberapa perangkat sah memakai Credential yang sama.

“Endpoint terkompromi” adalah prasyarat, bukan deskripsi dampak lengkap. Dalam Incident Response, pencurian sesi sementara sangat berbeda dari kepemilikan material kunci privat jangka panjang untuk banyak layanan.

Pass-ta-key hanya satu bagian dari permukaan serangan baru

Riset 2025 dan 2026 menunjukkan beberapa cara mengurangi perlindungan passkey tanpa mematahkan kunci privat secara matematis. Pass-ta-key menyalahgunakan Sync dan Recovery dengan malware yang sudah berjalan. Pass-the-Passkey menggabungkan Assertion yang tercatat dengan celah Replay server. Downgrade FIDO memanfaatkan metode login lemah yang masih aktif. Passkeys Pwned memerlukan ekstensi jahat atau eksekusi Script dalam browser. Infostealer mencuri sesi yang sudah diautentikasi.

Tidak satu pun mematahkan kriptografi kunci publik. Semuanya menyerang lapisan kepercayaan di sekitar WebAuthn: Sync dan Recovery, validasi server, browser, atau sesi setelah login. Pelanggaran protokol akan mengguncang semua implementasi yang sesuai. Kasus-kasus ini justru memerlukan pertahanan berbeda pada endpoint, browser, Identity, dan server.

Pass-the-Passkey: Ketika Assertion valid dapat digunakan ulang

SpecterOps mengidentifikasi tiga kerentanan pada Windows 11 dan Microsoft Entra ID serta lebih dari 20 teknik serangan untuk Black Hat USA 2026. Rantai terpenting bermula ketika Windows mencatat Assertion WebAuthn lengkap dalam Event Log Microsoft-Windows-WebAuthN/Operational.

Assertion tersebut memuat Credential-ID, Challenge, data autentikator, dan tanda tangan. Ini bukan kunci privat dan pada Verifier yang benar hanya boleh berfungsi satu kali dalam sesi login terkait. Namun, SpecterOps menemukan Entra ID menerima kembali Assertion yang tercatat dalam jendela waktu terbatas:

Windows logs a complete assertion
    -> an attacker reads it
    -> the verifier does not bind the challenge and assertion tightly enough to the session
    -> the same signed response is accepted again

Komponen Windows diberi CVE-2026-34348. Pada 14 Juli 2026, Microsoft menerbitkan pembaruan yang memotong tanda tangan dalam log menjadi beberapa byte dan menghilangkan sumber Replay. Pemeriksaan penghitung tanda tangan sisi server juga diperkenalkan untuk Security Key FIDO2 tertentu. Namun, penghitung bukan perlindungan universal karena beberapa Credential platform dan tersinkronisasi selalu menghasilkan nol atau berbagi status antarperangkat.

Pelajaran teknisnya lebih luas. Assertion WebAuthn tidak boleh masuk log diagnostik atau Event Log. Challenge harus acak, singkat, sekali pakai, dan terikat pada sesi login tertentu. Tanda tangan valid saja tidak membuktikan seluruh alur login benar.

Teknik lain memanfaatkan Parent-Window-Handle API WebAuthn Windows. Proses lokal dapat menempatkan dialog passkey asli seolah-olah berasal dari browser atau klien email tepercaya. UI sistem memang asli, tetapi konteks pemicunya menyesatkan. Perlakukan permintaan passkey atau Windows Hello tak terduga seperti MFA-Push tak terduga.

Fallback terlemah menentukan tingkat keamanan nyata

Proofpoint mendemonstrasikan downgrade FIDO terhadap Microsoft Entra ID pada 2025. Alur Evilginx yang dimodifikasi menyamar sebagai browser tanpa dukungan FIDO, sehingga platform menawarkan metode lain. Jika korban memilih SMS, OTP, atau metode yang dapat dipancing, kredensial dan sesi dapat disadap dalam alur Adversary-in-the-Middle.

Serangan tidak melewati Origin Binding, melainkan mencegah upacara WebAuthn dimulai. Ini hanya berhasil jika akun masih mengizinkan metode yang lebih lemah. Belum ada eksploitasi nyata yang terdokumentasi.

Kebijakannya jelas: Sebuah kebijakan belum tahan phishing hanya karena passkey telah didaftarkan. Kebijakan baru tahan phishing jika login untuk kebutuhan perlindungan tersebut tidak lagi menerima jalur cadangan yang dapat dipancing. Recovery dan reset Helpdesk harus dinilai dengan standar yang sama.

Browser termasuk dalam model keamanan

Dalam Passkeys Pwned, SquareX menunjukkan bagaimana ekstensi browser jahat atau eksekusi Script dalam konteks browser dapat memengaruhi navigator.credentials.create() dan navigator.credentials.get(). Saat registrasi, penyerang dapat menyisipkan material kuncinya sambil tetap menampilkan dialog biometrik asli kepada pengguna.

Riset vendor keamanan ini bukan eksploit browser universal. Prasyaratnya berat: Ekstensi atau konteks Script harus dapat masuk ke jalur WebAuthn. Namun, pelajaran arsitekturnya valid. Ekstensi, Content Script, dan fungsi proxy WebAuthn merupakan bagian Trusted Computing Base. Extension-Allowlist dan kontrol API browser berhak istimewa adalah perlindungan Identity, bukan sekadar kebersihan browser.

Passkey melindungi login, bukan otomatis sesi setelahnya

Setelah login, layanan biasanya memakai Session-Cookie atau token. Jika Infostealer mengambil artefak sesi dan server menerima penggunaannya dari perangkat lain, penyerang tidak memerlukan kata sandi atau passkey. Yang diserang adalah sesi yang sudah diautentikasi.

Ini lebih praktis saat ini daripada banyak Proof of Concept riset. Passkey mengurangi permukaan serangan sebelum dan saat login, tetapi tidak menggantikan penyimpanan token aman, durasi sesi pendek berbasis risiko, autentikasi ulang untuk tindakan kritis, pencabutan token, dan pengikatan kriptografis sesi bernilai tinggi ke perangkat.

Menyebutnya “MFA dilewati” sering menyesatkan. MFA selesai dengan benar, lalu hasilnya dicuri.

PoisonSeed menunjukkan cepatnya riset berubah menjadi sensasi

Pada Juli 2025, Expel awalnya melaporkan dugaan serangan Cross-Device Authentication dengan meneruskan QR-Code sah melalui situs phishing. Beberapa hari kemudian, Expel menarik klaim utama dan meminta maaf.

Analisis lanjutan menunjukkan pemeriksaan kedekatan lokal tidak berhasil dilewati. Tanpa kedekatan yang diperlukan, proses kedaluwarsa, semua tantangan MFA gagal, dan penyerang tidak memperoleh akses.

Kasus ini penting: Tidak setiap kombinasi QR-Code, phishing, dan passkey yang terdengar masuk akal adalah bypass FIDO. Komunikasi keamanan harus membedakan pengambilalihan akun yang diamati, Proof of Concept yang dapat direproduksi, serangan teoretis, dan hipotesis yang dibantah.

Penilaian keamanan saya

Cakupan teknis Pass-ta-key terbatas pada rantai yang dibuktikan terhadap Google Password Manager di Chrome pada Windows dengan TPM. Kemungkinannya menengah hingga rendah karena malware harus sudah berjalan lokal dan memanipulasi status atau memori proses.

Dampaknya tinggi hingga sangat tinggi: pengambilalihan akun, akses jarak jauh permanen, atau ekstraksi beberapa kunci privat. Risiko protokol tetap rendah karena WebAuthn, Origin Binding, dan kriptografi kunci publik tidak dipatahkan.

Bagi pengguna biasa, passkey tersinkronisasi umumnya tetap lebih aman daripada kata sandi dengan SMS atau TOTP. Untuk administrator, persetujuan finansial, produksi, atau sistem sangat teregulasi, organisasi harus menentukan apakah Assurance sinkronisasi memadai. Kunci platform terikat perangkat atau FIDO2 Hardware Key terpisah dapat menjadi batas yang tepat. Ini bukan penolakan terhadap Sync-Passkey, melainkan arsitektur keamanan bertingkat.

Yang harus diperiksa operator layanan web

Pelajaran utama bagi Relying Party adalah validasi WebAuthn yang bersih. Server harus:

• menetapkan userVerification: "required" jika diperlukan,
• wajib memeriksa flag UV dalam authenticatorData,
• memvalidasi Challenge, Origin, Relying-Party-ID, dan tanda tangan sepenuhnya,
• membuat Challenge acak, singkat, sekali pakai, dan terikat sesi,
• tidak mencatat Assertion lengkap, tanda tangan, atau artefak autentikasi yang dapat digunakan ulang,
• mencatat registrasi, penghapusan, dan Account-Recovery sebagai peristiwa berisiko tinggi,
• mengizinkan autentikator baru pada akun istimewa hanya setelah autentikasi ulang kuat,
• mencatat asal dan karakteristik autentikator jika memungkinkan,
• mempertimbangkan Attestation dan autentikator terkelola untuk kasus keamanan tinggi,
• memasukkan perubahan perangkat, lokasi, dan ikatan passkey ke telemetri Identity,
• mencabut sesi setelah perubahan berisiko dan mengautentikasi ulang tindakan kritis,
• memakai sesi terikat perangkat ketika platform dan aplikasi mendukungnya secara andal.

Pustaka WebAuthn matang mengurangi risiko implementasi sendiri yang tidak lengkap, tetapi konfigurasi tetap harus ditinjau. Kasus eBay menunjukkan dampak satu flag yang tidak diperiksa. Pass-the-Passkey menunjukkan tanda tangan benar tidak berguna jika Challenge dan sesi tidak cocok.

Yang harus diubah organisasi dalam peluncuran passkey

Passkey bukan hanya proyek IAM, tetapi juga proyek endpoint, browser, dan Recovery. Akun Workforce biasa dapat memakai passkey tersinkronisasi pada perangkat terkelola dengan perlindungan endpoint dan Conditional Access. Akun sensitif memerlukan autentikator platform terkelola atau sinkronisasi terbatas. Admin, Break-Glass, dan akun bernilai tinggi sebaiknya memakai FIDO2 Hardware Key terikat perangkat, Recovery ketat, dan tanpa sinkronisasi cloud tak terkendali.

Organisasi juga harus:

• memperbarui Chrome dan Windows,
• memastikan patch CVE-2026-34348 terpasang,
• secara sadar mengizinkan atau membatasi penyimpanan passkey browser lewat Enterprise Policies,
• mengendalikan ekstensi dengan Allowlist dan memantau proxy WebAuthn berhak istimewa,
• menerapkan EDR dan Application Control pada proses pengguna,
• memantau akses ke basis data sinkronisasi dan dump memori Chrome,
• menyelidiki penghapusan atau pembuatan ulang passkey_enclave_state,
• memperlakukan permintaan PIN Recovery GPM berulang atau tak terduga sebagai sinyal peringatan,
• menguji proses kehilangan perangkat dan Account-Recovery terhadap penyalahgunaan,
• menghapus Fallback yang dapat dipancing untuk akun istimewa,
• menyelidiki prompt passkey, registrasi Credential, dan penggunaan WebAuthn dari proses aneh,
• menginventarisasi layanan yang memakai Credential tersinkronisasi atau terikat perangkat.

Endpoint Detection bukan pos anggaran terpisah dari passkey. Jika autentikator hidup di browser dan klien, keamanan endpoint adalah bagian langsung dari model autentikasi.

Yang harus dilakukan pengguna sekarang

Tidak ada alasan untuk menghapus semua passkey dan kembali ke kata sandi yang lebih lemah. Sebaliknya:

• perbarui Chrome dan Windows segera,
• pasang hanya perangkat lunak dan ekstensi tepercaya,
• pertahankan perlindungan perangkat, Windows Hello, dan antimalware,
• jangan konfirmasi dialog passkey atau Windows Hello yang tak terduga,
• jangan menyetujui permintaan PIN Recovery atau Re-Onboarding secara sembarangan,
• periksa perangkat dan passkey terdaftar di Google Password Manager serta layanan penting,
• pertimbangkan Hardware Security Key terpisah untuk akun bernilai tinggi,
• isolasi dan periksa endpoint yang mencurigakan.

Jika ada indikasi malware, status Chrome dimanipulasi, atau dump memori, anggap Credential dan sesi mungkin telah dicuri. Mengganti kata sandi tidak cukup. Bangun ulang atau bersihkan endpoint secara andal, cabut sesi aktif, periksa metode Recovery, hapus passkey asing, dan daftarkan kembali autentikator tepercaya.

Pada dugaan Golden Pass-ta-key, riset publik tidak menjelaskan rotasi SDS sederhana bagi pengguna. Jangan menjanjikan perubahan PIN atau pembuatan ulang satu passkey pasti menyelesaikannya. Setelah endpoint bersih, saya akan mendaftarkan Credential baru yang terikat perangkat untuk akun penting, menghapus Credential tersinkronisasi lama, dan melibatkan penyedia atau tim Incident Response.

Pelajaran utamanya

Passkey bukan perisai terhadap semua kompromi. Ia menyelesaikan masalah besar: pengguna tidak perlu memberikan rahasia yang dapat digunakan ulang kepada server atau situs palsu.

Pass-ta-key menunjukkan lapisan berikutnya. Sinkronisasi kunci privat menciptakan infrastruktur enkripsi, kepercayaan perangkat, dan Recovery yang dapat memiliki kelemahan walaupun protokol WebAuthn benar.

Menyatakan passkey gagal adalah reaksi yang salah. Menganggap setiap serangan setelah infeksi malware lokal sebagai hal sepele juga salah.

Penilaian saya jelas: lanjutkan peluncuran passkey, tetapi rumuskan janji keamanannya secara tepat. Passkey tersinkronisasi sangat kuat terhadap phishing. Hardware Key terikat perangkat memberi batas lebih kuat bagi akun bernilai tinggi. Dan tidak ada autentikator yang menggantikan endpoint bersih, Recovery terkendali, serta validasi server yang benar.

Passkey telah mengunci pintu phishing jauh lebih baik. Pass-ta-key mengingatkan bahwa penyerang yang sudah berada di dalam rumah memerlukan pertahanan berbeda.

Sampai jumpa lagi,
Joe

FAQ