Passkeys dan multi-akun: isolasi kunci pada 2026

Mulai 1 September 2026, Microsoft mulai memasukkan passkeys sebagai metode masuk default di Entra ID, dan mulai 1 Februari 2027, akan menonaktifkan pengiriman kode SMS dan suara. Google telah menjadikan kunci akses sebagai opsi utama untuk akun pribadi sejak Oktober 2023. Bagi satu orang dengan satu akun, ini sangat nyaman. Namun, bagi mereka yang mengelola puluhan akun di anti-detect, passkey dengan mudah menjadi benang tak terlihat yang menghubungkan profil yang terisolasi. Di bawah ini kita akan membahas bagaimana ini terjadi dan bagaimana membangun skema di mana kunci tidak "bocor" antara akun.

Mengapa pertanyaan ini muncul sekarang

Passkeys telah ada sejak 2022, tetapi pada 2026, dari "bisa diaktifkan" menjadi "anda akan diminta". Tiga alasan spesifik:

Microsoft Entra ID. Mulai September 2026, pengguna yang mengonfirmasi masuk melalui SMS atau panggilan akan secara otomatis diaktifkan passkeys: pada pemeriksaan MFA berikutnya, akan ada tawaran untuk mendaftar kunci. Hingga 31 Januari 2027, ini dapat ditunda, mulai 1 Februari 2027, tidak bisa ditunda lagi. Microsoft mengutip angkanya: kampanye phishing dengan AI mendapatkan 54% klik dibandingkan 12% untuk yang biasa.
Google. Mulai Oktober 2023, di akun pribadi, opsi "Lewati pengenalan kata sandi jika memungkinkan" diaktifkan secara default. Jika kunci telah dibuat, Google menawarkan untuk masuk menggunakan kunci tersebut.
Transfer kunci antar pengelola. FIDO Alliance telah menerbitkan standar Credential Exchange (format CXF dan CXP). Di iOS 26 dan macOS 26, passkeys dapat ditransfer antara Apple Passwords, 1Password, Bitwarden, Dashlane, dan aplikasi lainnya secara terenkripsi, tanpa mengekspor file. Kunci tidak lagi terikat secara permanen ke satu penyimpanan. Untuk multi-akunting, ini adalah kesempatan dan risiko.

Bagaimana passkey bekerja dan mengapa ia merusak isolasi profil

Passkey adalah sepasang kunci kriptografis. Kunci publik disimpan oleh situs, kunci privat disimpan oleh "pengautentikasi". Kunci terikat pada domain (dalam spesifikasi ini rpId), sehingga situs phishing tidak akan mendapatkannya. Pertanyaan utama untuk multi-akunting adalah di mana secara fisik kunci privat disimpan. Anti-detect mengisolasi cookies, localStorage, IndexedDB, dan sidik jari. Penyimpanan kunci sering kali berada di luar profil browser:

Windows Hello menyimpan kunci di tingkat akun Windows. Browser mana pun dan profil mana pun di bawah akun ini mengakses penyimpanan yang sama.
Ikatan kunci iCloud di macOS milik Apple ID. Chrome dan Safari di satu Mac melihat satu set kunci yang sama.
Pengelola kata sandi Google terikat pada akun Google yang digunakan oleh browser atau ponsel. Satu akun Google bisnis untuk dua puluh profil — ini adalah satu brankas bersama.
Ekstensi-pengelola (Bitwarden, 1Password, dan lainnya) menyimpan kunci di penyimpanan akun mereka. Satu penyimpanan untuk semua profil berfungsi sebagai titik tunggal, melalui mana semuanya terlihat.

Dari sini muncul kesalahan yang khas. Anda mengklik "Masuk dengan kunci akses" di profil akun №7, tetapi sistem menunjukkan kunci akun №3 dan №12 di situs yang sama. Situs ini tidak melihat daftar ini: ia hanya menerima kunci yang dipilih. Namun, satu klik yang salah — dan akun №3 masuk dari profil, IP, dan sidik jari akun №7. Hubungan semacam itu tidak dapat dibatalkan.

Apa yang sebenarnya diketahui situs saat masuk dengan passkey

Passkey tidak menghilangkan risiko penilaian, ia hanya menggantikan kata sandi. Saat masuk, platform masih melihat IP, sidik jari browser, dan riwayat sesi. Selain itu, ia menerima beberapa sinyal WebAuthn miliknya:

Identifikasi kunci (credential ID). Ini unik untuk pasangan "akun — pengautentikasi".
AAGUID — identifikasi model pengautentikasi. Berdasarkan ini, situs seperti Google menandatangani kunci dalam pengaturan akun: "dibuat di iCloud Keychain", "di pengelola kata sandi Google", dan seterusnya. Ini bukan nomor unik perangkat Anda, tetapi ini adalah karakteristik lain yang harus cocok dengan legenda profil.
Flag BE dan BS (kelayakan cadangan dan status cadangan) menunjukkan apakah kunci ini disinkronkan atau terikat pada perangkat.

Kesimpulan: profil "mobile" yang masuk dengan kunci dari Windows Hello terlihat sama tidak logisnya dengan iPhone dengan zona waktu Brasil dan IP dari Jerman. Kunci harus sesuai dengan legenda yang sama dengan proxy dan sidik jari.

Skema langkah demi langkah: satu akun — satu profil — satu penyimpanan — satu IP

Lakukan inventarisasi. Catat platform di mana akun Anda sudah memiliki passkeys atau ada tawaran untuk membuatnya: Google, Microsoft, pasar besar, dan media sosial. Di pengaturan keamanan setiap akun, terlihat berapa banyak kunci yang terdaftar dan di mana mereka dibuat. Semua catatan tak terduga "Windows Hello" dan "iCloud Keychain" adalah kandidat untuk dihapus.
Nonaktifkan penyimpanan kunci sistem untuk profil kerja. Di browser tempat profil bekerja, matikan penyimpanan kata sandi dan kunci akses di pengelola bawaan. Di mesin kerja, jangan buat kunci di Windows Hello atau ikatan iCloud. Jika jendela pembuatan kunci menawarkan "komputer ini", pilih cara lain.
Pilih penyimpanan untuk setiap akun. Aturannya sederhana: penyimpanan harus dipisahkan seperti profil. Opsi:
- penyimpanan pengelola kata sandi terpisah untuk setiap akun atau untuk kelompok akun dari satu klien;
- kunci perangkat keras (FIDO2) untuk beberapa akun paling berharga;
- untuk otomatisasi — pengautentikasi perangkat lunak, yang akan dibahas di langkah 6.
Satu penyimpanan untuk semua — cara paling umum untuk menghubungkan akun satu sama lain.
Daftarkan kunci hanya dari profil "asli". Profil yang sama, sidik jari yang sama, proxy yang sama dengan sesi yang terikat, geo yang sama saat akun berfungsi normal. Pendaftaran kunci adalah tindakan sensitif, dan platform memperhatikannya dengan cermat. Perubahan IP di tengah prosedur sering kali menyebabkan pemeriksaan tambahan. Cara menjaga satu alamat untuk profil, telah kami bahas secara mendetail dalam artikel sticky-sesi atau rotasi untuk profil anti-detect.
Siapkan metode cadangan untuk masuk. Penyimpanan yang hilang berarti akun yang hilang. Untuk setiap akun, diperlukan cara kedua untuk masuk: passkey kedua di penyimpanan lain, kata sandi dengan TOTP, atau kode pemulihan yang disimpan terpisah dari kunci. Microsoft di Entra secara langsung meminta pengguna untuk beralih ke metode yang tahan terhadap phishing sebelum Februari 2027. Jangan tunggu sampai jendela pendaftaran tidak bisa ditutup lagi.
Gunakan pengautentikator virtual dalam otomatisasi. Di Chrome DevTools Protocol ada domain WebAuthn. Metode addVirtualAuthenticator membuat pengautentikasi perangkat lunak dengan protokol ctap2 dan transport internal (platform) atau usb/hybrid. Parameter hasResidentKey dan hasUserVerification mengaktifkan penyimpanan kunci di pengautentikator dan verifikasi pengguna. getCredentials setelah pendaftaran mengembalikan kunci secara keseluruhan: credentialId, rpId, userHandle, signCount, dan kunci privat dalam format PKCS#8. addCredential pada peluncuran berikutnya mengembalikannya. Hasilnya adalah kunci yang hanya hidup di penyimpanan rahasia Anda dan terhubung ke sesi akun tertentu. Dua catatan: domain ini ditandai sebagai eksperimental dan dibuat untuk pengujian WebAuthn, dan kunci privat yang diekspor adalah rahasia tingkat kata sandi, dan harus disimpan dengan cara yang sesuai.
Transfer kunci melalui Credential Exchange, bukan secara manual. Jika Anda mengganti pengelola atau memisahkan akun ke penyimpanan yang berbeda, gunakan ekspor bawaan berdasarkan standar FIDO: ini didukung di Apple Passwords, 1Password, Bitwarden, Dashlane, DuckDuckGo, Devolutions. Perhatikan bahwa di macOS, beberapa aplikasi belum menerapkan mekanisme ini.

Bahaya yang mungkin terjadi

Sinkronisasi secara default. Kunci yang dibuat "di perangkat ini" dapat langsung masuk ke cloud iCloud atau Google dan muncul di semua perangkat akun ini, termasuk ponsel pribadi Anda.
Masuk lintas perangkat melalui QR. Skenario "pindai QR dengan ponsel" (transport hybrid) menghubungkan ke sesi profil ponsel nyata dengan kunci-kuncinya. Untuk profil kerja, ini adalah hubungan tambahan.
AAGUID yang sama di seluruh farm — itu normal. Jutaan orang menggunakan pengelola yang sama. Yang berbahaya bukanlah penyedia yang sama, tetapi kunci bersama atau penyimpanan bersama.
Passkey tidak menyembuhkan "masuk kotor". Jika akun masuk dengan IP yang sudah terlihat di akun tetangga, atau dari pusat data yang tidak disukai oleh platform, kriptografi yang kuat tidak akan membantu. Risiko dinilai berdasarkan kombinasi sinyal.
Faktor kedua juga perlu diisolasi. Jika metode cadangan masuk adalah TOTP, rahasia juga tersebar di akun, dan tidak disimpan dalam satu aplikasi di ponsel pribadi. Cara menghubungkan 2FA dan proxy, telah kami bahas dalam materi tentang autentikasi dua faktor dalam kerja melalui proxy.

Proxy apa yang dibutuhkan dan mengapa

Untuk masuk dengan kunci, yang paling penting adalah konsistensi: akun harus mendaftarkan kunci dan kemudian masuk dengan kunci tersebut dari jaringan yang sama, di geo yang sama. Oleh karena itu:

Profil web di anti-detect — proxy residensial dengan sesi yang terikat di negara akun. Ini adalah alamat penyedia rumah, dan mereka sesuai dengan legenda "pengguna biasa di rumah".
Platform seluler dan akun dengan legenda seluler — proxy seluler. Profil seluler yang mendaftarkan kunci dari jaringan rumah di ujung negara yang lain, keluar dari sejarahnya.
Rotasi untuk setiap permintaan cocok untuk pengambilan data, tetapi tidak untuk masuk ke akun. Tetapkan interval dengan cadangan untuk seluruh sesi kerja.

Kesimpulan

Passkeys membuat masuk tahan terhadap phishing, tetapi memindahkan titik koneksi antara akun dari cookies dan kata sandi ke penyimpanan kunci. Titik ini sering kali berada di luar profil anti-detect: di Windows Hello, iCloud, akun Google, atau penyimpanan bersama pengelola. Skema kerja terlihat seperti ini: setiap akun memiliki profilnya sendiri, penyimpanan kunci sendiri, IP tetapnya sendiri, dan cara cadangan untuk masuk. Untuk otomatisasi, ada pengautentikator virtual di CDP. Lakukan ini sebelum Februari 2027, ketika Microsoft akan berhenti memberikan penundaan pendaftaran. Setelah itu, Anda harus menyelesaikannya dengan terburu-buru dan langsung di akun yang aktif.