Gesaan dan skop
Anda memiliki laman web yang sudah mempunyai log masuk kata laluan dan ingin menambah Passkey. Pada pelayar yang disokong, pengguna sepatutnya mengesahkan identiti dengan buka kunci platform atau kunci keselamatan sambil mengekalkan laluan sandaran dan pemulihan yang mudah difahami. Reka bentuk kerjasama frontend dan pelayan, termasuk navigator.credentials.create(), navigator.credentials.get(), cabaran (challenges), RP ID, semakan origin, dan sempadan kitaran hayat kelayakan (credentials).
WebAuthn ialah API pengesahan kunci awam antara pelayar dan pengesah (authenticator). Kunci peribadi kekal dalam pengesah dan laman web menyimpan kunci awam. Frontend memperoleh pilihan pelayan, memanggil API pelayar, mensirikan hasilnya, dan memaparkan keadaan; pelayan mesti mengesahkan tandatangan, menggunakan cabaran, dan mengikat kelayakan pada akaun.
Perkara yang diuji oleh penemu duga
Jawapan yang kukuh memisahkan pendaftaran dan log masuk kepada dua aliran berkeadaan (stateful) yang pendek: pelayan mencipta cabaran satu kali yang tidak dapat diramal, frontend memanggil pengesah, dan pelayan mengesahkan cabaran yang dikembalikan, origin, RP ID, tandatangan, serta pembilang (counter) sebelum mencipta sesi. Ia juga merangkumi konteks selamat HTTPS, pembatalan pengguna, tamat masa, penghijrahan peranti, berbilang kelayakan, dan pemulihan dan bukannya menganggap "Face ID muncul" sebagai kejayaan protokol.
Penemu duga akan melihat sama ada anda memahami bahawa pengisian automatik bersyarat ialah keupayaan UX, bukan pengganti bagi pengesahan pelayan. Mereka juga mungkin bertanya mengapa pemadaman kelayakan pelayan perlu diikuti dengan API isyarat (signal APIs) WebAuthn supaya pengesah dapat mengemas kini keadaannya.
Soalan untuk dijelaskan terlebih dahulu
Klien yang disokong dan dasar akaun
Sahkan pelayar sasaran, platform mudah alih dan desktop, sama ada kelayakan boleh ditemui yang diselaraskan (synced discoverable credentials) dibenarkan, dan sama ada kata laluan atau kunci keselamatan kekal tersedia. Pilihan tersebut mempengaruhi residentKey, userVerification, pemilihan kelayakan, dan teks bantuan.
Domain dan topologi penggunaan
Sahkan subdomain pengeluaran dan log masuk, iframe, proksi terbalik (reverse proxies), dan domain khusus penyewa (tenant-specific domains). RP ID mestilah domain berkaitan yang sah untuk origin semasa. Domain pratonton yang berpindah ke pengeluaran tidak boleh menggunakan semula konfigurasi secara andaian dengan selamat.
Pemulihan dan tindakan berisiko tinggi
Tanya bagaimana pengguna membuktikan kawalan apabila setiap pengesah hilang, dan sama ada tetapan semula membatalkan sesi, memberitahu pengguna, atau melambatkan tindakan berisiko tinggi. Pemulihan adalah sebahagian daripada kitaran hayat identiti; ia tidak boleh dikurangkan kepada sekadar pautan "gunakan kata laluan" di frontend.
Rangka kerja jawapan 30 saat
"Kedua-dua pendaftaran dan log masuk bermula dengan cabaran satu kali yang tidak dapat diramal daripada pelayan. Frontend menghantar pilihan kepada WebAuthn. Semasa pendaftaran, pelayan mengesahkan cabaran, origin, RP ID, dasar perakuan (attestation policy), dan kunci awam sebelum mengikat ID kelayakan pada akaun. Semasa log masuk, ia mengesahkan tandatangan penegasan (assertion), cabaran, RP ID, origin, dan pembilang tandatangan sebelum mencipta sesi. Frontend membezakan keadaan tidak disokong, dibatalkan, tamat masa, dan ditolak. Pengantaraan bersyarat (conditional mediation) boleh menyediakan pengisian automatik tetapi tidak diperlukan untuk ketepatan. Kehilangan peranti melalui pemulihan yang dikawal risiko, membatalkan sesi lama, dan membenarkan kelayakan baharu didaftarkan."
Penyelesaian langkah demi langkah
Langkah 1: Biarkan pelayan mencipta cabaran
Halaman pendaftaran atau log masuk terlebih dahulu meminta pelayan untuk mencipta aliran. Pelayan menjana sekurang-kurangnya 16 bait data cabaran rawak dan menyimpan cincangan (hash), akaun, tujuan, tamat tempoh, dan keadaan yang telah digunakan. Frontend tidak boleh menjana atau menggunakannya semula: jika tidak, penegasan lama boleh dialihkan ke aliran lain. Pelayan mengembalikan pilihan publicKey untuk RP semasa, dan frontend tidak menulis semula medan yang sensitif terhadap keselamatan.
Langkah 2: Reka bentuk pendaftaran
Dalam konteks selamat HTTPS, frontend memanggil navigator.credentials.create(). Pilihan merangkumi RP, ID pengguna, nama paparan, algoritma kunci awam yang diterima, keutamaan pengesahan pengguna, dan dasar kelayakan yang boleh ditemui. Selepas Promise selesai (resolves), frontend mensirikan ID kelayakan, data klien, respons perakuan, dan sambungan (extensions) yang diperlukan ke pelayan. Kunci peribadi tidak pernah meninggalkan pengesah.
Langkah 3: Sahkan pendaftaran pada pelayan
Pelayan menyemak bahawa cabaran sepadan dengan aliran, origin dibenarkan, cincangan RP ID adalah betul, serta tandatangan dan algoritma kunci awam memenuhi dasar. Ia memutuskan sama ada untuk mengesahkan perakuan berdasarkan matlamat privasi dan keserasian. Sekiranya berjaya, ia hanya menyimpan kunci awam, ID kelayakan, akaun, pembilang tandatangan, dan label peranti yang diperlukan. Ia tidak sepatutnya mengekalkan keseluruhan objek mentah atau data peranti yang boleh dikenal pasti selama-lamanya.
Langkah 4: Reka bentuk log masuk dan pengisian automatik bersyarat
Untuk log masuk, pelayan mencipta cabaran baharu dan frontend memanggil navigator.credentials.get() dengannya, kemudian menyerahkan penegasan tersebut. Pelayan mengesahkan cabaran, origin, RP ID, tandatangan, dan pembilang sebelum menentukan akaun daripada ID kelayakan. Dengan pengantaraan bersyarat, halaman boleh meminta kelayakan yang boleh ditemui selepas pengguna berinteraksi dengan medan nama pengguna, membolehkan pelayar menunjukkan Passkey dalam pengisian automatik. Ini mengubah UX penemuan, bukan kontrak pengesahan.
Langkah 5: Kendalikan keadaan dan kegagalan frontend
Pembatalan, tamat masa, pelayar yang tidak disokong, dasar kebenaran yang disekat, dan penolakan pelayan harus menjadi keadaan berbeza yang boleh difahami pengguna. AbortController boleh membatalkan panggilan yang belum selesai apabila pengguna pergi atau mengklik semula, menghalang Promise lama daripada menulis ganti keadaan semasa. Frontend tidak boleh memaparkan tandatangan, ID kelayakan, atau ralat dalaman pelayan, dan tidak boleh sesekali menandakan pendaftaran yang tidak lengkap sebagai berjaya.
Langkah 6: Pemulihan, pembatalan, dan pengurusan kelayakan
Tetapan akaun harus menyenaraikan label kelayakan, masa penciptaan, dan masa terakhir digunakan, serta membenarkan satu kelayakan dipadamkan. Selepas pelayan memadamkannya, ID kelayakan yang tidak diketahui kemudiannya boleh mencetuskan PublicKeyCredential.signalUnknownCredential(); log masuk yang berjaya boleh menggunakan signalAllAcceptedCredentials() untuk menyelaraskan ID yang masih diterima oleh pelayan. Kehilangan setiap pengesah menggunakan pemulihan yang dikawal risiko seperti kata laluan ditambah semakan risiko, e-mel yang disahkan, atau semakan sokongan. Batalkan sesi lama dan kemudian wajibkan pendaftaran Passkey baharu.
Langkah 7: Sahkan dan kembangkan
Uji pelayar yang berbeza, pengesah platform, kelayakan yang diselaraskan, kunci keselamatan, pembatalan, tamat masa, origin yang salah, cabaran yang tamat tempoh dan berulang, anomali pembilang, serta kelayakan lama selepas pemulihan. Kesan keupayaan dan terima dasar daripada pelayan dan bukannya meneka daripada rentetan user-agent. Sambungan baharu harus bersifat pilihan dengan UI sandaran, dan sambungan yang tidak diketahui tidak boleh mengubah pengesahan teras pelayan.
Contoh jawapan berkualiti tinggi
Saya akan menganggap Passkey sebagai aliran pengesahan kunci awam yang dipacu oleh pelayan. Apabila pengguna memulakan pendaftaran, frontend meminta cabaran satu kali dan pilihan publicKey daripada pelayan, kemudian memanggil WebAuthn melalui HTTPS. Pelayan sahaja yang mengesahkan cabaran, origin, RP ID, tandatangan, algoritma, dan sebarang perakuan yang diperlukan, kemudian menyimpan ID kelayakan, kunci awam, pembilang, dan ikatan akaun. Kunci peribadi kekal dalam pengesah.
Log masuk bermula dengan satu lagi cabaran pelayan. Frontend memanggil navigator.credentials.get(), menyerahkan penegasan, dan pelayan mengesahkan tandatangan, cabaran, origin, RP ID, dan pembilangnya sebelum mencipta sesi. Jika pengantaraan bersyarat disokong, saya menawarkan pengisian automatik Passkey selepas interaksi medan nama pengguna, tetapi ia mengikut pengesahan pelayan yang sama.
Frontend membezakan keadaan tidak disokong, dibatalkan, tamat masa, dan ditolak, serta membatalkan panggilan yang belum selesai apabila halaman ditinggalkan. Tetapan akaun menyenaraikan dan memadam kelayakan; selepas pemadaman, isyarat WebAuthn menghalang pelayar daripada mencadangkan kelayakan yang tidak diketahui. Kehilangan peranti memerlukan pemulihan yang dikawal risiko, membatalkan sesi lama, memberitahu pengguna, dan mendaftarkan kelayakan pengganti. Ujian merangkumi pengesah rentas platform, origin yang salah, cabaran yang tamat tempoh atau berulang, anomali pembilang, sandaran pelayar, dan kelayakan lama selepas pemulihan supaya perubahan UX tidak sekali-kali melemahkan pengesahan protokol.
Kesilapan lazim
- Kesilapan: Menjana cabaran dalam frontend atau meletakkannya dalam pemalar halaman. → Mengapa ia gagal: Penyerang boleh memainkan semula (replay) penegasan lama dan pelayan tidak dapat memastikan kesegaran (freshness) aliran. → Pembetulan: Janakannya pada pelayan, simpannya seketika, gunakannya sekali sahaja, dan ikat ia pada akaun serta tujuan.
- Kesilapan: Melog masuk pengguna apabila Promise selesai. → Mengapa ia gagal: Objek pelayar bukan bukti bahawa pelayan telah mengesahkan origin, RP ID, dan tandatangan. → Pembetulan: Lengkapkan pengesahan penegasan pada pelayan dan biarkan frontend memaparkan hasil yang berstruktur.
- Kesilapan: Mengesan sokongan dengan rentetan user-agent. → Mengapa ia gagal: Versi pelayar, pengesah platform, dan dasar kebenaran berbeza-beza. → Pembetulan: Gunakan API keupayaan dan dasar pelayan, kemudian sediakan laluan kata laluan atau kunci keselamatan yang jelas.
- Kesilapan: Memadam kelayakan pangkalan data tanpa menyelaraskan keadaan peranti. → Mengapa ia gagal: Pengesah masih menganggap kelayakan itu wujud dan terus menawarkan pilihan yang tidak boleh digunakan. → Pembetulan: Panggil API isyarat WebAuthn dalam keadaan disahkan yang sesuai dan sediakan laluan pendaftaran semula.
Soalan susulan dan jawapan
Susulan 1: Mengapakah RP ID tidak boleh menjadi mana-mana domain API?
RP ID mestilah domain berkaitan untuk origin semasa dan disemak oleh kedua-dua pelayar dan pelayan. Nilai yang tidak berkaitan menyebabkan penciptaan gagal atau meluaskan skop kepercayaan. Bagi domain berbilang penyewa (multi-tenant), konfigurasikan setiap domain yang dipercayai secara eksplisit; jangan sesekali menerima rentetan sewenang-wenangnya yang disediakan oleh klien.
Susulan 2: Pengguna mendaftar pada telefon, tetapi desktop tidak mempunyai kunci. Apa perlu buat sekarang?
Jika kelayakan boleh ditemui yang diselaraskan dibenarkan, pelayar dan pengurus kelayakan boleh menyediakan Passkey akaun yang sama merentas peranti. Jika tidak, tawarkan aliran QR rentas peranti atau kunci keselamatan. Frontend harus menyatakan bahawa peranti tidak boleh menggunakan kelayakan tersebut dan menyediakan tindakan; pelayan masih mengesahkan peraturan cabaran dan penegasan yang sama, termasuk origin.
Susulan 3: Patutkah pengunduran pembilang (counter rollback) mengunci akaun dengan serta-merta?
Mula-mula bezakan kelayakan platform yang diselaraskan, pemulihan sandaran, dan risiko pengklonan sebenar. Anggap anomali sebagai isyarat risiko yang mungkin memerlukan pengesahan tambahan dan maklumkan pengguna, bukannya mengunci secara kekal tanpa konteks. Tindakan bernilai tinggi boleh memerlukan kelayakan berdaftar yang lain atau semakan sokongan, dengan keputusan direkodkan untuk penalaan dasar.
Susulan 4: Adakah pemulihan melemahkan keselamatan Passkey?
Ya, jika pemulihan hanya bergantung pada pautan e-mel yang berpotensi dikompromi. Gunakan semakan risiko bertingkat, pembatalan sesi, tempoh bertenang (cooling period), pemberitahuan, dan tindakan berisiko tinggi yang ditangguhkan. Selepas pemulihan, daftarkan kelayakan baharu dan alih keluar yang lama. Terangkan kompromi (trade-off) antara ketersediaan dan pengambilalihan akaun dan bukannya berjanji bahawa pengguna tidak akan kehilangan akses.