Mengapa passkey aman — mekanisme autentikasi yang tidak mengirim rahasia

Berita bahwa “lagi-lagi kata sandi bocor dari layanan besar” sudah tidak mengejutkan siapa pun. Pelatihan phishing diadakan setiap tahun, tetapi orang yang tertipu tidak pernah mencapai nol. “Jangan memakai ulang kata sandi, buat yang panjang, ganti berkala… tidak perlu lagi” — nasihatnya sendiri pun bolak-balik.

Passkey, yang menyebar cepat dalam beberapa tahun terakhir, adalah metode autentikasi yang didorong bersama oleh Apple, Google, dan Microsoft sebagai jawaban atas situasi ini.¹ Passkey sering diperkenalkan sebagai “nyaman karena bisa masuk dengan sidik jari atau wajah”, tetapi itu bukan intinya. Nilai sejati passkey adalah memindahkan dasar keamanan dari kewaspadaan manusia ke struktur protokol.

• Kata sandi bocor karena pengguna ceroboh, jadi latih mereka → manusia pasti salah
• Latih orang agar dapat mengenali situs palsu → situs palsu yang tidak dapat dikenali tetap dapat dibuat
• Dengan passkey → tidak ada rahasia yang dikirim, dan tanda tangan tidak terbentuk di situs palsu

Artikel ini menelusuri mengapa passkey aman, mulai dari apa yang rusak pada kata sandi, lalu merangkumnya dengan diagram. Setelah itu, pertanyaan yang wajar dijawab secara langsung: apakah passkey yang disinkronkan benar-benar aman, dan apakah ada kelemahan. Di bagian akhir, pokok praktis penerapan ke aplikasi web dan lingkungan Windows disusun.

1. Kesimpulan di awal

Alasan passkey aman terangkum dalam tiga poin.

1. Tidak ada rahasia di server. Yang disimpan server hanyalah kunci publik, informasi yang tidak dapat disalahgunakan meskipun bocor. Bahkan jika seluruh basis data dieksfiltrasi, tidak ada “bahan untuk menyamar” yang dapat dibawa pulang penyerang.²
2. Rahasia tidak mengalir di jaringan. Yang dikirim saat masuk hanyalah tanda tangan atas angka acak sekali pakai (challenge). Karena kunci privat tidak pernah keluar dari authenticator perangkat, menyadap atau merelay di mana pun di jalur tidak menghasilkan rahasia.²
3. Tanda tangan tidak terbentuk di situs palsu. Passkey terikat ke domain situs, dan browser memaksa pencocokan domain. Meski pengguna tertipu situs palsu, passkey untuk situs asli tidak muncul sebagai kandidat; jika tanda tangan entah bagaimana di-relay, verifikasi akan menolaknya.³

Ketiganya bukan trik yang berdiri sendiri. Semuanya konsekuensi dari satu perubahan desain: beralih dari autentikasi yang berbagi rahasia lalu mengirimnya, ke autentikasi yang membuktikan kepemilikan rahasia lewat tanda tangan. Kita bahas berurutan.

Hubungan antar istilah — passkey, WebAuthn, FIDO2, CTAP

Bidang ini punya banyak istilah, dan cakupannya berbeda antar artikel, jadi hubungannya dipatok dulu. Passkey bukan protokol baru; itu “nama” yang dilekatkan pada kombinasi standar yang sudah ada.²¹

Tabel 1: Passkey adalah nama di atas fondasi FIDO2, bukan nama standar itu sendiri

Dengan kata lain, “mendukung passkey” dalam bahasa implementasi berarti “mengimplementasikan WebAuthn”. CTAP adalah lapisan yang diurus browser dan OS ketika authenticator eksternal dipakai, jadi pembuat aplikasi web tidak menyentuhnya secara langsung.

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 keamanan passkey adalah melihat kelemahan kata sandi sebagai persoalan lokasi. Pada autentikasi kata sandi, rahasia itu sendiri menempuh seluruh jalur setiap kali autentikasi.

sequenceDiagram
    participant U as Pengguna
    participant B as Browser
    participant S as Server
    Note over U: Memegang rahasia (kata sandi) di ingatan<br/>【Kelemahan ①】Dapat ditebak / dipakai ulang
    U->>B: Memasukkan kata sandi
    Note over B: 【Kelemahan ②】Dapat dimasukkan ke situs palsu<br/>dengan cara yang sama (tidak dapat dibedakan secara visual)
    B->>S: Mengirim kata sandi itu sendiri
    Note over B,S: 【Kelemahan ③】Rahasia mengalir di jalur<br/>Dilindungi TLS, tetapi di ujung kembali menjadi plaintext
    S->>S: Mencocokkan dengan hash yang tersimpan
    Note over S: 【Kelemahan ④】Rahasia (hash-nya) semua pengguna terakumulasi<br/>Jika bocor, menjadi sasaran brute force offline

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

Dari sudut penyerang, ini struktur yang sasaran tembaknya banyak dan mudah.

• Kelemahan ① (pengguna): Kekuatannya hanya sebatas yang dapat diingat, dan dipakai ulang di beberapa situs. Satu kebocoran merambat ke semua akun (serangan berbasis daftar kata sandi).
• Kelemahan ② (saat input): 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” membuat perlindungan itu tidak berarti (AiTM yang dibahas kemudian).
• Kelemahan ④ (server): Meski di-hash lalu disimpan, jika basis data bocor, hash dapat di-brute force secara offline. Kata sandi lemah pecah lebih dulu.

“Kalau begitu tambahkan kode sekali pakai (SMS atau TOTP)” adalah autentikasi multi-faktor tradisional, tetapi struktur mengirim rahasia yang dibagi tidak berubah. Pada TOTP, server dan aplikasi authenticator berbagi seed (rahasia) yang sama, dan kode 6 digit yang dihasilkan tetap dapat dimasukkan pengguna ke situs palsu. Phishing tipe AiTM (Adversary-in-the-Middle) — situs palsu merelay ke server asli secara real time — menembus pasangan kata sandi + kode sekali pakai dengan mengalirkannya apa adanya. Yang dicantumkan CISA (badan siber AS) sebagai “MFA tahan phishing” hanya dua: metode FIDO/WebAuthn, dan autentikasi berbasis PKI seperti kartu pintar (PIV/CAC). Di antara keduanya, FIDO diposisikan sebagai standar emas, justru karena alasan ini.⁴

Jadi persoalannya bukan “kekuatan” kata sandi, melainkan struktur “berbagi rahasia, lalu 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 dari W3C dan CTAP dari FIDO Alliance (bersama-sama FIDO2).²¹ Kedengarannya rumit, tetapi strukturnya sederhana.

flowchart LR
    subgraph DEV["Perangkat pengguna"]
        AUTH["Authenticator (brankas)<br/>Windows Hello / Face ID /<br/>kunci layar Android / security key"]
        SK["Kunci privat<br/>tidak pernah keluar dari sini"]
        BIO["Sidik jari / wajah / PIN<br/>= hanya membuka pintu brankas<br/>ini pun tidak keluar"]
        AUTH --- SK
        BIO -->|"Pencocokan lokal"| AUTH
    end
    subgraph SRV["Server"]
        PK["Kunci publik<br/>tidak dapat disalahgunakan meski bocor<br/>informasi 'khusus verifikasi'"]
    end
    SK -.->|"Pasangan matematis<br/>(sisi yang membuat tanda tangan)"| PK

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. Kunci ini 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.¹

Pendaftaran: menyerahkan “hanya” kunci publik

Alur ketika mendaftarkan passkey ke situs.

sequenceDiagram
    participant S as Server (example.com)
    participant B as Browser
    participant A as Authenticator
    S->>B: Permintaan pendaftaran (challenge acak + info situs)
    B->>A: Buat kunci untuk situs ini (example.com)
    A->>A: Verifikasi identitas dengan sidik jari / wajah / PIN (lokal)
    A->>A: Menghasilkan pasangan kunci baru<br/>kunci privat disimpan di dalam
    A->>B: Kunci publik + credential ID (label kunci)
    B->>S: Mengirim kunci publik + credential ID
    S->>S: Menyimpan sebagai kunci publik akun ini
    Note over S: Yang diterima server hanyalah<br/>informasi yang tidak dapat disalahgunakan meski bocor

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

Yang penting: 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 (RP ID bersifat per domain, jadi 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.³

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).

sequenceDiagram
    participant S as Server (example.com)
    participant B as Browser
    participant A as Authenticator
    S->>B: Permintaan masuk (challenge acak sekali pakai)
    B->>A: Permintaan tanda tangan ke example.com
    A->>A: Verifikasi identitas dengan sidik jari / wajah / PIN (lokal)
    A->>A: Membuat tanda tangan dengan kunci privat<br/>menanamkan challenge + origin + hash RP ID
    A->>B: Tanda tangan (bukan kunci privat itu sendiri)
    B->>S: Mengirim tanda tangan
    S->>S: Memverifikasi tanda tangan dengan kunci publik yang tersimpan<br/>juga mengonfirmasi challenge, origin, dan RP ID
    Note over B,S: Yang mengalir di jalur hanyalah tanda tangan sekali pakai<br/>meski dicuri, tidak dapat dipakai untuk challenge berikutnya

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, lalu mengonfirmasi bahwa challenge adalah yang ia ajukan sendiri, serta bahwa origin dan RP ID adalah milik situsnya sendiri.⁵

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 sehingga tidak dapat dipakai ulang (replay).

Yang tersisa, “tanda tangan tidak terbentuk di situs palsu”, adalah keunggulan terbesar passkey. Kita bahas di bab tersendiri.

4. Alasan phishing “secara struktural” tidak terbentuk

Phishing terhadap kata sandi berhasil karena rahasia asli dapat dimasukkan ke situs palsu. Manusia (terutama saat lelah) tidak 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 jika “domain origin yang sedang ditampilkan” dan “RP ID passkey” saling sesuai.³ Berikut apa yang terjadi saat situs palsu diakses.

sequenceDiagram
    participant U as Pengguna
    participant B as Browser
    participant P as Situs palsu (examp1e.com)<br/>proksi AiTM yang merelay ke yang asli
    participant S as Server asli (example.com)
    U->>P: Mengakses layar masuk yang tampak identik
    P->>S: (Di belakang) memulai proses masuk asli
    S->>P: Challenge
    P->>B: Mengalirkan challenge dan meminta tanda tangan
    B->>B: Origin saat ini adalah examp1e.com<br/>passkey untuk example.com tidak dapat dijadikan kandidat
    B--xP: Tanda tangan tidak dibuat (pengguna tidak punya cara tertipu)
    Note over B,S: Bahkan jika tanda tangan entah bagaimana dibuat,<br/>examp1e.com tertanam di tanda tangan sehingga<br/>verifikasi server asli pasti gagal

Gambar 5: Phishing tipe AiTM menembus kata sandi + kode sekali pakai, tetapi dengan passkey 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.⁵

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.⁴⁶

Isi sampai di sini, ditata per teknik serangan.

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. “Kunci privat dikatakan tidak keluar dari perangkat, lalu mengapa passkey yang dibuat di iPhone dapat dipakai di iPad?” — pertanyaan bagus, dan jawabannya: “ada dua jenis passkey”.

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

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”

flowchart TB
    subgraph SYNC["Passkey tersinkron (default untuk konsumen)"]
        S1["iCloud Keychain /<br/>Google Password Manager /<br/>pengelola kata sandi seperti 1Password"]
        S2["Sinkron terenkripsi end-to-end<br/>antar perangkat akun yang sama<br/>penyedia pun tidak dapat membaca isinya"]
        S3["Kelebihan: kuat terhadap ganti perangkat / kehilangan<br/>Perhatian: pertahanan akun cloud itu sendiri diperlukan"]
        S1 --> S2 --> S3
    end
    subgraph BOUND["Passkey terikat perangkat"]
        B1["Security key (YubiKey dan sejenisnya) /<br/>Windows Hello /<br/>Microsoft Authenticator (Entra ID)"]
        B2["Kunci privat tidak keluar secara fisik<br/>dari perangkat keras itu (dilindungi TPM dan sejenisnya)"]
        B3["Kelebihan: lokasi kunci jelas di satu tempat<br/>Perhatian: beberapa pendaftaran wajib sebagai cadangan kehilangan"]
        B1 --> B2 --> B3
    end
    SYNC ~~~ BOUND

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: 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.⁷⁸ 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, tingkat jaminan authenticator 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.⁶

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.⁹ Windows Hello di 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, mungkin pernah terasa aneh 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 dihentikan oleh konfirmasi kedekatan.¹

6. Bukan peluru perak — kelemahan tidak “hilang”, melainkan “berpindah”

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

flowchart LR
    A["Penyerang"]
    G["Autentikasi itu sendiri<br/>tanda tangan challenge<br/>【keras】"]
    R["Alur pemulihan akun<br/>mengaku 'kehilangan passkey' lalu<br/>memaksa penyiapan ulang lewat SMS atau email,<br/>dan mendaftarkan passkey penyerang"]
    F["Fallback yang masih berdampingan<br/>jika masuk kata sandi / SMS masih ada,<br/>mata rantai terlemah ada di situ"]
    C["Akun cloud<br/>untuk tipe tersinkron, Apple ID /<br/>akun Google adalah titik kegagalan tunggal"]
    SS["Sesi<br/>jika Cookie setelah masuk dicuri,<br/>metode autentikasi tidak relevan"]
    A --x G
    A --> R
    A --> F
    A --> C
    A --> SS

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 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 penerapan bukan menambah passkey, melainkan pengurangan dan penghapusan terencana fallback.
2. Alur pemulihan menjadi permukaan serangan baru. Modus mengaku “kehilangan perangkat” lalu membawa ke penyiapan ulang lewat meja dukungan atau email, dan mendaftarkan passkey penyerang sendiri. 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. Penerapan dalam praktik — WebAuthn API dan lingkungan Windows

Terakhir, pokok dari sudut pihak yang menerapkan.

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: "太郎" },
    pubKeyCredParams: [{ type: "public-key", alg: -7 }],  // ES256
    authenticatorSelection: {
      residentKey: "required",        // jadikan discoverable credential (= passkey)
      userVerification: "required",   // wajibkan verifikasi identitas dengan biometrik/PIN
    },
  },
});
// Kunci publik diambil dari credential.response, credential ID dari
// credential.id / credential.rawId di tingkat atas. Respons pendaftaran juga
// diverifikasi di server untuk challenge, origin, dan RP ID — sama seperti saat autentikasi —
// baru kemudian disimpan

Arti parameter utama adalah sebagai berikut.

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 dapat dicoba 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",
  },
  // Tampilkan passkey sebagai kandidat isi otomatis di kolom masuk. Periksa dulu
  // dukungan dengan PublicKeyCredential.isConditionalMediationAvailable(),
  // lalu pada browser yang tidak mendukung, fallback ke pemanggilan biasa tanpa mediation
  mediation: "conditional",
  // (pada <input> sasaran, autocomplete="username webauthn" wajib)
});
// Verifikasi tanda tangan di assertion.response di server

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

• Pencocokan challenge: apakah challenge yang belum terpakai yang diterbitkan 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, dan sejenisnya). 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.¹⁰ 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 “MFA tahan phishing” dituntut dengan kekuatan autentikasi akses bersyarat, akses ke sumber daya sasaran dapat dibatasi ke passkey dan sejenisnya.⁹ 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, lalu mengirimnya setiap kali autentikasi”. Karena rahasia ada di pengguna, kolom input, jalur, dan server semuanya, sasaran serangan banyak. Menambah kode sekali pakai pun kalah di-relay oleh phishing tipe AiTM.
• Passkey adalah pasangan kunci kriptografi kunci publik per situs, menyerahkan ke server hanya kunci publik yang tidak dapat disalahgunakan meskipun 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 penerapan 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

• Apa itu TPM di Windows — brankas yang tidak mengeluarkan kunci dan Measured Boot, dijelaskan dengan diagram
• NTLM dan Kerberos dijelaskan dengan diagram — mengapa autentikasi “jatuh” ke NTLM
• Menyematkan autentikasi Entra ID ke aplikasi WinForms/WPF — konfigurasi praktis MSAL.NET dan broker WAM
• Penanganan kredensial yang aman di PowerShell — mengusir kata sandi plaintext dari skrip
• Daftar periksa keamanan minimum pengembangan aplikasi Windows
• Dari mana UKM harus mulai soal keamanan — panduan “Pedoman Keamanan Informasi untuk UKM” IPA, edisi ke-4

Area konsultasi terkait

KomuraSoft LLC menangani pengembangan perangkat lunak kontrak yang mencakup dukungan implementasi WebAuthn untuk login passkey pada sistem web internal, perancangan penerapan MFA tahan phishing di lingkungan Entra ID, dan penyematan autentikasi ke aplikasi bisnis Windows seperti WinForms/WPF.

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, lalu mengirim rahasia itu setiap kali masuk. Rahasia ada di mana-mana — di ingatan pengguna, di kolom input, di jalur komunikasi, dan di basis data server — sehingga semuanya menjadi sasaran serangan. Passkey memakai pasangan kunci kriptografi kunci publik, dan kunci privat tidak pernah dikirim ke server. Pada tipe terikat perangkat, kunci privat tidak pernah keluar dari authenticator sama sekali; pada tipe tersinkron pun, kunci itu hanya keluar dalam bentuk terenkripsi end-to-end. Yang disimpan server hanyalah kunci publik — informasi yang tidak dapat disalahgunakan meskipun bocor — dan yang dikirim saat masuk hanyalah tanda tangan atas challenge sekali pakai. Dengan kata lain, rahasia bersama yang menjadi kelemahan kata sandi memang tidak ada. Selain itu, karena pasangan kunci dibuat terpisah untuk setiap situs, gagasan penggunaan ulang pun tidak berlaku.

Apakah data biometrik (sidik jari atau wajah) dikirim ke server?

Tidak. Data sidik jari atau wajah hanya dipakai untuk pencocokan lokal di dalam perangkat — 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) telah dilakukan; sidik jari itu sendiri tidak ikut, bahkan vektor cirinya pun tidak. Jika biometrik tidak dapat dipakai, PIN dapat menggantikannya. PIN ini, seperti PIN Windows Hello, hanya dicocokkan secara lokal di perangkat. Perbedaan yang menentukan dari kata sandi: PIN tidak pernah mengalir 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), dan browser hanya menawarkan passkey yang cocok dengan domain situs yang sedang ditampilkan. Meski domain palsu tampak identik dengan yang asli, passkey untuk situs asli tidak muncul sebagai pilihan, sehingga pengguna tidak punya cara untuk tertipu. Selain itu, origin yang dikonfirmasi browser dan hash RP ID tertanam di tanda tangan; jika tanda tangan di-relay, verifikasi di server asli akan menolaknya. Kecelakaan seperti pada kata sandi atau kode SMS — memasukkan kredensial asli ke situs palsu — secara struktural tidak dapat terjadi. Itulah perbedaan mendasar dari penanggulangan yang mengandalkan pelatihan dan kewaspadaan.

Jika ponsel hilang, apakah akun menjadi tidak bisa diakses?

Jika itu passkey tersinkron (yang disimpan di iCloud Keychain atau Google Password Manager), passkey dapat dipulihkan ke perangkat baru yang masuk dengan Apple ID atau akun Google yang sama. Namun, memulihkan brankas terenkripsi end-to-end mensyaratkan bukan hanya kata sandi akun, melainkan juga verifikasi identitas tambahan — misalnya memasukkan kunci layar (kode sandi) perangkat sebelumnya. Jika sarana pemulihan itu juga hilang, pemulihan bisa gagal. Penting untuk tidak menitipkan semuanya pada satu ponsel. Passkey terikat perangkat (security key, Windows Hello, dan sejenisnya) berbagi nasib dengan perangkatnya, jadi praktik standar untuk akun penting adalah mendaftarkan lebih dari satu passkey. Banyak layanan mengizinkan beberapa passkey pada satu akun. Cara menonaktifkan passkey yang hilang berbeda menurut jenisnya. Pada tipe tersinkron, salinan di setiap perangkat adalah kredensial yang sama, jadi pertama-tama hapus perangkat yang hilang atau lakukan remote wipe di sisi akun platform agar salinan di perangkat itu tidak dapat dipakai (menghapus passkey di pengaturan akun layanan menonaktifkan salinan di semua perangkat sekaligus). Pada tipe terikat perangkat, menghapus passkey authenticator itu di sisi layanan cukup untuk menonaktifkan kunci yang hilang saja. Untuk pemakaian organisasi, rancang bersamaan redundansi agar pengguna dapat pulih sendiri dan prosedur agar administrator mencabutnya saat hilang.

Apakah passkey juga punya kelemahan?

Ada. Lebih tepat 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, di situlah mata rantai terlemah tetap ada; ada modus menyalahgunakan alur pemulihan akun untuk mendaftarkan passkey penyerang; dan pada tipe tersinkron, pengambilalihan akun cloud itu sendiri menjadi titik kegagalan tunggal yang baru. Selain itu, serangan yang mencuri cookie sesi setelah masuk tidak dihentikan oleh passkey, jadi ancaman yang tidak terkait pun tidak tiba-tiba hilang. Penerapan perlu mencakup bukan hanya menambah passkey, melainkan juga penguatan alur pemulihan dan pengurangan terencana sarana 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.