KomuraSoft LLC
Hubungi kami
Menu

Mengapa passkey aman? — panduan bergambar autentikasi yang tidak mengirim rahasia

· Diperbarui pada: · · Passkey, WebAuthn, FIDO2, Keamanan, Autentikasi, Pencegahan phishing, Sistem informasi

Berita bahwa «kata sandi bocor dari layanan besar lain» tidak lagi mengejutkan siapa pun. Latih phishing setiap tahun, dan jumlah orang yang tertipu tidak pernah mencapai nol. «Jangan pakai ulang kata sandi, buat panjang, perubahan berkala… tidak perlu lagi» — bahkan nasihatnya pun bolak-balik.

Passkey, yang menyebar cepat dalam beberapa tahun terakhir, adalah metode autentikasi yang Apple, Google, dan Microsoft dorong bersama sebagai jawaban atas situasi ini.1 Mereka sering diperkenalkan sebagai «nyaman — Anda dapat masuk dengan sidik jari atau wajah» — tetapi itu bukan intinya. Nilai sejati passkey adalah bahwa ia memindahkan dasar keamanan dari «kewaspadaan manusia» ke «struktur protokol».

  • Kata sandi bocor karena pengguna ceroboh, jadi mari latih mereka → manusia selalu salah
  • Mari latih orang mengenali situs palsu → situs palsu yang tidak dapat dikenali dapat dibangun
  • Dengan passkey → tidak ada rahasia untuk dikirim sejak awal, dan tidak ada tanda tangan yang dapat dihasilkan di situs palsu

Artikel ini menelusuri, dengan gambar, mengapa passkey aman, mulai dari apa yang rusak pada kata sandi. Ia kemudian menjawab langsung pertanyaan yang wajar — «apakah passkey tersinkron benar-benar aman?» dan «apakah mereka punya kelemahan?» — dan menutup dengan menata pokok praktis menggelar passkey ke aplikasi web dan lingkungan Windows.

1. Intinya dulu

Alasan passkey aman terangkum pada tiga poin.

  1. Tidak ada rahasia di server. Yang disimpan server hanyalah kunci publik, yang merupakan informasi yang aman bocor. Bahkan jika seluruh basis data diekfiltrasi, tidak ada «bahan untuk menyamar» yang dapat dibawa pulang penyerang.2
  2. Rahasia tidak pernah berjalan di jaringan. Yang dikirim saat masuk hanyalah tanda tangan atas nilai acak sekali pakai (challenge). Karena kunci privat tidak pernah meninggalkan authenticator perangkat, menyadap atau merelay di mana pun di jalur tidak menghasilkan rahasia.2
  3. Tidak ada tanda tangan yang dapat dihasilkan di situs palsu. Passkey terikat ke domain situs, dan browser memaksa kecocokan domain. Bahkan jika pengguna tertipu oleh situs palsu, passkey untuk situs asli sama sekali tidak muncul sebagai kandidat, dan bahkan jika tanda tangan entah bagaimana di-relay, verifikasi akan menolaknya.3

Ketiganya bukan trik independen — semuanya konsekuensi yang mengikuti dari satu pergeseran desain: perpindahan dari autentikasi yang berbagi dan mengirim rahasia, ke autentikasi yang membuktikan kepemilikan rahasia lewat tanda tangan. Mari kita lihat berurutan.

Hubungan istilah — passkey, WebAuthn, FIDO2, dan CTAP

Bidang ini punya banyak istilah, dan artikel yang berbeda memakainya untuk cakupan yang berbeda, jadi mari paku hubungannya dulu. Passkey bukan protokol baru — ia adalah «nama» yang dilekatkan pada kombinasi standar yang sudah ada.21

Istilah Nama resmi Apa yang dirujuk
WebAuthn Web Authentication API (Rekomendasi W3C) Standar antara browser dan situs web. API yang memakai navigator.credentials untuk meminta pembuatan pasangan kunci dan penandatanganan
CTAP Client to Authenticator Protocol (FIDO Alliance) Standar antara browser dan authenticator eksternal. Bagian yang berbicara dengan security key dan ponsel lewat USB, NFC, atau Bluetooth
FIDO2 — Istilah payung untuk kerangka yang menggabungkan dua di atas. FIDO2 = WebAuthn + CTAP
Passkey — Nama yang diberikan kepada subset kredensial FIDO2 yang memungkinkan Anda masuk secara mandiri sebagai pengganti kata sandi (discoverable credentials)

Tabel 1: Passkey adalah nama yang diberikan di atas fondasi FIDO2 — ia bukan nama standar itu sendiri

Dengan kata lain, «mendukung passkey» diterjemahkan, dalam istilah implementasi, menjadi «mengimplementasikan WebAuthn». CTAP adalah lapisan yang ditangani browser dan OS atas nama Anda ketika authenticator eksternal dipakai, jadi mereka yang membangun aplikasi web tidak pernah menyentuhnya secara langsung.

Peta pengetahuan artikel ini

Passkey adalah kredensial berbasis kriptografi kunci publik yang berdiri di atas standar WebAuthn dan CTAP (bersama-sama FIDO2); kunci privat tidak keluar dari authenticator, dan yang dititipkan ke server hanyalah kunci publik yang aman bocor. Karena passkey dibuat terikat ke domain situs (RP ID), tanda tangan tidak terbentuk di situs palsu dan phishing dicegah secara struktural. Passkey tersinkron memperoleh ketahanan terhadap kehilangan dengan imbalan ketergantungan pada akun cloud, sementara tipe terikat perangkat mengurung kunci di perangkat keras. Setelah penggelaran passkey, fokus praktik menjadi pengurangan metode fallback yang masih berdampingan dan penguatan alur pemulihan akun.

Peta pengetahuan mengapa passkey amanDiagram yang menunjukkan bahwa passkey berdiri di atas WebAuthn, FIDO2, CTAP, dan kriptografi kunci publik; bahwa pengikatan domain lewat RP ID secara struktural mencegah phishing; perbedaan passkey tersinkron dan terikat perangkat beserta titik kegagalan tunggal masing-masing; posisinya sebagai MFA tahan phishing; serta hubungan risiko yang tersisa (fallback, pemulihan akun, pencurian sesi)menggunakanmenggunakanmenggunakanmenggunakanmenggunakanmenggunakanmenggunakanmenggunakanmenggunakanmenggunakanmenggunakanmensyaratkanmenggunakanmensyaratkanmencegahmencegahmencegahmengurangidapat menyebabkandapat menyebabkandapat menyebabkandapat menyebabkandapat menyebabkantidak disarankandisarankan untukmenggunakandikonfigurasi dengandisimpan ditidak kompatibeldisarankan untukdapat menyebabkandisarankan untukdapat menyebabkandisarankan untukdapat menyebabkandisarankan untukdapat menyebabkantidak disarankanpasskeyWebAuthnFIDO2kriptografi kunci publikCTAPauthenticatorTPMWindows Hellosecurity keypasskey terikat perangkatpersyaratan konteks aman (HTTPS)challenge (angka acak sekali pakai)RP ID (pengidentifikasi Relying Party)phishingphishing AiTM (man-in-the-middle)kebocoran basis data kredensialautentikasi kata sandipenggunaan ulang kata sandi (serangan berbasis daftar)pengambilalihan akunpencurian cookie sesione-time password (TOTP)MFA tahan phishingMicrosoft Entra IDpasskey tersinkronbrankas kredensial platformNIST AAL3 (Authenticator Assurance Level 3)penguatan perlindungan akun platformpenyalahgunaan alur pemulihan akunpenguatan verifikasi identitas pada alur pemulihanmetode autentikasi fallback yang masih berdampinganpengurangan terencana metode fallback

Pada diagram, garis utuh menunjukkan relasi yang selalu berlaku dan garis putus-putus menunjukkan relasi bersyarat (syaratnya ada pada penjelasan masing-masing relasi di halaman rincian). Daftar lengkap relasi (total 38, beserta bukti dan tingkat kepastian) serta definisi konsep utama dikumpulkan di halaman rincian peta pengetahuan (dalam bahasa Jepang). Data: JSON-LD / Turtle

2. Apa yang rusak pada autentikasi kata sandi

Jalan pintas memahami mengapa passkey aman adalah memikirkan kelemahan kata sandi dalam istilah «lokasi». Dengan autentikasi kata sandi, rahasia itu sendiri menempuh seluruh jalur setiap kali Anda mengautentikasi.

ServerBrowserPenggunaServerBrowserPenggunaMemegang rahasia (kata sandi) di kepala【Kelemahan ①】Dapat ditebak / dipakai ulang antar situs【Kelemahan ②】Dapat dimasukkan ke situs palsudengan cara yang sama (tidak dapat dibedakan secara visual)【Kelemahan ③】Rahasia mengalir di jalurDilindungi TLS tetapi di ujung kembali menjadi plaintext【Kelemahan ④】Rahasia (hash-nya) semua pengguna terakumulasiJika bocor, menjadi sasaran brute force offlineMemasukkan kata sandiMengirim kata sandi itu sendiriMencocokkan dengan hash yang tersimpan

Gambar 1: Dengan autentikasi kata sandi, rahasia itu sendiri ada di seluruh jalur.

Dari sudut penyerang, ini adalah struktur yang punya banyak sasaran dan mudah ditembak.

  • Kelemahan ① (pengguna): Hanya sekuat yang dapat diingat, dan dipakai ulang di beberapa situs. Satu kebocoran merambat ke semua akun (serangan berbasis daftar kata sandi).
  • Kelemahan ② (saat memasukkan): Siapkan situs palsu yang tidak dapat dibedakan dari yang asli, dan pengguna sendiri yang menyerahkan rahasianya (phishing).
  • Kelemahan ③ (jalur): Karena ada TLS, menyadap jalur itu sendiri sulit, tetapi menyisipkan «titik relay yang tampak sah» membuatnya tidak berarti (AiTM yang dibahas kemudian).
  • Kelemahan ④ (server): Bahkan jika di-hash lalu disimpan, jika basis data bocor, ia dapat di-brute force secara offline. Kata sandi lemah pecah lebih dulu.

«Kalau begitu tambahkan one-time code (SMS atau TOTP)» adalah autentikasi multi-faktor tradisional, tetapi ini pun struktur mengirim rahasia yang dibagi tidak berubah. TOTP adalah server dan aplikasi authenticator yang berbagi seed (rahasia) yang sama, dan kode 6 digit yang dihasilkan pada akhirnya tetap dapat dimasukkan pengguna ke situs palsu. Sebenarnya, phishing tipe AiTM (Adversary-in-the-Middle) di mana situs palsu merelay ke server asli secara real time menembus pasangan kata sandi + one-time code dengan mengalirkannya apa adanya. Yang dicantumkan CISA (badan siber AS) sebagai «MFA tahan phishing» hanyalah dua: metode FIDO/WebAuthn, dan autentikasi berbasis PKI seperti kartu pintar (PIV/CAC); di antara keduanya FIDO diposisikan sebagai standar emas, justru karena ini.4

Jadi masalahnya bukan «kekuatan» kata sandi, melainkan struktur «berbagi rahasia, dan mengirimnya setiap kali autentikasi» itu sendiri.

3. Identitas passkey — membuktikan kepemilikan tanpa mengirim rahasia

Passkey adalah kredensial berbasis kriptografi kunci publik yang berdiri di atas dua standar, WebAuthn W3C dan CTAP FIDO Alliance (bersama-sama FIDO2).21 Kedengarannya sulit, tetapi strukturnya sederhana.

ServerPerangkat penggunaPencocokan lokalPasangan matematis(sisi yang membuat tanda tangan)Kunci publikaman bocorinformasi «khusus verifikasi»Authenticator (brankas)Windows Hello / Face ID /kunci layar Android / security keyKunci privattidak pernah keluar dari siniSidik jari / wajah / PIN= hanya membuka pintu brankasini pun tidak keluar

Gambar 2: Identitas passkey adalah pasangan kunci per situs. Sisi rahasia tidak keluar dari perangkat, dan server hanya memegang kunci publik untuk verifikasi.

  • Kunci privat adalah kunci sisi yang dapat membuat tanda tangan, disimpan di authenticator di dalam perangkat (Windows Hello, Face ID/Touch ID iPhone, kunci layar Android, atau security key seperti YubiKey), dan tidak keluar.
  • Kunci publik adalah kunci sisi yang hanya dapat memverifikasi tanda tangan, dan ini yang dititipkan ke server. Menghitung balik kunci privat dari kunci publik secara komputasi mustahil, jadi ini informasi yang boleh bocor.
  • Data biometrik seperti sidik jari atau wajah dipakai hanya untuk membuka pintu brankas secara lokal, dan ini pun tidak keluar dari perangkat. Data biometrik tidak dikirim ke server.1

Pendaftaran: menyerahkan «hanya» kunci publik

Alur ketika mendaftarkan passkey ke situs.

AuthenticatorBrowserServer (example.com)AuthenticatorBrowserServer (example.com)Yang diterima server hanyalah«informasi yang aman bocor»Permintaan pendaftaran (challenge acak + info situs)Buat kunci untuk situs ini (example.com)Verifikasi identitas dengan sidik jari / wajah / PIN (lokal)Menghasilkan pasangan kunci barukunci privat disimpan di dalamKunci publik + credential ID (label kunci)Mengirim kunci publik + credential IDMenyimpan sebagai kunci publik akun ini

Gambar 3: Saat pendaftaran, yang mengalir di jaringan dan disimpan di server hanyalah kunci publik.

Yang penting adalah bahwa pada saat ini pasangan kunci dibuat terikat ke domain situs (RP ID). Passkey yang dibuat untuk example.com hanya dapat dipakai di situs example.com (karena RP ID per domain, halaman subdomain di bawah domain yang sama seperti login.example.com dapat memakainya, tetapi domain yang tidak terkait tidak dapat). Pengikatan ini menjadi fondasi ketahanan phishing yang dibahas kemudian.3

Selain itu, pasangan kunci dibuat baru setiap kali, per situs. Passkey situs A dan situs B tidak terkait secara matematis, jadi konsep «penggunaan ulang» sendiri tidak ada, dan tidak menjadi bahan untuk mencocokkan pengguna antar situs.

Autentikasi: mengembalikan tanda tangan sekali pakai

Alur saat masuk. Bandingkan dengan autentikasi kata sandi (Gambar 1).

AuthenticatorBrowserServer (example.com)AuthenticatorBrowserServer (example.com)Yang mengalir di jalur hanyalah tanda tangan sekali pakaimeski dicuri, tidak dapat dipakai untuk challenge berikutnyaPermintaan masuk (challenge acak sekali pakai)Permintaan tanda tangan ke example.comVerifikasi identitas dengan sidik jari / wajah / PIN (lokal)Membuat tanda tangan dengan kunci privatmenanamkan challenge + origin + hash RP IDTanda tangan (bukan kunci privat itu sendiri)Mengirim tanda tanganMemverifikasi tanda tangan dengan kunci publik yang tersimpanjuga mengonfirmasi challenge, origin, dan RP ID

Gambar 4: Saat autentikasi pun rahasia tidak bergerak. Yang mengalir hanyalah «dokumen bukti sekali pakai».

Server setiap kali mengajukan angka acak baru (challenge), dan authenticator menandatangani «challenge itu + origin yang sedang dilihat browser + hash RP ID». Server memverifikasi tanda tangan dengan kunci publik yang tersimpan, dan mengonfirmasi bahwa challenge adalah yang ia ajukan sendiri, serta bahwa origin dan RP ID adalah milik situsnya sendiri.5

Sebagai konsekuensi desain ini, dua dari tiga alasan di awal sudah terbentuk.

  • Tidak ada rahasia di server: yang tersimpan hanyalah kunci publik. Meski bocor, penyerang tidak dapat membuat tanda tangan, jadi tidak dapat «dibawa pulang lalu dipecahkan» seperti hash kata sandi.
  • Rahasia tidak mengalir: meski tanda tangan di jalur dicuri, challenge sekali pakai jadi tidak dapat dipakai ulang (replay).

Yang tersisa, «tanda tangan tidak terbentuk di situs palsu», adalah keunggulan terbesar passkey. Kita pisahkan ke bab sendiri.

4. Alasan phishing «secara struktural» tidak terbentuk

Phishing terhadap kata sandi berhasil karena rahasia asli dapat dimasukkan ke situs palsu. Manusia tidak (terutama saat lelah) dapat membedakan example.com dan examp1e.com, tetapi kolom input kata sandi bekerja sama di kedua situs.

Dengan passkey, pencocokan ini dilakukan secara mekanis oleh browser, bukan manusia. Menurut spesifikasi WebAuthn, browser hanya dapat memanggil authenticator ketika «domain origin yang sedang ditampilkan» dan «RP ID passkey» saling sesuai.3 Berikut apa yang terjadi pada saat mengakses situs palsu.

Server asli (example.com)Situs palsu (examp1e.com)proksi AiTM yang merelay ke yang asliBrowserPenggunaServer asli (example.com)Situs palsu (examp1e.com)proksi AiTM yang merelay ke yang asliBrowserPenggunaBahkan jika tanda tangan entah bagaimana dibuat,examp1e.com tertanam di tanda tangan sehinggaverifikasi server asli pasti gagalMengakses layar masuk yang tampak identik(Di belakang) memulai proses masuk asliChallengeMengalirkan challenge dan meminta tanda tanganOrigin saat ini adalah examp1e.compasskey untuk example.com tidak dapat dijadikan kandidatTanda tangan tidak dibuat (pengguna tidak punya cara tertipu)

Gambar 5: Phishing tipe AiTM menembus kata sandi + one-time code, tetapi dengan passkey ia gagal di tahap tanda tangan.

Perhatikan bahwa pertahanan berlapis dua.

  1. Tidak muncul sebagai kandidat: browser hanya mencantumkan passkey dengan RP ID yang sesuai origin. Di domain palsu, passkey untuk situs asli tidak muncul sebagai pilihan, jadi pengguna bahkan tidak dapat «tidak sengaja memakainya».
  2. Tanda tangan tidak lolos: sasaran tanda tangan mencakup origin yang dikonfirmasi browser dan hash RP ID. Server asli mencocokkan ini saat verifikasi, jadi tanda tangan yang dibuat di origin lain pasti ditolak.5

Penanggulangan phishing kata sandi bergantung pada usaha manusia «pengguna melihat URL dengan saksama». Dengan passkey, pengguna tidak perlu mengenali situs palsu sejak awal. Inilah arti tepat «tahan phishing (phishing-resistant)», dan alasan CISA serta NIST (National Institute of Standards and Technology AS) memperlakukan metode FIDO/WebAuthn secara khusus.46

Isi sampai di sini, ditata per teknik serangan.

Serangan Kata sandi Kata sandi + TOTP Passkey
Tebakan / brute force ✗ Lemah △ Kode mencegah, tetapi kata sandi asalnya tetap lemah ○ Tidak ada sasaran tebakan
Penggunaan ulang (serangan berbasis daftar) ✗ Satu kebocoran merambat ke seluruhnya △ Runtuh dari situs yang tidak mendukung kode ○ Kunci independen per situs
Kebocoran DB server ✗ Hash di-brute force secara offline ✗ Seed TOTP (rahasia bersama) juga bocor ○ Hanya ada kunci publik
Phishing klasik (memasukkan di situs palsu) ✗ Dapat dimasukkan ✗ Kode juga dapat dimasukkan ○ Tidak muncul sebagai kandidat, tanda tangan pun tidak lolos
AiTM (relay real time) ✗ Dialirkan apa adanya ✗ Kode ikut dialirkan ○ Tanda tangan tidak terbentuk karena pencocokan origin
Replay (pemakaian ulang komunikasi) ✗ Kata sandi yang sama berlaku berkali-kali △ Kode yang diserobot sebelum dipakai pemilik masih berlaku (penerimaan ulang kode terpakai ditolak pada implementasi yang benar) ○ Challenge setiap kali sekali pakai

Tabel 2: Perbandingan ketahanan per teknik serangan. Setiap «○» passkey berasal dari struktur, bukan dari operasi atau kewaspadaan.

5. Apakah «passkey yang disinkronkan» aman?

Membaca penjelasan sampai di sini, pertanyaan ini wajar muncul. «Anda bilang kunci privat tidak keluar dari perangkat, lalu mengapa passkey yang dibuat di iPhone dapat dipakai di iPad?» — pertanyaan bagus, dan jawabannya adalah «ada dua jenis passkey».

Kesimpulan dulu sebagai tabel cepat. Bab ini dan bab berikutnya menjelaskan mengapa setiap baris tabel itu menjadi demikian.

Sudut pandang Passkey tersinkron Passkey terikat perangkat
Contoh representatif iCloud Keychain, Google Password Manager, pengelola kata sandi seperti 1Password Security key (YubiKey dll.), Windows Hello, passkey di dalam Microsoft Authenticator
Tempat penyimpanan kunci privat Brankas kredensial platform. Direplikasi antar perangkat akun yang sama dalam bentuk terenkripsi end-to-end Di dalam perangkat keras authenticator. Tidak keluar ke luar TPM atau secure element
Saat hilang / ganti perangkat Dapat dipulihkan ke perangkat baru dengan masuk ke Apple ID / akun Google yang sama Passkey authenticator itu hilang. Pendaftaran beberapa authenticator cadangan adalah prasyarat
Titik kegagalan tunggal Akun cloud platform Perangkat fisik itu sendiri
Kecocokan pengelolaan korporat Karena kunci masuk ke akun cloud pribadi, organisasi sulit menelusuri lokasi atau mencabut secara massal. Cocok untuk BYOD atau skala kecil Administrator dapat mendistribusikan dan mencabut, lokasi kunci jelas. Cocok untuk lingkungan dengan aturan ketat
Kesesuaian AAL NIST AAL2 jika syarat terpenuhi. Tidak dapat dipakai untuk AAL3 karena kunci privat dapat diekspor6 Authenticator yang dilindungi perangkat keras dan kuncinya tidak dapat diambil dapat juga memenuhi syarat yang diminta AAL36

Tabel 3: Tabel cepat passkey tersinkron vs terikat perangkat. Mana yang dipilih diputuskan dari mana yang diambil: «ketahanan terhadap kehilangan» atau «dapat mengelola lokasi kunci».

Passkey terikat perangkatSecurity key (YubiKey dll.) /Windows Hello /Microsoft Authenticator (Entra ID)Kunci privat tidak keluar secara fisikdari perangkat keras itu (dilindungi TPM dll.)Kelebihan: lokasi kunci jelas di satu tempatPerhatian: beberapa pendaftaran wajib sebagai cadangan kehilanganPasskey tersinkron (default untuk konsumen)iCloud Keychain /Google Password Manager /pengelola kata sandi seperti 1PasswordSinkron terenkripsi end-to-endantar perangkat akun yang samapenyedia pun tidak dapat membaca isinyaKelebihan: kuat terhadap ganti perangkat / kehilanganPerhatian: pertahanan akun cloud itu sendiri diperlukan

Gambar 6: Tersinkron vs terikat perangkat. Keduanya sama di poin «tidak mengirim kunci privat ke server»; yang berbeda adalah pusat berat cara menjaganya.

Passkey tersinkron adalah yang iCloud Keychain atau Google Password Manager menyinkronkan kunci privat antar perangkat akun yang sama. Yang penting di sini adalah bahwa sinkronisasi dienkripsi end-to-end. Apple maupun Google menyatakan dengan tegas bahwa passkey dienkripsi di perangkat lalu disinkronkan, dan penyedia sendiri tidak dapat membaca isinya.78 Dengan kata lain, prinsip «kunci privat tidak keluar dari perangkat» secara tepat dilonggarkan menjadi «kunci privat tidak keluar dari perangkat dalam bentuk plaintext», dan sebagai gantinya diperoleh ketahanan terhadap ganti perangkat dan kehilangan.

Bagaimana pelonggaran ini mengubah model ancaman harus diucapkan dengan jelas. Tempat yang harus dijaga terpusat dari «server tiap situs» ke «satu akun cloud». Ketahanan terhadap kebocoran DB tiap situs dan phishing tetap kuat, tetapi kini pengambilalihan Apple ID / akun Google itu sendiri menjadi titik kegagalan tunggal. Itulah sebabnya prasyarat besar adalah menaruh perlindungan terkuat (kunci layar yang kuat, penataan sarana pemulihan, jika mungkin physical security key) pada akun platform tempat passkey dititipkan. NIST juga pada April 2024 mengeluarkan suplemen NIST SP 800-63B (Supplement 1: Incorporating Syncable Authenticators Into NIST SP 800-63B), dan secara resmi memposisikan bahwa passkey tersinkron ini (syncable authenticator) dapat memenuhi AAL2 (Authenticator Assurance Level 2) standar pemerintah jika syarat terpenuhi. Namun, karena kunci privat dapat diekspor, ditetapkan bahwa tipe tersinkron tidak dipakai untuk AAL3 yang menuntut lingkungan terisolasi perangkat keras.6

Passkey terikat perangkat adalah tipe yang kunci privatnya tidak keluar dari perangkat keras. Security key seperti YubiKey adalah contoh khas, dan di sisi korporat passkey Microsoft Entra ID (yang dibuat di dalam Microsoft Authenticator) juga terikat perangkat.9 Windows Hello Windows pun, jika ada TPM, melindungi kunci privat di bawah TPM. Mekanisme «brankas perangkat keras yang tidak mengeluarkan kunci» ini sendiri berdiri di atas fondasi yang sama dengan yang dijelaskan secara rinci di artikel TPM.

Selain itu, Anda mungkin pernah heran diminta memindai kode QR saat «masuk ke browser PC dengan passkey ponsel». Itu bukan sekadar transisi layar, melainkan metode hibrida (autentikasi lintas perangkat FIDO) yang mengonfirmasi kedekatan fisik ponsel dan PC lewat Bluetooth. Serangan di mana penyerang jarak jauh membuat orang lain menyetujui masuk ke PC penyerang lewat kode QR dihancurkan oleh konfirmasi kedekatan.1

6. Bukan peluru perak — kelemahan tidak «hilang», melainkan «berpindah»

Sampai di sini kita menjelaskan kekuatan passkey, tetapi secara jujur, passkey bukan teknologi yang menghilangkan serangan melainkan yang mendorong penyerang ke tempat yang lebih lemah. Berikut diagram ke mana penyerang berputar ketika pintu depan autentikasi mengeras.

PenyerangAutentikasi itu sendiritanda tangan challenge【keras】Alur pemulihan akunmengaku «kehilangan passkey» lalumemaksa penyiapan ulang lewat SMS atau email,dan mendaftarkan passkey penyerangFallback yang masih berdampinganjika masuk kata sandi / SMS masih ada,mata rantai terlemah ada di situAkun clouduntuk tipe tersinkron, Apple ID /akun Google adalah titik kegagalan tunggalSesijika Cookie setelah masuk dicuri,metode autentikasi tidak relevan

Gambar 7: Ketika pintu depan (autentikasi) mengeras, serangan pindah ke alur pemulihan, sarana yang masih berdampingan, akun cloud, dan sesi.

Risiko yang tersisa yang perlu dipegang dalam praktik ada empat.

  1. Fallback yang masih berdampingan menjadi mata rantai terlemah. Jika Anda hanya membuat passkey «juga» dapat dipakai, sementara masuk kata sandi atau SMS masih ada, penyerang hanya memakai yang itu. Ketahanan phishing, dilihat dari akun secara keseluruhan, dibatasi pada tingkat sarana masuk yang paling lemah. Inti penggelaran bukan menambah passkey, melainkan pengurangan dan penghapusan terencana fallback.
  2. Alur pemulihan menjadi permukaan serangan baru. Trik mengaku «kehilangan perangkat» lalu membawa ke penyiapan ulang lewat meja dukungan atau email, dan mendaftarkan passkey penyerang sendiri. Sebenarnya, rekayasa sosial yang menipu help desk untuk menghindari autentikasi yang kuat sudah menjadi cara standar pelanggaran berskala besar. Karena autentikasi dikeraskan, yang dipertanyakan adalah bagaimana merancang verifikasi identitas pada alur pemulihan.
  3. Pada tipe tersinkron, akun cloud adalah titik kegagalan tunggal. Seperti bab sebelumnya. Pertahanan akun tempat passkey dititipkan, dan untuk pemakaian organisasi kebijakan «sinkronisasi ke platform mana yang diizinkan», diperlukan.
  4. Pencurian sesi tidak dapat dicegah. Passkey hanya menjaga momen masuk; jika cookie sesi setelah masuk dicuri lewat malware atau XSS, metode autentikasi tidak relevan. Pekerjaan lapisan lain — masa berlaku token, binding, pengelolaan kesehatan perangkat — tetap ada.

Ini bukan cerita «jadi jangan pakai passkey». Ini cerita biasa bahwa mengunci pintu depan ke yang terbaru tidak menggantikan mengunci jendela. Justru karena lokasi kelemahan menjadi jelas, sumber daya pertahanan dapat dikonsentrasikan ke alur pemulihan dan pengelolaan sesi.

7. Penggelaran dalam praktik — WebAuthn API dan lingkungan Windows

Terakhir, kita paku pokok dari sudut pihak yang menggelar.

Menambahkan masuk passkey ke layanan web sendiri

Di sisi browser hanya dua fungsi WebAuthn API. Pendaftaran memanggil navigator.credentials.create(), autentikasi memanggil navigator.credentials.get().

// Pendaftaran (sisi browser)
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: challengeFromServer,   // Angka acak sekali pakai yang dihasilkan server
    rp: { id: "example.com", name: "Example" },
    user: { id: userIdBytes, name: "taro@example.com", displayName: "Taro" },
    pubKeyCredParams: [{ type: "public-key", alg: -7 }],  // ES256
    authenticatorSelection: {
      residentKey: "required",        // Jadikan discoverable credential (= passkey)
      userVerification: "required",   // Wajibkan verifikasi identitas lewat biometrik/PIN
    },
  },
});
// Kunci publik diambil dari credential.response, dan credential ID dari
// credential.id / credential.rawId di tingkat atas. Respons pendaftaran
// juga harus diverifikasi di sisi server (challenge, origin, RP ID)
// sebelum disimpan, seperti saat autentikasi

Arti parameter utama adalah sebagai berikut.

Parameter Peran Perhatian saat implementasi
challenge Angka acak sekali pakai yang dihasilkan server setiap kali Pakai angka acak kriptografis yang tidak dapat ditebak. Verifikasi di sisi server bahwa itu «yang belum terpakai yang Anda terbitkan sendiri», lalu konsumsi
rp.id Domain (RP ID) yang mengikat kredensial Jika dihilangkan, menjadi domain efektif origin pemanggil. Hanya dapat ditetapkan dalam rentang domain yang dapat didaftarkan, seperti menetapkan example.com dari login.example.com
user.id Pengidentifikasi pengguna internal server (user handle) Nilai buram maksimal 64 byte. Jangan memasukkan informasi yang dapat mengidentifikasi individu seperti alamat email atau nama pengguna apa adanya2
user.name / user.displayName String yang ditampilkan di UI authenticator atau browser agar pengguna memilih akun Khusus tampilan. Server tidak boleh mempercayai nilai ini untuk mengidentifikasi akun
pubKeyCredParams Mencantumkan algoritma kunci publik yang diterima menurut prioritas Selain -7 (ES256), mencantumkan juga -257 (RS256) memperluas jangkauan authenticator yang diterima
authenticatorSelection Sifat yang diminta dari authenticator residentKey: "required" membuatnya passkey (discoverable credential), userVerification: "required" membuat verifikasi identitas lewat biometrik/PIN wajib

Tabel 4: Parameter utama navigator.credentials.create().

Perhatian lingkungan verifikasi: WebAuthn API hanya dipublikasikan di konteks aman, jadi pemanggilan navigator.credentials gagal di halaman yang dilayani dengan http:// biasa. Pengecualiannya adalah http://localhost (serta 127.0.0.1); ini diperlakukan sebagai origin terpercaya, jadi di mesin pengembangan Anda dapat mencobanya tanpa HTTPS. Namun RP ID harus domain efektif origin (atau domain induknya), jadi passkey yang dibuat di localhost tidak dapat dipakai di domain produksi. Bahkan tanpa authenticator di tangan, mengaktifkan authenticator virtual di tab «WebAuthn» alat pengembang Chrome memungkinkan menjalankan dari pendaftaran sampai autentikasi.

// Autentikasi (sisi browser)
const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: challengeFromServer,
    rpId: "example.com",
    userVerification: "required",
  },
  // Tawarkan passkey sebagai kandidat pengisian otomatis di kolom masuk.
  // Konfirmasikan dukungan lebih dulu dengan
  // PublicKeyCredential.isConditionalMediationAvailable(), dan pada browser
  // yang tidak mendukung, kembali ke pemanggilan biasa tanpa mediation
  mediation: "conditional",
  // (<input> sasaran memerlukan autocomplete="username webauthn")
});
// Verifikasi tanda tangan di assertion.response di sisi server

Intinya adalah verifikasi di sisi server. Minimal, lakukan yang berikut tanpa kecuali.5

  • Pencocokan challenge: apakah challenge yang belum terpakai yang Anda terbitkan sendiri. Apakah dijadikan sekali pakai (penanggulangan replay). Lebih jauh, simpan terikat ke sesi browser (percobaan masuk) saat diterbitkan, dan izinkan konsumsi hanya pada respons dari sesi yang sama. Jika longgar di sini, ruang muncul bagi penyerang mengirim tanda tangan atas challenge yang ditujukan kepada mereka sendiri lewat browser korban, dan membuat korban masuk ke akun penyerang (login CSRF).
  • Pencocokan origin: apakah origin di clientDataJSON adalah origin sah situs sendiri (poros penanggulangan phishing).
  • Pencocokan hash RP ID: apakah rpIdHash di authenticatorData cocok dengan SHA-256 RP ID situs sendiri.
  • Konfirmasi jenis upacara dan bendera: apakah type di clientDataJSON adalah webauthn.get untuk autentikasi, webauthn.create untuk pendaftaran. Apakah bendera UP (user present) di authenticatorData berdiri. Jika user verification (UV) diminta, apakah bendera UV juga berdiri.
  • Verifikasi tanda tangan: apakah tanda tangan diverifikasi dengan benar dengan kunci publik yang disimpan saat pendaftaran.
  • Pengikatan ke akun: apakah credential ID (dan userHandle) yang disajikan ditarik di basis data sendiri, dan sesi diterbitkan kepada pemilik kredensial itu. Mempercayai nama pengguna yang dimasukkan secara terpisah tanpa syarat menjadi lubang yang membuat tanda tangan yang benar masuk sebagai orang lain.
  • Penyimpanan dan perbandingan penghitung tanda tangan: simpan signCount di authenticatorData per kredensial, dan konfirmasikan bahwa nilai berikutnya lebih besar dari sebelumnya. Jika sama atau lebih kecil dari nilai sebelumnya (termasuk sama), perlakukan sebagai tanda duplikasi (klon) authenticator. Namun passkey tersinkron sering mengembalikan 0 selalu, jadi 0 dengan 0 saja dikecualikan sebagai pengecualian.

Menulis verifikasi ini dengan tangan adalah sumber kecelakaan, jadi pakailah pustaka yang sudah terbukti (.NET: fido2-net-lib, Node.js: SimpleWebAuthn, dll.). Detail spesifikasi (penguraian CBOR, kesepakatan algoritma, pengelolaan challenge) diserahkan ke pustaka, dan kita sendiri berkonsentrasi pada penyimpanan dan pencabutan challenge, UI pengelolaan beberapa passkey, dan desain alur pemulihan — itulah pembagian tenaga yang benar.

Kasus lingkungan Windows dan sistem internal

Dari posisi «yang memegang sistem bisnis Windows» yang menjadi pembaca situs ini, tiga poin berikut sudah cukup.

  • Klien Windows sudah mendukung. Windows 11 mendukung pembuatan, pemakaian, dan pengelolaan passkey (Pengaturan > Akun > Passkey) dengan Windows Hello sebagai authenticator, dan kunci privat dilindungi perangkat keras jika ada TPM.10 WebAuthn lewat browser (Edge/Chrome) juga berjalan di Windows 10.
  • Di lingkungan Entra ID, aktifkan «passkey = metode autentikasi FIDO2». Microsoft Entra ID mendukung security key dan passkey di dalam aplikasi Microsoft Authenticator (terikat perangkat), dan jika Anda menuntut «MFA tahan phishing» dengan kekuatan autentikasi akses bersyarat, akses ke sumber daya sasaran dapat dibatasi ke passkey dan sejenisnya.9 Migrasi dari dunia NTLM dan kebijakan kedaluwarsa kata sandi tidak maju dalam satu lompatan, jadi praktik standar adalah, bersamaan dengan inventaris fondasi autentikasi yang dibahas di artikel NTLM dan Kerberos, mewajibkan MFA tahan phishing mulai dari akun administrator dulu.
  • Manfaatnya sama di aplikasi web internal. Namun HTTPS adalah prasyarat. WebAuthn API hanya berjalan di konteks aman, jadi bahkan di aplikasi intranet (kecuali localhost saat pengembangan) HTTPS-isasi dan penataan nama domain internal yang dapat dipakai sebagai RP ID adalah keputusan awal. Begitu itu selesai, RP ID berfungsi juga terhadap domain internal. Dalam arti berpisah dari stiker kata sandi, tidak jarang efeknya muncul lebih cepat di internal daripada di layanan ke luar.

8. Ringkasan

  • Kelemahan kata sandi bukan kekuatan, melainkan struktur «berbagi rahasia, dan mengirimnya setiap kali autentikasi». Karena rahasia ada di pengguna, kolom input, jalur, dan server semuanya, sasaran serangan banyak. Menambah one-time code pun kalah di-relay oleh phishing tipe AiTM.
  • Passkey adalah pasangan kunci kriptografi kunci publik per situs, menyerahkan ke server hanya kunci publik yang aman bocor, dan saat masuk hanya mengirim tanda tangan atas challenge sekali pakai. Tidak ada rahasia di server, dan tidak ada rahasia yang mengalir di jalur.
  • Origin dan RP ID yang dikonfirmasi browser tertanam di tanda tangan, jadi di situs palsu passkey untuk yang asli tidak muncul sebagai kandidat, dan meski di-relay verifikasi gagal. Pengguna tidak perlu mengenali situs palsu adalah identitas «ketahanan phishing», dan dasar pertahanan pindah dari kewaspadaan manusia ke struktur protokol.
  • Passkey tersinkron disinkronkan dengan enkripsi end-to-end, kuat terhadap ganti perangkat dan kehilangan. Sebagai gantinya tempat yang harus dijaga terpusat ke akun cloud, jadi pertahanan Apple ID / akun Google itu sendiri menjadi prasyarat besar. Korporat juga dapat memilih tipe terikat perangkat (security key, passkey Authenticator Entra ID).
  • Passkey tidak menghilangkan serangan melainkan mendorongnya ke tempat yang lemah. Kata sandi yang masih berdampingan, alur pemulihan akun, dan pencurian sesi adalah permukaan serangan yang tersisa, dan inti penggelaran ada pada pengurangan terencana fallback dan penguatan alur pemulihan.
  • Implementasi adalah dua fungsi create / get WebAuthn API + verifikasi server. Jangan membuat verifikasi sendiri; serahkan ke pustaka yang terbukti, dan alokasikan tenaga ke pengelolaan challenge, UI beberapa passkey, dan desain pemulihan.

Artikel terkait

Area konsultasi terkait

KomuraSoft LLC menangani Custom Software Development yang mencakup dukungan implementasi WebAuthn masuk passkey ke sistem web internal, desain penggelaran MFA tahan phishing di lingkungan Entra ID, dan penyematan autentikasi ke aplikasi bisnis Windows seperti WinForms/WPF.

  1. FIDO Alliance, Passkeys dan How FIDO Works. Tentang passkey sebagai kredensial FIDO yang menggantikan kata sandi; data biometrik yang tidak dikirim dari perangkat dan hanya dipakai untuk pencocokan lokal; pernyataan bersama Apple, Google, dan Microsoft pada Mei 2022 untuk memperluas dukungan passwordless lewat standar FIDO; dan bahwa pemakaian lintas perangkat (cross-device) memakai metode hibrida dengan konfirmasi kedekatan lewat kode QR dan Bluetooth. ↩ ↩2 ↩3 ↩4 ↩5

  2. W3C, Web Authentication: An API for accessing Public Key Credentials Level 2 (Rekomendasi W3C). Tentang WebAuthn sebagai API untuk membuat dan memakai kredensial berbasis kriptografi kunci publik; kunci privat kredensial yang dipegang authenticator dan hanya kunci publik serta credential ID yang didaftarkan ke server (Relying Party); autentikasi yang dilakukan lewat tanda tangan (assertion) atas challenge yang dikirim server; dan tujuan desain cakupan serta perlindungan kredensial. Juga dirujuk di teks bahwa API hanya dipublikasikan di konteks aman; RP ID jika dihilangkan menjadi domain efektif origin pemanggil; dan user handle (user.id) adalah nilai buram maksimal 64 byte yang tidak boleh berisi informasi yang mengidentifikasi individu seperti nama pengguna atau alamat email (§14.6.1 User Handle Contents). ↩ ↩2 ↩3 ↩4 ↩5

  3. W3C, Web Authentication Level 2 — §5.1.3 Create / RP ID validation, §13.4.9 Regarding phishing. Tentang kredensial kunci publik yang dicakup ke RP ID (pengidentifikasi Relying Party = domain); browser (klien) yang memverifikasi kesesuaian domain yang dapat didaftarkan dari origin pemanggil dengan RP ID, dan menolak pembuatan serta pemakaian kredensial jika tidak sesuai; dan bahwa dari origin palsu kredensial untuk situs lain tidak dapat diakses, sehingga WebAuthn memiliki ketahanan terhadap serangan phishing termasuk tipe man-in-the-middle. ↩ ↩2 ↩3

  4. CISA, Implementing Phishing-Resistant MFA (lembar fakta Oktober 2022). Tentang MFA yang memakai SMS, suara, pemberitahuan dorong, atau OTP yang rentan terhadap phishing, serangan AiTM (relay), dan serangan kelelahan MFA; metode tahan phishing yang dicantumkan sebagai autentikasi FIDO/WebAuthn dan autentikasi berbasis PKI (kartu pintar dll.), dengan autentikasi FIDO/WebAuthn diposisikan sebagai standar emas; dan bahwa organisasi harus bermigrasi ke MFA tahan phishing mulai dari akun berisiko tinggi. ↩ ↩2

  5. W3C, Web Authentication Level 2 — §7.2 Verifying an Authentication Assertion. Tentang prosedur verifikasi sisi server yang menetapkan verifikasi type, challenge (kecocokan dengan yang diterbitkan sendiri), dan origin di clientDataJSON; verifikasi bahwa rpIdHash di authenticatorData cocok dengan hash SHA-256 RP ID yang diharapkan; konfirmasi bendera User Present / User Verified; dan verifikasi tanda tangan dengan kunci publik yang tersimpan. ↩ ↩2 ↩3

  6. NIST, Incorporating Syncable Authenticators Into NIST SP 800-63B (suplemen April 2024, diintegrasikan ke SP 800-63B edisi ke-4). Tentang authenticator yang dapat disinkronkan (passkey tersinkron) yang dapat memenuhi AAL2 ketika kunci privatnya disimpan dan direplikasi di kain sinkronisasi dengan cara yang memenuhi syarat; di sisi lain authenticator kriptografis AAL3 menuntut lingkungan yang dilindungi dan diisolasi perangkat keras, jadi authenticator tersinkron yang kunci privatnya dapat diekspor tidak dipakai di AAL3; dan bahwa metode yang melakukan verifikasi origin seperti WebAuthn ditata sebagai memiliki ketahanan terhadap penyamaran verifier (ketahanan phishing). PDF asli adalah NIST SP 800-63B Supplement 1. ↩ ↩2 ↩3 ↩4

  7. Dukungan Apple, About the security of passkeys. Tentang passkey yang disinkronkan di iCloud Keychain; iCloud Keychain yang dienkripsi end-to-end dan Apple pun tidak dapat membacanya; sinkronisasi yang dilindungi oleh kunci di perangkat pengguna; dan pemulihan lewat escrow berbatas laju yang disediakan. ↩

  8. Google, Security of Passkeys in the Google Password Manager. Tentang kunci privat passkey yang dienkripsi di perangkat lalu disinkronkan; enkripsi end-to-end yang membuat Google sendiri tidak dapat mengakses isi kunci privat; dan pemulihan yang menuntut perlindungan berdasarkan kunci layar perangkat dan sejenisnya. ↩

  9. Microsoft Learn, Enable passkeys (FIDO2) for Microsoft Entra ID. Tentang Entra ID yang mendukung autentikasi passwordless tahan phishing lewat FIDO2 security key dan passkey Microsoft Authenticator (terikat perangkat); dan bahwa pengaktifan di kebijakan metode autentikasi serta permintaan lewat kekuatan autentikasi akses bersyarat (MFA tahan phishing) dimungkinkan. ↩ ↩2

  10. Microsoft Learn, Passkeys in Windows. Tentang Windows 11 yang mendukung pembuatan dan pemakaian passkey dengan Windows Hello; passkey tersimpan yang dapat dikelola dari Pengaturan > Akun > Passkey; kredensial Windows Hello yang dilindungi perangkat keras di lingkungan dengan TPM tersedia; dan passkey di perangkat seluler yang dapat dipakai lewat kode QR. ↩

Artikel terkait

Artikel terbaru dengan tag yang sama untuk mendalami topik-topik terdekat.

Topik terkait

Halaman-halaman ini menempatkan topik dalam konteks layanan dan keputusan yang lebih luas.

Pertanyaan yang sering diajukan

Pertanyaan yang sering muncul dalam konsultasi tentang topik artikel ini.

Apa perbedaan mendasar antara passkey dan kata sandi?
Kata sandi adalah mekanisme di mana pengguna dan server berbagi rahasia yang sama dan mengirim rahasia itu setiap kali masuk. Karena rahasia ada di mana-mana — di kepala pengguna, di kolom input, di jalur komunikasi, dan di basis data server — semuanya menjadi sasaran serangan. Passkey memakai pasangan kunci kriptografi kunci publik, dan kunci privat tidak pernah dikirim ke server. Dengan passkey terikat perangkat, kunci privat tidak pernah meninggalkan authenticator sama sekali; bahkan dengan passkey tersinkron ia hanya keluar dari perangkat dalam bentuk terenkripsi end-to-end. Yang disimpan server hanyalah kunci publik — informasi yang aman bocor — dan yang dikirim saat masuk hanyalah tanda tangan atas challenge sekali pakai. Dengan kata lain, rahasia bersama yang merupakan kelemahan mendasar kata sandi memang tidak ada. Di atas itu, karena pasangan kunci dibuat terpisah untuk setiap situs, gagasan penggunaan ulang pun tidak berlaku.
Apakah data biometrik (sidik jari, wajah) dikirim ke server?
Tidak. Data sidik jari atau wajah dipakai hanya untuk pencocokan lokal di dalam perangkat — untuk membuka pintu brankas yang menampung kunci privat — dan menurut desain FIDO, data biometrik tidak pernah dikirim ke luar perangkat. Yang diterima server hanyalah tanda tangan dengan bendera bahwa verifikasi identitas (user verification) terjadi; tidak berisi sidik jari itu sendiri, bahkan tidak juga vektor ciri biometrik yang diturunkan darinya. Ketika biometrik tidak dapat dipakai, PIN dapat menggantikan, dan seperti PIN Windows Hello, PIN ini pun hanya dicocokkan secara lokal di perangkat — perbedaan yang menentukan dari kata sandi adalah bahwa ia tidak pernah berjalan di jaringan.
Mengapa passkey tahan terhadap phishing?
Karena, menurut desain, pengguna tidak perlu mengenali situs palsu sejak awal. Passkey dibuat terikat ke domain situs (RP ID-nya), dan browser hanya akan menawarkan passkey yang cocok dengan domain situs yang sedang ditampilkan. Bahkan jika Anda mengunjungi domain palsu yang tampak identik dengan yang asli, passkey untuk situs asli sama sekali tidak muncul sebagai pilihan, jadi pengguna tidak punya cara untuk tertipu. Di atas itu, tanda tangan memiliki origin yang dikonfirmasi browser dan hash RP ID yang tertanam di dalamnya, jadi bahkan jika tanda tangan di-relay, verifikasi di server asli akan menolaknya. Ketidakmungkinan struktural kecelakaan yang menghantui kata sandi dan kode SMS — memasukkan kredensial asli ke situs palsu — adalah perbedaan mendasar dari penanggulangan yang mengandalkan pelatihan dan kewaspadaan.
Jika saya kehilangan ponsel, apakah saya akan terkunci dari akun?
Jika itu passkey tersinkron — yang disimpan di iCloud Keychain atau Google Password Manager — Anda dapat memulihkannya ke perangkat baru yang masuk ke Apple ID atau akun Google yang sama. Meski begitu, memulihkan brankas terenkripsi end-to-end mensyaratkan bukan hanya kata sandi akun tetapi verifikasi identitas tambahan, seperti memasukkan kunci layar (kode sandi) perangkat sebelumnya, jadi jika Anda juga kehilangan sarana pemulihan itu, pemulihan mungkin tidak mungkin. Penting untuk tidak menitipkan semuanya pada satu ponsel. Passkey terikat perangkat (security key, Windows Hello, dan sejenisnya) berbagi nasib perangkat, jadi praktik standar untuk akun penting adalah mendaftarkan lebih dari satu passkey. Sebagian besar layanan memungkinkan mendaftarkan beberapa passkey pada satu akun. Perhatikan bahwa cara menonaktifkan passkey yang hilang berbeda menurut jenisnya. Untuk passkey tersinkron, karena salinan di setiap perangkat adalah kredensial yang sama, pertama hapus perangkat yang hilang atau lakukan remote wipe di sisi akun platform untuk menonaktifkan salinan di perangkat itu (menghapus passkey di pengaturan akun layanan itu sendiri menonaktifkan salinan di semua perangkat sekaligus). Untuk passkey terikat perangkat, menghapus passkey authenticator itu di sisi layanan menonaktifkan hanya kunci yang hilang. Untuk pemakaian organisasi, penting merancang bersama «redundansi agar pengguna dapat pulih sendiri» dan «prosedur agar administrator mencabutnya saat hilang».
Apakah passkey juga punya kelemahan?
Ya. Meskipun lebih akurat dikatakan bahwa lokasi kelemahan berpindah. Karena autentikasi itu sendiri dikeraskan oleh kriptografi kunci publik, penyerang menargetkan area sekitar yang lebih lemah. Secara konkret: jika metode lama seperti kata sandi atau SMS masih berdampingan, itu tetap mata rantai terlemah; ada trik menyalahgunakan alur pemulihan akun untuk mendaftarkan passkey penyerang sendiri; dan untuk passkey tersinkron, pengambilalihan akun cloud itu sendiri menjadi titik kegagalan tunggal baru. Selain itu, serangan yang mencuri cookie sesi setelah masuk tidak dihentikan oleh passkey, jadi ancaman yang tidak terkait pun tidak tiba-tiba hilang. Menggelar ini perlu mencakup bukan hanya «menambah passkey» tetapi juga penguatan alur pemulihan dan pengurangan terencana metode fallback.

Profil penulis

Halaman perkenalan penulis artikel.

Go Komura

Direktur KomuraSoft LLC

Berspesialisasi dalam pengembangan perangkat lunak Windows, konsultasi teknis, dan investigasi bug, terutama pada proyek dengan sistem yang sudah ada dan bug yang sulit direproduksi.

Hubungi kami
Kembali ke blog