WebAuthn Resident Key: Kredensial yang Dapat Ditemukan sebagai Passkeys

Passkeys dan protokol yang mendasarinya, WebAuthn, sedang merevolusi lanskap autentikasi. Namun, menyiapkan server WebAuthn dengan benar bisa menjadi pekerjaan yang rumit. Kesalahan konfigurasi tidak hanya dapat menimbulkan kerentanan, tetapi juga merusak passkeys yang sudah ada jika kita perlu mengubahnya nanti. Postingan blog berikut seharusnya membantu kita lebih memahami spesifikasi WebAuthn yang sering kali kompleks dan memberikan saran tentang pengaturan mana yang terbaik untuk kasus penggunaan kita.

WebAuthn beroperasi dengan tiga entitas utama:

• Relying Party (RP): Ini adalah layanan web kita yang ingin mengautentikasi pengguna. RP mengirimkan tantangan ke klien, memverifikasi respons, dan mengelola kunci publik dari sebuah passkey.
• Authenticator: Ini adalah perangkat yang dapat membuktikan kepemilikan kredensial. Contohnya termasuk smartphone, laptop, atau kunci keamanan (misalnya, YubiKeys). Authenticator bisa bersifat spesifik platform (seperti Windows Hello atau Touch ID / Face ID Apple) atau lintas platform (seperti kunci keamanan, misalnya YubiKeys).
• Klien: Biasanya, ini adalah browser web atau aplikasi native yang bertindak sebagai perantara antara RP dan authenticator. Mereka memfasilitasi komunikasi, memastikan bahwa data mengalir dengan benar dan aman.

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

Berikut ini, alur data tingkat tinggi selama proses autentikasi (baik login maupun sign-up) dijelaskan.

1. Inisiasi Klien: Proses dimulai di sisi klien, biasanya ketika pengguna mencoba untuk login atau sign-up. Misalnya, mereka mungkin mengklik tombol "Login dengan WebAuthn" dan klien mengirimkan permintaan tantangan ke RP.
2. Permintaan RP: RP kemudian mengirimkan tantangan kembali ke klien. Tantangan ini adalah nilai yang dibuat secara acak yang memastikan keaslian respons berikutnya.
3. Klien ke Authenticator: Selama sign-up, klien meminta authenticator untuk membuat passkey baru dengan membuat pasangan kunci publik-privat yang sesuai. Selama login, klien meminta authenticator untuk menandatangani tantangan. Ini dilakukan menggunakan kunci privat pada authenticator, yang sesuai dengan kunci publik yang terdaftar sebelumnya yang disimpan di RP.
4. Respons Authenticator: Selama sign-up, authenticator mengirimkan kembali kunci publik ke klien. Selama login, authenticator menandatangani tantangan dan mengirimkan assertion yang ditandatangani ini kembali ke klien.
5. Klien ke RP: Klien meneruskan kunci publik baru ini / assertion yang ditandatangani ke RP.
6. Verifikasi RP: RP menyimpan kunci publik / memverifikasi assertion yang ditandatangani menggunakan kunci publik yang tersimpan. Jika valid, autentikasi berhasil.

Ben Gould

Head of Engineering

I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.

10.000+ developer memercayai Corbado & membuat Internet lebih aman dengan passkeys. Punya pertanyaan? Kami telah menulis 150+ postingan blog tentang passkeys.

Gabung Komunitas Passkeys

Alur proses tingkat tinggi yang dijelaskan di atas menggambarkan proses sign-up dan login WebAuthn. Passkeys dibangun di atas WebAuthn. Awalnya, istilah passkeys digunakan sebagai istilah yang lebih mudah diingat dan non-teknis daripada WebAuthn yang menggambarkan hal yang sama. Selain itu, passkeys menyediakan lebih banyak fitur dibandingkan dengan WebAuthn standar, misalnya, kemungkinan untuk menyinkronkan passkeys melalui akun cloud atau manajer kata sandi.

Untuk lebih memahami bagian-bagian berikut, kami mendefinisikan beberapa istilah penting dalam protokol WebAuthn agar memiliki pemahaman yang sama.

• Credential ID: Credential ID adalah pengidentifikasi unik yang diberikan ke kredensial kunci publik tertentu yang dihasilkan oleh authenticator. Ini memungkinkan Relying Party (RP) untuk mengidentifikasi dan memilih PublicKeyCredential yang benar untuk proses autentikasi.
• PublicKeyCredential: Ini adalah struktur data utama yang dikembalikan dari API WebAuthn browser atau aplikasi native. Ini mencakup baik data Attestation selama sign-up maupun data Assertion selama login. Pada dasarnya, ini berisi data yang dibutuhkan RP untuk memverifikasi proses tersebut.
• Attestation: Attestation dalam konteks WebAuthn berfungsi sebagai bukti asal authenticator dan integritasnya. Selama sign-up, ini adalah cara bagi authenticator untuk mengatakan, "Saya telah mendaftarkan kredensial pengguna dengan aman, dan inilah pernyataan yang dapat Anda gunakan untuk memverifikasi hal itu". Relying Party kemudian dapat memverifikasi bahwa tanda tangan berasal dari authenticator tertentu yang diizinkan (misalnya, Yubikey). Tidak semua authenticator passkey membalas dengan attestation seperti itu, beberapa hanya tidak mengirimkan data yang berguna kembali (lihat di sini daftar authenticator passkeys). AAGUID (Authenticator Attestation GUIDs) lebih lanjut yang mengidentifikasi lebih banyak authenticator (terutama kunci keamanan, misalnya YubiKeys) dapat ditemukan di FIDO Alliance Metadata Service.
• Assertion: Setelah proses sign-up, ketika seorang pengguna mencoba untuk login, authenticator menghasilkan sebuah assertion. Assertion pada dasarnya adalah PublicKeyCredential + tantangan yang ditandatangani. Assertion ini membuktikan bahwa pengguna memiliki kunci privat yang terkait dengan kunci publik yang terdaftar tanpa mengungkapkan kunci privat yang sebenarnya. Ini adalah cara authenticator untuk mengatakan, "Ini adalah pengguna yang asli, dan saya dapat menjamin mereka."

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Resident keys (RKs) dan non-resident keys (NRKs) adalah dua jenis kunci kriptografis _yang digunakan dalam protokol WebAuthn, dan keduanya berbeda terutama dalam lokasi penyimpanan dan mekanisme pengambilannya.

Definisi:

Resident keys disimpan langsung di dalam authenticator itu sendiri. Ini bisa berupa kunci keamanan (misalnya, YubiKey), secure enclave platform (misalnya, Secure Enclave iPhone), _atau trusted platform module (TPM) di laptop. Conditional UI (passkey autofill) hanya berfungsi untuk resident keys dan kelompok kerja WebAuthn saat ini mensyaratkan resident keys agar dianggap sebagai passkey.

Pada tangkapan layar berikut, Anda melihat daftar semua resident keys (credential ID, rpID, nama pengguna, nama tampilan) yang disimpan di YubiKey. Non-resident keys tidak ada dalam daftar, karena tidak disimpan di authenticator:

Alur login:

Sumber: William Brown

Selama proses login, Relying Party mengirimkan permintaan tanpa menentukan kredensial ke klien (browser) yang mulai menanyakan authenticator (di sini dalam bagan: kunci keamanan). Authenticator menemukan semua resident keys untuk Relying Party yang sesuai dan klien (browser) memilih resident key yang diinginkan. Resident key ini digunakan untuk menandatangani tantangan. Tanda tangan dikirim dari authenticator melalui klien ke Relying Party.

Kelebihan:

1. Pengalaman Pengguna yang Efisien: Salah satu keuntungan paling signifikan dari resident keys adalah bahwa authenticator menyimpan user handle (misalnya, email, nomor telepon, nama pengguna) dan dengan demikian dapat mengisi user handle (misalnya, email, nomor telepon, nama pengguna) untuk login. Pengguna tidak perlu mengingat atau memasukkan user handle (misalnya, email, nomor telepon, nama pengguna), menyederhanakan proses login, terutama pada perangkat dengan kemampuan biometrik. Ini juga dapat terjadi secara otomatis dengan Conditional UI.
2. Autentikasi Spesifik Perangkat: Resident keys dapat memberikan lapisan keamanan tambahan dengan mengikat autentikasi ke perangkat tertentu. Ini bisa sangat berguna untuk layanan yang ingin memastikan pengguna login dari perangkat tepercaya.
3. Conditional UI (Passkey Autofill): Conditional UI hanya berfungsi dengan resident keys yang menyediakan pengalaman login yang paling mulus (lihat di bawah untuk detailnya).

Kekurangan:

1. Batasan Penyimpanan: Beberapa authenticator memiliki kapasitas penyimpanan yang terbatas. Terutama untuk kunci keamanan (misalnya, YubiKeys), seringkali ada batasan jumlah resident keys yang dapat mereka simpan (kebanyakan memiliki batasan berkisar antara 8 hingga ~100 resident keys). Setelah batas ini tercapai, kunci yang lebih lama mungkin perlu dihapus untuk memberi ruang bagi yang baru, atau pengguna mungkin perlu menggunakan authenticator lain.
2. Kehilangan Authenticator: Jika authenticator, misalnya, kunci keamanan (misalnya, YubiKey) atau smartphone, hilang atau rusak, semua resident keys di perangkat itu hilang. Ini bisa mengunci pengguna dari beberapa layanan sampai mereka mendaftar ulang atau memulihkan akun mereka. Menyinkronkan kunci melalui akun cloud (misalnya, iCloud Keychain, Google Password Manager) atau manajer kata sandi modern (misalnya, 1Password atau Dashlane) mencegah kehilangan ini.
3. Kekhawatiran Keamanan: Jika sebuah authenticator dengan resident keys dicuri, penyerang mungkin mencoba untuk mengekstrak kuncinya. Meskipun authenticator modern memiliki mekanisme keamanan yang kuat untuk mencegah ekstraksi, misalnya, pengguna melindungi perangkat dengan PIN yang kuat, passcode atau gestur, risikonya, meskipun minimal, tetap ada.

Kasus Penggunaan: Ideal untuk perangkat di mana pengguna sering melakukan autentikasi, seperti smartphone atau laptop pribadi.

Want to find out how many people use passkeys?

View Adoption Data

Definisi:

Non-resident keys, sebaliknya, tidak disimpan di authenticator. Sebaliknya, authenticator menghasilkan pasangan kunci baru (berdasarkan kunci master yang dilindungi secara internal) dan mengirimkan kunci publik dari pasangan kunci baru ini ke server (Relying Party) bersama dengan credential ID (yang berisi seed) selama sign-up. Server kemudian mengaitkan kunci publik ini dengan akun pengguna. Untuk autentikasi selanjutnya, authenticator menurunkan kembali kunci privat dengan menerima credential ID, mengekstrak seed, dan menggabungkannya dengan kunci master. Karena kunci tersebut hanya tersedia sementara di memori yang dilindungi dari authenticator, kadang-kadang disebut kunci fana (ephemeral key) dalam bahasa kriptografi.

Alur login:

Sumber: William Brown

Selama proses login, Relying Party pertama-tama harus mengidentifikasi pengguna mana yang meminta autentikasi (misalnya, dengan meminta user handle, contohnya email, nomor telepon, atau nama pengguna) dan kemudian mengirimkan credential ID yang diketahuinya untuk pengguna yang meminta ke klien (browser). Klien meneruskannya ke authenticator (di sini: kunci keamanan). Authenticator menggunakan credential ID bersama dengan kunci master authenticator untuk menurunkan kunci privat sementara, menandatangani tantangan dengan kunci yang dihasilkan dan mengembalikannya ke klien (di sini: browser), yang meneruskannya ke Relying Party. Non-resident keys awalnya digunakan sebagai faktor kedua sebelum pengenalan passkeys. Oleh karena itu, mengidentifikasi pengguna terlebih dahulu adalah bagian dari proses login biasa.

Kelebihan:

1. Skalabilitas: Karena non-resident keys tidak berada di authenticator, pengguna dapat memiliki jumlah non-resident keys yang hampir tidak terbatas yang terkait dengan berbagai layanan. Ini sangat bermanfaat bagi pengguna yang memiliki akun di banyak platform.
2. Kemampuan Roaming: Non-resident keys ideal untuk authenticator roaming seperti kunci keamanan (misalnya, YubiKey). Seorang pengguna dapat menggunakan kunci keamanan yang sama (misalnya, YubiKey) untuk mengautentikasi di berbagai perangkat dan platform, memberikan pengalaman yang konsisten.
3. Mengurangi Ketergantungan pada Penyimpanan Authenticator: Untuk pengaturan server WebAuthn yang sesuai, tidak perlu khawatir tentang batasan penyimpanan authenticator. Ini bisa sangat menguntungkan untuk authenticator dengan penyimpanan rendah, seperti kunci keamanan (misalnya, YubiKeys).

Kekurangan:

1. UX Kurang Baik karena User Handle Diperlukan: Kelemahan terbesar dari non-resident keys adalah bahwa user handle (misalnya, email, nomor telepon, nama pengguna) perlu disediakan oleh pengguna yang membuat pengisian nama pengguna secara otomatis melalui Conditional UI menjadi tidak mungkin. User handle ini perlu dikaitkan dengan credential ID yang diperlukan untuk menghitung kunci yang dibungkus kunci fana (ephermal key-wrapped key).
2. Potensi Kesalahan Manajemen: RP perlu mengelola dan mengamankan hubungan antara akun pengguna dan kunci publik. Manajemen yang buruk atau kerentanan dapat menyebabkan masalah keamanan.

Kasus Penggunaan: Ideal untuk authenticator roaming seperti kunci keamanan (misalnya, YubiKeys) yang digunakan di berbagai layanan atau platform.

Bayangkan Anda memiliki kunci keamanan (misalnya, YubiKey), dan Anda mendaftarkannya dengan dua layanan online: Layanan A dan Layanan B. Untuk Layanan A, Anda menggunakan resident key. Untuk Layanan B, non-resident key. Ketika Anda mengautentikasi ke Layanan A, Anda cukup mengetuk kunci keamanan Anda (misalnya, YubiKey), dan Anda masuk - tidak perlu menyebutkan nama pengguna. Untuk Layanan B, Anda pertama-tama akan memberikan nama pengguna Anda di browser / aplikasi native. Layanan tersebut kemudian mengirimkan credential ID yang terkait ke kunci keamanan Anda (misalnya, YubiKey), yang kemudian menghasilkan kembali kunci privat fana untuk autentikasi.

Intinya, sementara resident dan non-resident keys meningkatkan keamanan dengan memanfaatkan autentikasi kriptografis, pengalaman pengguna dan mekanisme penyimpanannya berbeda, melayani berbagai kasus penggunaan.

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

Conditional UI adalah fitur tonggak sejarah dari passkeys / WebAuthn. Ini mengambil lebih banyak beban dari pengguna, karena pengguna tidak hanya tidak perlu mengingat kata sandi, tetapi juga tidak perlu mengingat user handle (misalnya, email, nomor telepon, nama pengguna) yang digunakannya untuk mendaftar ke Relying Party. Terutama, dalam kasus di mana layanan Relying Party hanya sesekali digunakan, ini adalah langkah besar.

Ini berfungsi karena begitu halaman login dibuka, server Relying Party mengirimkan tantangan di latar belakang ke klien (ingat tidak ada credential ID yang perlu dikirim dalam panggilan ini). Klien mengambil tantangan ini dan memeriksa passkeys mana yang cocok dengan Relying Party ID pada authenticator ini dan menawarkan pilihan melalui menu autofill, di mana pengguna dapat memilih passkey yang sesuai.

Selain itu, ini juga menghemat pengguna dari klik ekstra pada tombol login, karena begitu passkey dipilih dari menu autofill, proses login dimulai.

CTAP adalah protokol dasar dalam standar FIDO2 , menjembatani kesenjangan komunikasi antara klien (seperti browser) dan authenticator (seperti kunci keamanan, misalnya, YubiKeys, atau smartphone). Untuk lebih memahami CTAP, mari kita lihat sekilas versi protokol yang berbeda sebelum menganalisis dampaknya pada resident dan non-resident keys.

Versi sebelumnya, sering disebut sebagai Universal 2nd Factor (U2F), terutama dirancang untuk autentikasi faktor kedua. Dalam U2F, server memberikan tantangan, dan authenticator memberikan respons, membuktikan kepemilikan kunci privat. Namun, U2F tidak mendukung resident keys, yang berarti selalu memerlukan pencarian sisi server untuk mengidentifikasi kunci mana yang akan digunakan untuk seorang pengguna, karena ini adalah bagian dari proses ketika meminta faktor kedua.

Sebagai penerus U2F, CTAP2 memperkenalkan dukungan untuk resident keys, memungkinkan autentikasi tanpa kata sandi dan tanpa nama pengguna. Dengan resident keys, authenticator menyimpan nama pengguna dan credential ID pengguna (bersama dengan Relying Party ID), menghilangkan kebutuhan bagi server Relying Party untuk menyediakannya selama autentikasi. Ini adalah lompatan signifikan menuju UX yang lebih mulus.

Namun, CTAP2 datang dengan tantangan. Salah satu masalah penting adalah pengelolaan resident keys. Misalnya, menghapus resident key tertentu di perangkat CTAP2.0 seringkali memerlukan reset perangkat lengkap (sehingga kunci master Anda juga direset, yang berarti semua non-resident keys Anda juga tidak akan berfungsi lagi), yang tidak ramah pengguna dan dapat menjadi masalah dalam skenario di mana beberapa resident keys disimpan pada satu perangkat. Ini membuat resident keys pada perangkat CTAP2.0 menjadi komitmen yang serius. Anda benar-benar tidak ingin secara tidak sengaja mengisi ruang terbatas yang sering Anda miliki, terutama pada kunci keamanan (misalnya, YubiKeys).

CTAP2.1 adalah versi selanjutnya dari CTAP2, membawa fitur tambahan dan perbaikan pada protokol. Beberapa poin kunci tentang CTAP 2.1 meliputi:

• Manajemen Resident Key yang Lebih Baik: CTAP 2.1 memungkinkan untuk mengelola, memperbarui, dan menghapus resident key tertentu dari perangkat Anda secara individual.
• Attestation Perusahaan: Fitur ini memungkinkan perusahaan untuk memiliki lebih banyak kontrol atas kunci yang digunakan oleh karyawan mereka. Ini menyediakan cara bagi perusahaan untuk memverifikasi bahwa kunci yang digunakan adalah yang dikeluarkan perusahaan.
• Pengenalan Pengguna Ganda: Beberapa authenticator dapat mengenali banyak pengguna. CTAP 2.1 menyediakan cara bagi authenticator ini untuk menunjukkan pengguna mana yang telah dikenali.
• Kompatibilitas Mundur: CTAP 2.1 dirancang agar kompatibel dengan CTAP2, memastikan bahwa perangkat dan platform yang mendukung versi lama masih dapat bekerja dengan yang baru.

Setelah melihat resident keys, non-resident keys, dan berbagai versi CTAP, sekarang kita akan menganalisis sisi Relying Party dan dengan demikian sisi server WebAuthn secara lebih mendalam.

Fleksibilitas (tetapi juga kompleksitas) WebAuthn sebagian besar disebabkan oleh pengaturan servernya, terutama di dalam objek authenticatorSelection. Objek ini memandu klien dalam memilih authenticator yang tepat untuk tugas tersebut.

{
    "rp": {
        "name": "corbado.com",
        "id": "corbado.com"
    },
    "user": {
        "id": "dGVzdefEyMjE",
        "name": "test-username",
        "displayName": "test-username"
    },
    "challenge": "mhanjsapJjCNaN_Ttasdfk1C0DymR-V_w_0UVOPsdfdfJG2ON_FK5-ODtqp33443tgqHzuuDjv-NUUmMAE4hg",
    "pubKeyCredParams": [
        {
            "type": "public-key",
            "alg": -7
        },
        {
            "type": "public-key",
            "alg": -257
        }
    ],
    "timeout": 60000,
    "excludeCredentials": [],
    "authenticatorSelection": {
        "authenticatorAttachment": "platform",
        "residentKey": "preferred",
        "requireResidentKey": false,
        "userVerification": "preferred"
    },
    "attestation": "none",
    "extensions": {
        "credProps": true
    }
}

Opsi server ini menentukan bagaimana authenticator terpasang pada perangkat klien. Ini memberikan wawasan tentang bagaimana authenticator berkomunikasi dengan klien:

Nilai yang Mungkin

• Platform: Ini menunjukkan bahwa authenticator terpasang pada platform klien dan oleh karena itu tidak dapat dilepas.
• Cross-platform: Ini menunjukkan bahwa authenticator tidak terikat pada platform klien dan dapat digunakan di beberapa perangkat.

Kasus Penggunaan & Contoh

• Platform: Contohnya termasuk pemindai sidik jari yang terpasang di laptop atau sistem pengenalan wajah di ponsel, misalnya, Face ID, Touch ID atau Windows Hello.
• Cross-platform: Contohnya termasuk kunci keamanan USB (misalnya, YubiKeys), perangkat Bluetooth, atau kartu NFC.

Dalam spesifikasi WebAuthn Level 1, opsi server ini disebut requireResidentKey dan dapat berisi nilai Boolean true (authenticator harus membuat resident key) atau false (authenticator harus membuat non-resident key). WebAuthn Level 2 menggantikan opsi server ini dengan opsi server baru residentKey:

Nilai yang Mungkin

• Required: Authenticator harus membuat resident key (jika tidak memungkinkan, operasi harus gagal).
• Preferred: Authenticator harus mencoba membuat resident key (jika tidak memungkinkan, ia harus membuat non-resident key)
• Discouraged: Authenticator harus membuat non-resident key (jika tidak memungkinkan, operasi harus gagal).

Kasus Penggunaan & Contoh

• Required: Ideal untuk skenario di mana login tanpa nama pengguna diinginkan atau di mana pengguna seharusnya hanya mengautentikasi dari perangkat yang terdaftar sebelumnya (dengan menambahkan lapisan keamanan ekstra dengan mengikat kredensial pengguna ke perangkat tertentu).
• Preferred: Cocok untuk skenario di mana layanan web ingin memberikan UX login terbaik jika memungkinkan (melalui resident keys), tetapi masih ingin mendukung non-resident keys jika resident keys tidak memungkinkan.
• Discouraged: Sebuah layanan ingin menawarkan autentikasi passkey dan juga ingin memastikan bahwa pengguna dapat menggunakan authenticator apa pun, bahkan yang tanpa kemampuan penyimpanan, tanpa mengikat kredensial ke perangkat tertentu.

Verifikasi pengguna mengacu pada proses yang memastikan orang yang berinteraksi dengan authenticator adalah pemilik yang sah, biasanya dengan mewajibkan gerakan autentikasi tertentu seperti memasukkan PIN, memberikan sidik jari, atau menggunakan pengenalan wajah.

Terkadang kehadiran pengguna (UP) juga disebutkan atau digunakan mirip dengan verifikasi pengguna tetapi memang memiliki beberapa perbedaan. Kehadiran pengguna hanya mengonfirmasi bahwa seseorang—siapa pun— hadir secara fisik dan berinteraksi dengan perangkat. Ini tidak memverifikasi identitas orang tersebut. Sentuhan sederhana pada kunci keamanan, tanpa pemeriksaan identitas lebih lanjut, dapat mencukupi untuk kehadiran pengguna. Untuk passkeys / WebAuthn, pengguna selalu harus hadir.

Nilai yang Mungkin

• Required: Operasi harus memiliki verifikasi pengguna.
• Preferred: Operasi sebaiknya memiliki verifikasi pengguna jika memungkinkan, tetapi dapat dilanjutkan tanpanya.
• Discouraged: Operasi sebaiknya tidak memiliki verifikasi pengguna.

Kasus Penggunaan & Contoh

• Required: Ideal untuk aplikasi keamanan tinggi seperti perbankan atau kesehatan, di mana memverifikasi identitas pengguna (misalnya, melalui sidik jari atau PIN) sangat penting.
• Preferred: Berguna untuk aplikasi umum di mana keamanan tambahan adalah bonus tetapi tidak mutlak diperlukan.
• Discouraged: Cocok untuk operasi berisiko rendah atau skenario di mana verifikasi pengguna mungkin merepotkan.

Pola

• Lampiran authenticator: platform
• Resident key: required
• Verifikasi pengguna: required

Contoh: Sebuah aplikasi perusahaan ingin karyawan login tanpa kata sandi di laptop yang dikeluarkan perusahaan menggunakan pembaca sidik jari bawaan. Kredensial disimpan di perangkat, dan pengguna harus memverifikasi dengan sidik jari setiap kali.

Pola

• Lampiran authenticator: cross-platform
• Resident key: required
• Verifikasi pengguna: required

Contoh: Seorang pengguna mendaftarkan kunci keamanan (misalnya, YubiKey) untuk perbankan online mereka. Mereka dapat menggunakan kunci ini untuk mengautentikasi di perangkat apa pun dengan menyediakan kunci keamanan (misalnya, YubiKey), tanpa perlu memasukkan nama pengguna.

Banyak kunci keamanan berbasis perangkat keras (misalnya, YubiKeys) memiliki batasan penyimpanan yang melekat. Batasan ini disebabkan oleh memori fisik yang tersedia di perangkat dan pertimbangan desain dari produsen.

Contoh: Sebuah YubiKey mungkin memiliki kapasitas untuk menyimpan hanya 20 resident keys. Setelah batas ini tercapai, tidak ada resident key tambahan yang dapat ditambahkan tanpa menghapus yang sudah ada.

Solusi:

• Penggunaan Selektif Resident Keys: Alih-alih menggunakan resident keys untuk setiap pengguna, pertimbangkan untuk peran atau skenario tertentu. Misalnya, prioritaskan resident keys untuk peran admin atau pengguna dengan hak istimewa tinggi yang memerlukan keamanan yang ditingkatkan.
• Edukasi Pengguna: Informasikan kepada pengguna tentang batasan kunci keamanan mereka (misalnya, YubiKeys). Dorong mereka untuk beralih ke perangkat yang dapat menggunakan resident keys tanpa batas, misalnya, laptop atau smartphone.

Authenticator yang berbeda mungkin menangani permintaan resident key secara berbeda. Beberapa mungkin secara default membuat resident key meskipun tidak diminta secara eksplisit, sementara yang lain mungkin memerlukan instruksi eksplisit.

Perilaku yang tidak konsisten untuk opsi server WebAuthn yang berbeda pada platform yang berbeda adalah masalah utama. Misalnya, iOS akan selalu membuat resident key terlepas dari opsi server WebAuthn yang diteruskan, sementara Android memerlukan persetujuan (misalnya, dengan residentKey: preferred atau residentKey: required).

Selain perilaku, yang lebih buruk adalah bahwa berdasarkan data yang disimpan di sisi server, Anda tidak dapat mengatakan dengan kepastian 100% apakah kredensial yang disimpan adalah resident key atau non-resident key. Sebaliknya, Anda dapat mengikuti beberapa pemeriksaan dan mempersempitnya (lihat di bawah), tetapi masih perlu berharap bahwa perilaku kredensial sesuai dengan keyakinan Anda.

Alasannya adalah bahwa ada saran WebAuthn untuk menyimpan informasi tentang jenis kredensial (resident key atau non-resident key) dalam ekstensi properti kredensial (clientExtensionResults.credProps.rk yang bernilai true atau false). Namun, memberikan informasi ini ke RP tidak dijamin karena semua ekstensi WebAuthn bersifat opsional, misalnya, iOS tidak mengirimkannya (sehingga Anda tidak tahu apakah itu resident key atau non-resident key).

Selama penelitian kami, kami mencoba menguji perilaku pada platform dan authenticator yang berbeda (Windows 10, Windows 11, Android 7, Android 13, iOS17, macOS Ventura, YubiKey) dengan dua halaman demo WebAuthn yang memberikan detail lebih lanjut tentang kredensial yang dibuat: https://webauthn.io dan https://webauthntest.identitystandards.io/. Yang terakhir menawarkan kemungkinan untuk bekerja dengan properti requireResidentKey warisan (WebAuthn Level 1) dan bahkan menggabungkannya dengan properti residentKey (WebAuthn Level 2). Namun, hasilnya tidak dapat diandalkan (misalnya, dinyatakan non-resident key untuk iOS tetapi jelas conditional UI berfungsi).

Skema pemeriksaan yang paling dapat dipercaya yang kami temukan adalah sebagai berikut:

1. Periksa pengaturan server WebAuthn Anda untuk atribut "residentKey"
   1. Jika "residentKey: required" dan kredensial berhasil dibuat -> itu adalah resident key
   2. Jika "residentKey: preferred" atau "residentKey: discouraged", maka lanjutkan ke pemeriksaan berikutnya
2. Apakah ekstensi credProps.rk didukung dan disimpan dalam kredensial di server?
   1. Jika credProps.rk = true, kredensial tersebut adalah resident key
   2. Jika credProps.rk = false, kredensial tersebut adalah non-resident key
   3. Jika credProps kosong, maka jenis kredensial tidak diketahui

Seperti yang Anda lihat, ini membantu mempersempitnya, namun opsi tidak diketahui tetap ada dan Anda tidak dapat menentukan jenis kunci dengan kepastian 100%.

Ini juga sejalan dengan temuan William Brown dari SUSE dalam artikel hebatnya yang menguraikan bagaimana kunci keamanan (misalnya, YubiKeys) bisa menjadi tidak berguna jika resident keys disyaratkan oleh Relying Parties (kami memperluas tabelnya):

Dalam tabel, Anda melihat untuk opsi resident key server WebAuthn yang berbeda apakah resident key dibuat (true), apakah non-resident key dibuat (false), atau sesuatu yang lain terjadi.

Solusi:

• Pengujian Menyeluruh: Sebelum menerapkan, uji implementasi WebAuthn Anda di berbagai authenticator populer untuk memahami perilakunya.
• Pengaturan Server Eksplisit: Saat menyiapkan server WebAuthn Anda, jelaskan persyaratan Anda secara eksplisit. Jika Anda hanya ingin memiliki passkeys, maka atur opsi residentKey ke required (catatan: ini mungkin menyebabkan tantangan lain dengan authenticator dengan kapasitas resident key terbatas, lihat di atas).

Jika pengguna mencapai batas penyimpanan pada kunci keamanan mereka (misalnya, YubiKey), mereka mungkin menghadapi kesalahan atau tidak dapat mendaftarkan kredensial baru. Hal ini dapat menyebabkan kebingungan dan frustrasi.

Solusi:

• Penanganan Kesalahan yang Baik: Terapkan pesan kesalahan yang jelas yang memberi tahu pengguna saat kunci keamanan mereka (misalnya, YubiKey) penuh dan berikan panduan tentang cara menyelesaikan masalah tersebut.
• Alur Kerja Terpandu: Tawarkan panduan langkah demi langkah atau tutorial tentang bagaimana pengguna dapat mengelola resident keys mereka, memastikan mereka dapat menyelesaikan masalah secara mandiri.

9. Praktik Terbaik untuk Developer dan Manajer Produk

Seperti yang telah Anda lihat di atas, pengaturan server WebAuthn yang Anda pilih dapat secara signifikan memengaruhi pengalaman pengguna dan keamanan proses autentikasi Anda. Sangat penting untuk memahami nuansa pengaturan ini untuk membuat keputusan yang tepat.

Resident vs. Non-resident Keys: Jika sebagian besar pengguna Anda terutama mengakses layanan Anda dari perangkat pribadi seperti smartphone atau laptop, resident keys adalah pilihan yang cocok. Resident keys disimpan di perangkat itu sendiri dan menawarkan pengalaman autentikasi yang mulus bagi pengguna yang sering menggunakan perangkat yang sama. Namun, bagi pengguna yang menggunakan kunci keamanan (misalnya, YubiKeys), non-resident keys mungkin lebih sesuai.

Pengaturan Verifikasi Pengguna (UV): Bergantung pada tingkat keamanan yang ingin Anda capai, Anda dapat memutuskan seberapa ketat proses verifikasi pengguna seharusnya. Jika Anda mengincar keamanan tinggi, memerlukan PIN, sidik jari, atau pengenalan wajah (userVerification: preferred atau userVerification: required) adalah tindakan yang disarankan.

Attestation dan Kepercayaan: Attestation memungkinkan Anda untuk memverifikasi asal dan integritas authenticator. Putuskan apakah Anda ingin mempercayai semua authenticator atau hanya yang berasal dari produsen tertentu. Ini bisa menjadi sangat penting jika Anda berurusan dengan data sensitif dan ingin memastikan bahwa hanya authenticator berkualitas tinggi dan tepercaya yang digunakan.

Mekanisme Fallback: Selalu siapkan mekanisme fallback. Jika pengguna kehilangan authenticator mereka atau jika terjadi malfungsi, mereka harus memiliki cara alternatif untuk mengakses akun mereka. Ini bisa melalui kode cadangan, verifikasi SMS, tautan ajaib email, atau metode autentikasi multifaktor lainnya.

Edukasi Berkelanjutan: Lanskap passkeys dan WebAuthn terus berkembang. Tetap update dengan perkembangan terbaru, kerentanan, dan perbaikan. Dorong tim pengembangan Anda untuk berpartisipasi dalam lokakarya, webinar, dan konferensi terkait passkeys dan WebAuthn.

Onboarding dan Edukasi Pengguna: Saat memperkenalkan autentikasi passkey, pastikan pengguna Anda memahami manfaatnya dan cara kerjanya. Tawarkan instruksi yang jelas selama proses pendaftaran dan sediakan sumber daya (seperti FAQ atau tutorial video) untuk membantu pengguna dalam menyiapkan dan menggunakan passkeys.

Dengan mematuhi praktik terbaik ini, developer dan manajer produk dapat memastikan bahwa mereka menerapkan autentikasi passkey secara efektif, menyeimbangkan keamanan dan pengalaman pengguna.

Jika Anda ingin mengimplementasikan passkeys untuk adopsi massal di situs web atau aplikasi Anda dan tidak perlu mendukung kunci keamanan (misalnya, YubiKeys), karena sebagian besar pengguna Anda hanya akan menggunakan smartphone atau laptop mereka, kami merekomendasikan pengaturan berikut.

• authenticator: platform
• residentKey: required
• userVerification: required

Manfaat:

• Karena semua kunci yang dibuat adalah resident keys, pengaturan ini memungkinkan Conditional UI membuat login Anda lebih mulus bagi pengguna karena mereka tidak perlu mengingat nama pengguna.
• Semua perangkat modern dari Apple, Google, dan Microsoft didukung dan menggunakan passkeys.

Pengaturan server WebAuthn, meskipun kompleks, menawarkan kerangka kerja yang kuat dan fleksibel untuk autentikasi. Menguasai pengaturan ini sangat penting, karena ini bukan hanya tentang mengimplementasikan standar baru; ini tentang memperbaiki keamanan dan efisiensi autentikasi pengguna secara fundamental.

Intinya, memahami pengaturan server WebAuthn adalah investasi dalam membangun aplikasi yang lebih aman, efisien, dan berwawasan ke depan. Seiring berkembangnya lanskap digital, menguasai teknologi semacam itu akan menjadi sangat diperlukan. Untuk tetap update, bergabunglah dengan komunitas passkeys kami atau berlangganan buletin kami di bawah ini.