FIDO2: WebAuthn, Kunci Sandi, dan Keamanan (ID)

FIDO2 terdiri dari dua standar autentikasi kunci publik: World Wide Web Consortium’s Web Authentication API (WebAuthn) dan FIDO Alliance Client to Authenticator Protocol (CTAP). Bersama-sama, keduanya memungkinkan pihak pengelola untuk mendaftarkan dan menggunakan kredensial kriptografi tanpa menyimpan rahasia bersama yang dapat digunakan kembali seperti kata sandi.

FIDO2 dapat menyediakan autentikasi yang tahan phishing dan tahan putar ulang jika diimplementasikan dan divalidasi dengan benar. Ini tidak membuktikan identitas hukum seseorang, memutuskan siapa yang boleh mendaftar, mengamankan sesi server yang disusupi, atau memperbaiki proses pemulihan akun yang lemah. Itu adalah kontrol tambahan yang harus dirancang di sekitar proses autentikasi.

Poin-poin Penting

• FIDO2 adalah WebAuthn ditambah CTAP. WebAuthn menghubungkan situs web atau aplikasi ke klien; CTAP menghubungkan platform klien ke autentikator keliling.
• Kunci privat tetap ada pada autentikator. Pihak pengelola menyimpan kunci publik dan memverifikasi tanda tangan atas tantangan baru dan konteks yang dilingkupkan.
• Pengikatan domain menciptakan ketahanan phishing. Kredensial yang terdaftar untuk satu pengidentifikasi pihak pengelola tidak dapat dengan mudah diputar ulang ke domain penyerang yang tidak terkait.
• Kunci sandi adalah kredensial FIDO. Kunci sandi dapat terikat perangkat atau disinkronkan di seluruh perangkat penyedia, menciptakan trade-off jaminan, pemulihan, dan portabilitas yang berbeda.
• Pemulihan adalah bagian dari model keamanan. Login FIDO2 yang kuat dapat dilewati jika email, dukungan, atau jalur pemulihan identitas dapat mengganti kredensial dengan bukti yang lebih lemah.

Apa itu FIDO2?

Ikhtisar spesifikasi FIDO Alliance mendefinisikan FIDO2 sebagai kombinasi spesifikasi W3C WebAuthn dan FIDO Client to Authenticator Protocols. Standar-standar ini membagi sistem ke dalam peran yang saling bekerja sama:

• Pihak pengelola (Relying party): situs web atau layanan yang mendaftarkan kredensial dan memverifikasi pernyataan autentikasi.
• Klien: biasanya browser atau komponen sistem operasi yang mengimplementasikan WebAuthn dan memediasi proses.
• Autentikator: komponen platform atau perangkat eksternal yang membuat dan menggunakan kunci kredensial.
• Pengguna: orang yang menyetujui pendaftaran atau autentikasi dan dapat memverifikasi secara lokal dengan PIN, kata sandi, atau biometrik.

Spesifikasi W3C WebAuthn Level 3 mendefinisikan API web untuk membuat dan menggunakan kredensial kunci publik yang dilingkupkan ke pihak pengelola. Skrip tidak pernah menerima kunci kredensial privat. Mereka menerima data terstruktur dan bukti kriptografi yang dihasilkan melalui autentikator dan klien.

Perbandingan FIDO2, WebAuthn, CTAP, U2F, dan kunci sandi

Istilah	Makna praktis	Batas utama
FIDO2	Standar WebAuthn dan CTAP yang digunakan bersama	Keluarga standar lengkap, bukan satu panggilan API
WebAuthn	API browser atau klien dan model data pihak pengelola untuk kredensial kunci publik	Menghubungkan pihak pengelola ke klien
CTAP2	Protokol antara platform klien dan autentikator roaming	Membawa komunikasi autentikator eksternal melalui transportasi seperti USB, NFC, dan BLE
U2F / CTAP1	Protokol FIDO sebelumnya yang umumnya terkait dengan kunci keamanan faktor kedua	Lebih terbatas dari kemampuan FIDO2 modern
Kunci Sandi	Kredensial FIDO yang dapat ditemukan yang dirancang untuk masuk tanpa kata sandi	Dapat disinkronkan atau terikat perangkat
Kunci keamanan	Autentikator perangkat keras roaming yang terhubung melalui USB, NFC, atau transportasi lain yang didukung	Salah satu bentuk autentikator yang mungkin
Autentikator platform	Autentikator yang terpasang pada perangkat atau sistem operasi	Sering diaktifkan dengan PIN lokal atau biometrik

“Tanpa sandi” menggambarkan perjalanan pengguna, bukan setiap penerapan yang mungkin. Sebuah layanan dapat menggunakan WebAuthn sebagai faktor kedua setelah kata sandi, sebagai kredensial multi-faktor utama, atau bersama autentikator lain. Pihak pengelola harus memutuskan karakteristik dan bendera kredensial mana yang memenuhi jaminan tindakan yang dilindungi.

Cara kerja pendaftaran FIDO2

Pendaftaran, juga disebut pembuatan kredensial, mengikat kredensial kunci publik baru ke akun di pihak pengelola.

1. Server membuat opsi pendaftaran

Pihak pengelola menghasilkan tantangan baru yang tidak dapat diprediksi dan mengirimkan opsi pembuatan kredensial kunci publik ke klien. Opsi mengidentifikasi pihak pengelola, akun pengguna, algoritma yang diterima, preferensi autentikator, preferensi atestasi, dan pengidentifikasi kredensial yang ada yang dikecualikan jika relevan.

Tantangan harus sekali pakai, berumur pendek, terikat pada sesi dan pengguna yang benar, dan disimpan atau dapat diverifikasi oleh server. Tantangan yang hanya dihasilkan di browser tidak dapat melindungi proses server.

2. Klien memanggil WebAuthn

Aplikasi memanggil navigator.credentials.create() dengan opsi kunci publik. Browser memeriksa asal dan konteks keamanan, lalu meminta autentikator yang tersedia untuk membuat kredensial.

3. Autentikator memperoleh persetujuan pengguna

Autentikator memerlukan keberadaan pengguna dan, jika diminta dan didukung, verifikasi pengguna. Keberadaan pengguna dapat berupa sentuhan atau tindakan eksplisit. Verifikasi pengguna berarti autentikator memverifikasi pengguna secara lokal melalui PIN, rahasia perangkat, biometrik, atau metode lain yang didukung.

Biometrik lokal biasanya membuka penggunaan kredensial; templat biometrik tidak dikirim ke situs web sebagai rahasia autentikasi.

4. Autentikator membuat pasangan kunci

Autentikator membuat pasangan kunci kredensial yang dilingkupkan ke pihak pengelola. Kunci privat tetap dilindungi oleh autentikator atau fabric sinkronisasinya. Kredensial yang dihasilkan berisi kunci publik, pengidentifikasi kredensial, data autentikator, data klien, dan informasi atestasi sesuai dengan format yang dipilih.

5. Server memvalidasi dan menyimpan kredensial

Pihak pengelola memvalidasi proses sebelum menyimpan apa pun. Pemeriksaan meliputi:

• tantangan yang diharapkan;
• asal yang diharapkan;
• hash pengidentifikasi pihak pengelola yang benar;
• status lintas-asal yang diharapkan dan topOrigin ketika proses disematkan;
• bendera keberadaan pengguna dan verifikasi pengguna sesuai kebijakan;
• algoritma dan parameter kunci yang diterima;
• struktur atestasi dan kebijakan kepercayaan jika atestasi diminta;
• keunikan dan asosiasi dengan akun pengguna yang benar.

Server menyimpan pengidentifikasi kredensial, kunci publik, pengikatan akun, penghitung tanda tangan atau status yang berlaku, transportasi atau metadata yang berguna, dan informasi siklus hidup kredensial. Server tidak pernah membutuhkan kunci privat.

Cara kerja autentikasi FIDO2

Autentikasi membuktikan kontrol atas kredensial yang sebelumnya terdaftar.

1. Server membuat opsi permintaan

Pihak pengelola menghasilkan tantangan baru dan mengirimkan opsi pernyataan. Ini mungkin termasuk daftar putih pengidentifikasi kredensial atau menggunakan kredensial yang dapat ditemukan sehingga autentikator dapat mengidentifikasi akun.

2. Klien meminta pernyataan

Aplikasi memanggil navigator.credentials.get(). Browser dan autentikator memilih kredensial yang sesuai dan memperoleh keberadaan pengguna yang diperlukan atau verifikasi pengguna lokal.

3. Autentikator menandatangani data proses

Autentikator menandatangani konteks tantangan baru dan data autentikator menggunakan kunci privat kredensial. Karena kredensial dilingkupkan ke pihak pengelola, asal phishing yang tidak terkait tidak dapat meminta autentikator untuk menghasilkan pernyataan yang valid untuk layanan yang sebenarnya.

4. Server memverifikasi pernyataan

Pihak pengelola memverifikasi tantangan yang diharapkan, asal, hash pihak pengelola, tanda tangan dengan kunci publik yang disimpan, bendera yang diperlukan, kredensial yang diizinkan, pengikatan pengguna, dan penghitung atau status cadangan yang relevan. Hanya setelah itu server harus membuat atau meningkatkan sesi aplikasi.

Setiap pernyataan membuktikan kontrol pada suatu waktu. Pembuatan sesi, perlindungan token, reautentikasi, otorisasi transaksi, logout, dan pencabutan tetap menjadi tanggung jawab aplikasi yang terpisah.

Mengapa FIDO2 tahan phishing

Kata sandi dan kode satu kali dapat dimasukkan ke situs penipu, yang dapat meneruskannya ke layanan yang sebenarnya. FIDO2 menggunakan kredensial yang dilingkupkan ke pihak pengelola dan secara kriptografis mengikat pernyataan ke konteks verifier yang diharapkan.

Persyaratan autentikator NIST SP 800-63B-4 menggambarkan WebAuthn sebagai tahan phishing melalui pengikatan nama verifier. Output autentikator terikat pada nama domain yang diautentikasi alih-alih bergantung pada pengguna yang menyadari halaman yang menipu.

Ketahanan phishing memiliki batasan:

• Ini tidak menghentikan malware atau penyerang yang sudah mengendalikan sesi yang diautentikasi.
• Ini tidak mencegah pengguna menyetujui transaksi berbahaya di dalam layanan asli.
• Ini tidak mengamankan jalur pemulihan akun yang dapat mengganti kredensial.
• Ini tidak membuktikan bahwa orang yang mengendalikan autentikator adalah orang nyata yang ingin didaftarkan oleh suatu organisasi.

Ketahanan putar ulang dan penanganan tantangan

Pernyataan yang direkam tidak boleh berfungsi dalam proses selanjutnya karena setiap permintaan menggunakan tantangan baru. NIST menggambarkan autentikator kriptografi yang menggabungkan nonces atau tantangan sebagai tahan putar ulang.

Kesalahan implementasi dapat menghilangkan properti tersebut. Kegagalan umum meliputi tantangan yang dapat diprediksi, penggunaan kembali tantangan, menerima tantangan untuk akun yang salah, tidak memberlakukan kedaluwarsa, atau hanya memvalidasi tanda tangan sambil mengabaikan asal dan konteks pihak pengelola.

Server harus menandai tantangan yang dikonsumsi secara atomik. Jika permintaan paralel bersaing, hanya satu proses yang berhasil yang dapat menggunakan tantangan tersebut.

Keberadaan pengguna dan verifikasi pengguna

WebAuthn membedakan:

• Keberadaan pengguna (UP): pengguna melakukan interaksi yang menunjukkan partisipasi.
• Verifikasi pengguna (UV): autentikator memverifikasi pengguna secara lokal melalui faktor aktivasi seperti PIN atau biometrik.

Keberadaan saja bukanlah autentikasi multi-faktor. Layanan yang melindungi tindakan berisiko tinggi mungkin memerlukan bendera UV dan menolak pernyataan yang hanya menunjukkan keberadaan. Persyaratan harus menyatakan nilai bendera yang diharapkan daripada mengandalkan label antarmuka seperti “Gunakan Face ID.”

Kualitas verifikasi lokal juga bervariasi berdasarkan autentikator. Pihak pengelola mungkin memiliki visibilitas terbatas ke implementasi biometrik atau PIN yang tepat untuk autentikator yang disediakan pengguna, sehingga kebijakan harus proporsional dengan transaksi dan populasi penerapan.

Autentikator platform, roaming, dan lintas-perangkat

Autentikator platform

Ini terintegrasi dengan ponsel, laptop, atau sistem operasi. Mereka dapat menyediakan perjalanan singkat menggunakan metode buka kunci lokal perangkat. Trade-offnya adalah ketergantungan pada pemulihan akun platform, keamanan perangkat, dan perilaku sinkronisasi.

Autentikator roaming

Kunci keamanan eksternal dapat dibawa antar perangkat dan dihubungkan melalui transportasi yang didukung. Kunci ini berguna untuk penggunaan tenaga kerja, administrasi, atau kasus penggunaan jaminan tinggi, terutama ketika non-eksporabilitas kredensial dan penerbitan yang terkelola menjadi penting.

Autentikasi lintas-perangkat

Alur hibrida dapat menggunakan ponsel terdekat untuk mengautentikasi sesi di perangkat lain. Mekanisme serah terima dan kedekatan meningkatkan kegunaan tetapi menambahkan detail antarmuka pengguna dan model ancaman yang harus diuji daripada diperlakukan sama dengan autentikasi perangkat yang sama.

Mendukung beberapa kredensial per akun. Pengguna mengganti ponsel, kehilangan kunci keamanan, menggunakan perangkat kerja dan pribadi, dan membutuhkan cara yang aman untuk menamai, memeriksa, dan menghapus kredensial.

Kunci sandi terikat perangkat dan tersinkronisasi

Kunci sandi adalah kredensial FIDO yang dirancang untuk masuk tanpa kata sandi. Kunci sandi dapat berupa:

• Terikat perangkat: kunci privat kredensial tetap terikat pada satu autentikator atau perangkat yang dikelola.
• Tersinkronisasi: materi kredensial dienkripsi dan disinkronkan melalui fabric penyedia untuk digunakan di seluruh perangkat yang memenuhi syarat.

Kunci sandi yang tersinkronisasi meningkatkan ketersediaan dan pemulihan, sementara kredensial terikat perangkat dapat memberikan non-eksporabilitas yang lebih kuat. Panduan autentikator yang dapat disinkronkan NIST SP 800-63B-4 mengizinkan autentikator yang dapat disinkronkan dalam konteks hingga Authentication Assurance Level 2 ketika persyaratannya terpenuhi, tetapi sinkronisasi bertentangan dengan non-eksporabilitas yang diperlukan pada Level 3.

Jangan menyimpulkan jaminan dari kata “kunci sandi.” Evaluasi apakah kredensial dicadangkan, memenuhi syarat untuk pencadangan, dibagikan, dikelola, terikat perangkat, diatesasi, dan diaktifkan dengan verifikasi pengguna sesuai kebijakan pihak pengelola.

Atestasi dan kepercayaan autentikator

Atestasi dapat memberikan bukti tentang asal atau properti autentikator pada saat pendaftaran. Ini tidak sama dengan tanda tangan autentikasi, dan tidak mengidentifikasi pengguna manusia.

Layanan konsumen seringkali meminimalkan pengumpulan atestasi untuk privasi dan kompatibilitas ekosistem. Penerapan tenaga kerja yang terkelola mungkin memerlukan model atau sertifikasi autentikator tertentu. Keputusan harus menjawab pertanyaan model ancaman daripada mengumpulkan bukti identifikasi perangkat secara default.

Jika atestasi digunakan:

• tentukan format yang diterima dan anchor kepercayaan;
• validasi jalur sertifikat dan pernyataan dengan benar;
• tentukan pembaruan metadata dan penanganan pencabutan;
• rencana untuk autentikator tanpa atestasi tepercaya;
• dokumentasikan konsekuensi privasi dan retensi;
• uji penggantian ketika model yang diterima berubah status.

FIDO2 tidak menggantikan pembuktian identitas

FIDO2 membuktikan kontrol atas kredensial yang terdaftar ke pihak pengelola. Ini tidak menetapkan nama hukum, usia, alamat, status peraturan, atau keunikan dunia nyata dari orang yang mendaftarkannya.

Perbedaan itu menciptakan tiga pola umum:

1. Pendaftaran pseudonim: layanan membutuhkan akun yang aman tetapi bukan identitas dunia nyata yang terverifikasi.
2. Pendaftaran terikat identitas: pembuktian identitas terjadi terlebih dahulu, kemudian kredensial FIDO diikat ke akun yang terverifikasi.
3. Step-up atau pemulihan: layanan memverifikasi ulang identitas atau menggunakan bukti kuat lainnya sebelum mengizinkan autentikator yang hilang diganti.

Pengikatan harus eksplisit. Catat akun dan status pembuktian apa yang ada saat kredensial ditambahkan, sesi mana yang mengotorisasinya, dan apakah risiko selanjutnya harus memicu reautentikasi atau penyegaran identitas.

Pemulihan akun dan siklus hidup kredensial

Pemulihan adalah tempat banyak penerapan tahan phishing mengalami penurunan. Jika pengguna dapat mengganti setiap kredensial FIDO menggunakan tautan email atau pertanyaan dukungan yang lemah, penyerang akan menargetkan jalur tersebut.

Siklus hidup lengkap mencakup:

• menambahkan autentikator kedua;
• menamai dan melihat kredensial terdaftar;
• kehilangan perangkat dan dugaan kompromi;
• mencabut satu kredensial tanpa menghancurkan akun;
• memulihkan dengan kode, autentikator lain, dukungan terkelola, atau pembuktian identitas;
• memberitahu pengguna melalui saluran independen;
• menunda atau membatasi tindakan berisiko tinggi setelah pemulihan;
• mencatat siapa yang mengubah set kredensial dan mengapa;
• menutup sesi yang dibuat sebelum kompromi dilaporkan.

Jaminan pemulihan harus sesuai dengan konsekuensi penggantian autentikator. Akun komunitas berisiko rendah dan administrator yang dapat memindahkan dana tidak membutuhkan jalur yang sama.

Cara mengevaluasi penerapan FIDO2

Validasi protokol

Uji pembuatan dan kedaluwarsa tantangan, validasi asal yang tepat, aturan pengidentifikasi pihak pengelola, verifikasi tanda tangan, algoritma yang didukung, kebijakan UP dan UV, asosiasi kredensial, penghitung, bendera cadangan, dan penanganan kesalahan. Lebih disukai menggunakan pustaka server yang terawat daripada penguraian biner yang ditulis tangan, sambil tetap memahami apa yang divalidasinya.

Cakupan autentikator

Uji autentikator platform dan roaming di seluruh browser, sistem operasi, perangkat, transportasi, kebijakan perusahaan, dan pengaturan aksesibilitas yang didukung. Sertakan pembuatan kredensial, masuk, antarmuka pengguna kondisional, penggunaan lintas-perangkat, dan penggantian perangkat.

Keamanan akun dan sesi

Tinjau siapa yang dapat menambahkan kredensial, apakah autentikasi terbaru diperlukan, bagaimana sesi ditingkatkan, kapan reautentikasi terjadi, dan bagaimana perubahan kredensial memengaruhi sesi yang ada.

Pemulihan dan dukungan

Tim merah kehilangan, perangkat dicuri, email disusupi, perubahan SIM, peniruan dukungan, dan akses rumah tangga atau tempat kerja yang berbahaya. Ukur ketahanan penyerang dan penyelesaian pengguna asli.

Privasi dan kemampuan observasi

Minimalkan atestasi dan data perangkat sesuai kebutuhan kebijakan. Hindari menggunakan pengidentifikasi kredensial stabil di seluruh pihak pengelola; cakupan WebAuthn dirancang untuk mencegah hal itu. Catat alasan dan hasil proses tanpa membocorkan data klien yang sensitif.

Kesalahan implementasi FIDO2 yang umum

Memeriksa tanda tangan tetapi tidak konteks

Tanda tangan yang valid tidak cukup jika server gagal memverifikasi tantangan, asal, pengidentifikasi pihak pengelola, bendera, dan pengikatan akun secara tepat.

Menyebut setiap kunci sandi multi-faktor

Server harus memverifikasi apakah verifikasi pengguna terjadi dan apakah karakteristik kredensial memenuhi kebijakan. Keberadaan pengguna saja tidak sama dengan verifikasi pengguna lokal.

Mengizinkan penambahan kredensial secara diam-diam

Menambahkan autentikator baru mengubah keamanan akun. Membutuhkan autentikasi terbaru yang sesuai atau proses pemulihan, memberitahu pengguna, dan mencatat peristiwa tersebut.

Hanya mendukung satu kredensial

Akun satu kredensial menciptakan pemulihan yang rapuh dan mendorong fallback yang lebih lemah. Izinkan beberapa autentikator dengan manajemen dan pencabutan yang jelas.

Meninggalkan kata sandi sebagai fallback yang setara

Jika kata sandi selalu dapat melewati jalur FIDO, ketahanan phishing mungkin hanya ada pada tombol yang disukai. Batasi atau hapus jalur yang lebih lemah sesuai risiko dan tahap migrasi.

Mengabaikan sesi server

FIDO2 mengautentikasi proses login. Lindungi cookie dan token, putar sesi setelah autentikasi, minta step-up untuk tindakan sensitif, dan cabut sesi yang disusupi.

Daftar periksa penerapan

Sebelum peluncuran, pastikan bahwa:

• tantangan tidak dapat diprediksi, sekali pakai, berumur pendek, dan terikat pada sesi yang benar;
• asal, pengidentifikasi pihak pengelola, tanda tangan, algoritma, bendera, dan kepemilikan kredensial divalidasi;
• persyaratan UP dan UV eksplisit untuk setiap tindakan yang dilindungi;
• kasus platform, roaming, tersinkronisasi, terikat perangkat, dan lintas-perangkat diuji sesuai dukungan;
• pengguna dapat mendaftarkan beberapa kredensial dan dengan aman menamai, memeriksa, dan mencabutnya;
• penambahan kredensial dan pemulihan membutuhkan jaminan yang proporsional dan menghasilkan pemberitahuan;
• pengumpulan atestasi memiliki kebijakan kepercayaan, privasi, dan metadata yang ditentukan;
• kata sandi, kode satu kali, dukungan, dan fallback pemulihan identitas dimodelkan ancamannya;
• sesi yang diautentikasi dan otorisasi transaksi dilindungi secara terpisah;
• pustaka protokol, dukungan browser, depresiasi, dan peristiwa keamanan memiliki pemilik.

Posisi Didit terkait FIDO2

FIDO2 menangani autentikasi setelah kredensial terdaftar. Didit dapat mendukung keputusan identitas terkait melalui Verifikasi ID, Deteksi Kehidupan (Liveness Detection), dan Autentikasi Biometrik. Harga Autentikasi Biometrik yang dipublikasikan adalah $0.10 per pemeriksaan.

Tim dapat meninjau tarif modul saat ini di halaman harga. Produk-produk ini tidak boleh diasumsikan mengimplementasikan FIDO2 dari deskripsi tersebut: poin arsitekturnya adalah bahwa pembuktian identitas, pemeriksaan biometrik, autentikasi kredensial FIDO, pemulihan akun, dan otorisasi aplikasi adalah keputusan kepercayaan yang berbeda.

Pertanyaan yang sering diajukan

Apa kepanjangan FIDO2?

FIDO mengacu pada Fast Identity Online. FIDO2 adalah keluarga standar yang menggabungkan W3C WebAuthn dengan FIDO Alliance CTAP untuk autentikasi kunci publik.

Apakah FIDO2 sama dengan WebAuthn?

Tidak. WebAuthn mendefinisikan API pihak pengelola dan klien serta model data. FIDO2 mencakup WebAuthn ditambah CTAP, yang menghubungkan platform klien dengan autentikator roaming.

Apakah kunci sandi kredensial FIDO2?

Ya. Kunci sandi adalah kredensial FIDO yang dapat ditemukan yang dirancang untuk masuk tanpa kata sandi. Kunci sandi dapat disinkronkan di seluruh perangkat yang memenuhi syarat atau tetap terikat perangkat.

Apakah FIDO2 tahan phishing?

Autentikasi FIDO2 yang divalidasi dengan benar tahan phishing karena kredensial dilingkupkan ke pihak pengelola dan pernyataan terikat pada konteks verifier tersebut. Pemulihan yang lemah atau sesi yang sudah disusupi masih dapat melewati perlindungan yang dimaksudkan.

Apakah FIDO2 menggunakan biometrik?

Ini dapat menggunakan biometrik lokal untuk mengaktifkan autentikator dan mengatur verifikasi pengguna. Pihak pengelola biasanya menerima hasil dan pernyataan kriptografi, bukan templat biometrik.

Apakah FIDO2 memverifikasi identitas seseorang?

Tidak. Ini memverifikasi kontrol atas kredensial terdaftar. Pembuktian identitas dunia nyata adalah keputusan pendaftaran atau pemulihan terpisah ketika layanan membutuhkannya.

Apa yang terjadi ketika pengguna kehilangan setiap autentikator?

Layanan membutuhkan kebijakan pemulihan yang proporsional dengan risiko akun. Opsi dapat mencakup autentikator terdaftar lainnya, kode pemulihan, pemulihan administratif terkelola, atau pembuktian identitas yang diperbarui, dengan pemberitahuan dan pembatasan pasca-pemulihan.

Referensi utama

• Spesifikasi Autentikasi Pengguna FIDO Alliance
• Snapshot Rekomendasi Kandidat W3C Web Authentication Level 3
• Standar yang Diusulkan FIDO Alliance CTAP 2.3
• NIST SP 800-63B-4: Manajemen Autentikasi dan Autentikator
• Persyaratan autentikator NIST SP 800-63B-4

FIDO2 menggantikan rahasia verifier yang dapat digunakan kembali dengan kredensial kunci publik yang dilingkupkan dan proses kriptografi baru. Nilainya tetap ada hanya ketika pihak pengelola memvalidasi konteks penuh, mengelola siklus hidup kredensial, melindungi sesi dan tindakan sensitif, dan memberikan perhatian keamanan yang sama pada pemulihan seperti pada login.