Sebuah assertion WebAuthn dapat memiliki signature yang valid tetapi tetap menunjukkan anomali operasional: signature counter-nya tidak lebih besar daripada nilai yang disimpan setelah assertion sukses sebelumnya. Kondisi ini berguna sebagai sinyal, tetapi tidak sama dengan bukti bahwa private key telah disalin, dan counter tersebut bukan mekanisme pencegah replay.

Field signCount berada di dalam authenticator data. Relying party menerima authenticator data itu sebagai bagian dari assertion lalu memverifikasinya bersama client data dan signature. Counter dapat memberi relying party bukti mengenai state authenticator di antara ceremony yang sukses. Nilai keamanannya bergantung pada perilaku counter milik authenticator dan pada kemampuan relying party menyimpan nilai sebelumnya secara benar.

Karena itu, signCount merupakan sinyal risiko yang memiliki state pada batas autentikasi, bukan pengganti challenge kriptografis WebAuthn, pemeriksaan origin, pemeriksaan RP ID, atau verifikasi signature.

Counter merupakan state yang diautentikasi

Authenticator data memuat signature counter unsigned 32-bit. Karena authenticator data dicakup oleh signature assertion, perantara tidak dapat sekadar mengganti counter dengan nilai pilihannya tanpa membuat signature menjadi tidak valid.

Pada authenticator yang menerapkan counter nonzero, operasi autentikasi yang sukses dapat menaikkan nilainya. Relying party menyimpan counter yang terkait dengan suatu kredensial dan membandingkan assertion berikutnya dengan nilai tersimpan. Nilai yang meningkat konsisten dengan urutan yang diharapkan. Nilai yang tidak meningkat dapat menunjukkan bahwa dua instance authenticator memakai material kredensial dengan state counter yang tidak lagi sinkron.

Batas yang relevan mudah terlewat. Relying party tidak meminta counter untuk mengautentikasi request. Signature sudah mengautentikasi kepemilikan private key kredensial untuk ceremony tersebut. Counter menambahkan konteks historis setelah pemeriksaan kriptografis sukses.

Urutan sederhana di sisi server dapat berbentuk:

terima assertion
    |
    +-- verifikasi challenge dan konteks ceremony
    +-- verifikasi binding origin dan RP ID
    +-- verifikasi signature assertion
    |
    +-- baca authenticatorData.signCount
    +-- bandingkan dengan counter tersimpan
    |
    +-- perbarui state risiko dan counter tersimpan

Pemeriksaan counter yang dilakukan sebelum verifikasi signature akan bertindak atas input yang belum diautentikasi. Counter baru bermakna sebagai bagian dari authenticator data yang sudah terverifikasi.

Regresi adalah bukti pendukung, bukan vonis

Misalkan relying party menyimpan signCount = 41 untuk sebuah kredensial. Assertion valid berikutnya melaporkan 42. Untuk authenticator yang memakai counter meningkat, urutan tersebut normal. Jika assertion valid setelahnya melaporkan 18, urutan itu tidak konsisten dengan satu state counter yang meningkat secara monoton.

Kloning kredensial merupakan salah satu kemungkinan penyebab. Jika material kredensial privat dan state counter disalin pada titik sebelumnya, dua salinan dapat berkembang secara independen. Assertion dari kedua salinan kemudian dapat menampilkan nilai counter yang gagal melampaui nilai yang disimpan relying party.

Observasi tersebut tidak membentuk aturan sebab-akibat yang universal. Perilaku counter berbeda-beda, dan detail implementasi platform atau authenticator berpengaruh. Karena itu, relying party perlu memperlakukan perbandingan counter yang mencurigakan sebagai input bagi kebijakan. Bergantung pada sensitivitas akun dan sinyal lain, kebijakan dapat meminta faktor autentikasi lain, menandai kredensial untuk pemeriksaan, meminta penggantian kredensial, atau mencatat peristiwa untuk korelasi berikutnya.

Penguncian akun secara langsung hanya berdasarkan anomali counter dapat mengubah sinyal yang tidak sempurna menjadi masalah availability.

Nilai nol memiliki arti operasional yang khusus

WebAuthn mengizinkan authenticator yang tidak menerapkan signature counter. Dalam kondisi tersebut, counter dapat tetap bernilai nol. Relying party tidak dapat membentuk urutan yang berguna dari rangkaian nilai nol.

Perbedaan ini mengubah logika server. Perbandingan seperti newCount <= storedCount tidak dapat diperlakukan sebagai pendeteksi kloning tanpa memperhitungkan perilaku zero-counter. Jika kedua nilai nol, relying party tidak memiliki progres counter untuk dievaluasi.

Secara konseptual, keputusan dapat dinyatakan sebagai:

if storedCount == 0 and newCount == 0:
    tidak ada sinyal berbasis counter
else if newCount > storedCount:
    progres konsisten
else:
    anomali counter; terapkan kebijakan relying party

Logika produksi tetap harus mengikuti spesifikasi WebAuthn dan perilaku library WebAuthn yang dipakai. Properti pentingnya adalah nilai nol tidak diam-diam diubah menjadi bukti kloning.

Kredensial multi-device melemahkan narasi satu perangkat

Passkey dapat diimplementasikan sebagai kredensial multi-device. Material kredensial dapat dicadangkan dan tersedia di beberapa perangkat dalam ekosistem yang didukung penyedia. Model ini tidak cocok dengan asumsi lama bahwa satu kredensial selalu berhubungan dengan satu authenticator fisik yang memiliki satu hardware counter persisten.

Authenticator data WebAuthn juga membawa informasi backup eligibility dan backup state. Flag tersebut memberi sinyal state kredensial yang terpisah dan tidak boleh disimpulkan dari signCount. Relying party yang membutuhkan pembedaan kebijakan terkait kredensial yang dicadangkan perlu mengevaluasi backup flag yang didefinisikan dan kebijakan penerimaannya sendiri, bukan mencoba menurunkan topologi perangkat dari signature counter.

Hal ini penting saat menafsirkan insiden. Anomali counter pada kredensial yang dapat tersedia di beberapa perangkat tidak membenarkan klaim bahwa hardware token telah diduplikasi secara fisik. Server mengamati inkonsistensi state, bukan rekonstruksi forensik atas riwayat penyimpanan kredensial.

Pertahanan replay berada pada ceremony

Signature counter kadang diberi tanggung jawab terlalu besar karena nilainya berubah seiring waktu. Ketahanan replay WebAuthn terutama berasal dari challenge baru yang dibuat server untuk ceremony serta binding bertanda tangan terhadap data ceremony, bukan dari persyaratan nilai counter yang unik secara global.

Relying party membuat challenge untuk ceremony autentikasi, mengaitkannya dengan transaksi yang sedang menunggu, lalu memvalidasi client data yang dikembalikan. Assertion yang direkam dari ceremony sebelumnya semestinya gagal terhadap challenge baru yang berbeda. Validasi origin dan RP ID mengikat ceremony ke konteks keamanan web yang diharapkan, sedangkan verifikasi signature membuktikan kepemilikan private key kredensial untuk data yang ditandatangani.

Counter memiliki fungsi berbeda. Counter dapat menunjukkan state mencurigakan di antara assertion yang secara lain valid. Memperlakukan counter sebagai replay nonce akan mencampur dua kontrol independen dan menghasilkan perilaku rapuh pada authenticator yang counter-nya tetap nol.

Penyimpanan counter merupakan bagian dari properti keamanan

Sinyal counter yang berguna membutuhkan state relying party yang persisten dan terserialisasi dengan benar. Jika dua node aplikasi menerima assertion secara bersamaan dan keduanya membandingkan terhadap nilai tersimpan yang sudah stale, pembaruan counter dapat mengalami race. Dampaknya dapat berupa progres yang hilang, anomali palsu, atau berkurangnya kemampuan mengorelasikan assertion berikutnya.

Karena itu, operasi database patut mendapat perhatian yang sama dengan proses perbandingannya. Record kredensial perlu mengidentifikasi public key dan state counter saat ini tanpa ambiguitas. Pembaruan perlu mencegah observasi lama menimpa nilai tersimpan yang lebih baru.

Deployment terdistribusi dapat menerapkannya dengan transaction, conditional update, atau primitive concurrency lain yang sesuai dengan datastore. Mekanisme tepatnya bersifat spesifik terhadap deployment. Invariant-nya lebih penting: state counter yang diterima tidak boleh bergerak mundur hanya karena dua worker server memproses assertion pada saat yang sama.

Penyimpanan counter juga harus tetap terikat pada credential identifier yang tepat. Satu akun pengguna dengan beberapa kredensial WebAuthn secara sah dapat memiliki riwayat counter berbeda untuk setiap kredensial.

Kebijakan perlu memisahkan kegagalan dan sinyal

Sebagian pemeriksaan WebAuthn merupakan persyaratan protokol yang bersifat biner. Signature yang salah, challenge yang tidak cocok, origin yang tidak diterima, atau RP ID yang tidak cocok menyebabkan ceremony gagal. Anomali signature counter memiliki peran berbeda: anomali itu merupakan bukti pendukung yang dapat menunjukkan authenticator hasil kloning atau inkonsistensi state lain.

Menyatukan kategori tersebut membuat kebijakan lebih sulit dioperasikan. Sistem yang mencatat hasil counter sebagai telemetry autentikasi terstruktur dapat menggabungkannya dengan backup state kredensial, peristiwa pemulihan akun, registrasi kredensial baru, sinyal manajemen perangkat, dan kontrol risiko khusus aplikasi. Tidak satu pun sinyal tambahan tersebut mengubah validitas signature WebAuthn itu sendiri.

Batas yang bersih adalah menyelesaikan verifikasi kriptografis dan ceremony yang wajib terlebih dahulu, mengevaluasi state counter yang sudah diautentikasi setelahnya, lalu menerapkan kebijakan relying party yang eksplisit terhadap anomali. Susunan ini mempertahankan nilai counter tanpa memberinya jaminan yang tidak disediakan protokol.

Keamanan Siber WebAuthn Autentikasi Passkey