Gesaan dan konteks yang sesuai
SaaS ini telah pun menyokong kata laluan dan sedang menambah passkey. Pengguna boleh log masuk daripada telefon, komputer riba, atau kunci keselamatan perkakasan; sesetengah kelayakan mungkin disegerakkan melalui platform, manakala tindakan perusahaan berisiko tinggi memerlukan pengesahan pengguna yang lebih kukuh. Reka bentuk pendaftaran, pengesahan, pemulihan, penghijrahan, dan kebolehcerapan.
Skopnya ialah WebAuthn dan sempadan pengesahan pelayan. Passkey tidak menyelesaikan pengurusan sesi, pemulihan akaun, pembatalan peranti, atau kebenaran perniagaan secara automatik.
Perkara yang dinilai oleh penemu duga
Penemu duga memeriksa sama ada anda memahami bahawa pelayar dan pengesah memegang kunci peribadi manakala pelayan menyimpan kunci awam; setiap upacara menggunakan cabaran rawak sekali guna; dan pengesah memeriksa cabaran, RP ID, origin, tandatangan, serta bendera kehadiran pengguna atau pengesahan pengguna yang diperlukan.
Jawapan yang kukuh juga memisahkan antara "kalis pancingan data" daripada "tidak pernah hilang." Kelayakan boleh segerak meningkatkan ketersediaan tetapi mungkin tidak memenuhi keperluan ketidakboleh-eksportan yang paling ketat. Jika pemulihan memintas bukti yang setara, keseluruhan reka bentuk hanya sekuat laluan paling lemahnya.
Penjelasan untuk ditanya terlebih dahulu
- Tindakan manakah yang hanya memerlukan log masuk, dan manakah yang memerlukan UV atau kelayakan terikat peranti?
- Adakah RP ID merangkumi berbilang subdomain, dan adakah WebAuthn akan berjalan dalam iframe silang-origin?
- Bolehkah perusahaan melarang kelayakan boleh segerak atau mewajibkan kunci perkakasan?
- Apakah faktor sedia ada yang kekal untuk pemulihan, dan bolehkah pengendali menyemaknya?
- Apakah garis masa penghijrahan dan pembatalan untuk kata laluan, TOTP, dan passkey?
Rangka kerja jawapan 30 saat
"Pelayan mencipta cabaran sekali guna untuk setiap pendaftaran atau pengesahan dan mengikatnya pada sesi. Selepas upacara tersebut, ia mengesahkan RP ID, origin, cabaran, tandatangan, dan bendera UP/UV yang diperlukan. Pendaftaran menyimpan kunci awam, ID kelayakan, pembilang, dan metadata dasar, bukan kunci peribadi. Saya akan menyusun kelayakan boleh segerak mengikut tahap risiko dan mewajibkan UV atau pengikatan peranti untuk tindakan sensitif. Pemulihan menggunakan faktor kukuh sedia ada, aliran sekali guna jangka pendek, dan semakan risiko; SMS bukan pintu belakang tanpa syarat."
Jawapan mendalam langkah demi langkah
Langkah 1: Tentukan data pendaftaran dan pengesahan
Sebelum pendaftaran, pelayan mencipta cabaran yang tidak dapat diramal, jangka pendek, sekali guna dan menyimpannya dalam sesi atau storan sekali guna. Klien memanggil navigator.credentials.create(); pengesah mencipta pasangan kunci dan mengembalikan kelayakan kunci awam.
Simpan ID kelayakan, kunci awam, akaun, RP ID, pembilang tandatangan, kelayakan sandaran, dan keadaan sandaran mengikut keperluan. Kunci peribadi kekal dalam pengesah atau pengurus kelayakan platform.
Langkah 2: Laksanakan pemeriksaan pengesahan yang ketat
Untuk log masuk, pelayan mencipta cabaran baharu dan publicKeyCredentialRequestOptions; klien memanggil navigator.credentials.get(). Sahkan:
const valid = await verifyAuthenticationResponse({
response,
expectedChallenge: session.challenge,
expectedOrigin: "https://app.example.com",
expectedRPID: "app.example.com",
requireUserVerification: true
});Gunakan (hanguskan) cabaran dengan serta-merta selepas pengesahan berjaya. Tolak respons yang dimainkan semula (replayed), tamat tempoh, atau silang-sesi, kemudian sahkan tandatangan dengan kunci awam yang disimpan. Kendalikan juga pembatalan, pelayar yang tidak disokong, dan pengesah yang tidak tersedia buat sementara waktu.
Langkah 3: Fahami RP ID, origin, dan risiko silang-origin
RP ID mengenal pasti pihak yang bergantung (relying party) untuk sesuatu kelayakan; sesuatu kelayakan tidak boleh disahkan pada RP ID yang berbeza. Pelayan juga mesti memeriksa origin pemanggil dan bukannya membandingkan domain boleh daftar semata-mata. Iframe silang-origin atau Related Origin Request memerlukan semakan eksplisit sama ada pengguna mengetahui siapa yang meminta upacara tersebut dan ujian keserasian yang berasingan.
Logo syarikat bukanlah bukti origin. Origin, RP ID, cabaran, dan tandatangan mesti disahkan bersama merentas konteks pelayar/pengesah dan pelayan.
Langkah 4: Buat pertimbangan tentang UP, UV, dan status penyegerakan mengikut risiko
UP bermaksud pengguna berinteraksi dengan pengesah; UV bermaksud pengesah mengesahkan pengguna secara tempatan. Log masuk biasa boleh memilih dasar mengikut risiko, manakala pemindahan, eksport kunci, dan tindakan pentadbir harus mewajibkan UV dan meminta pelayan memeriksa bendera yang dikembalikan.
Kelayakan boleh segerak meningkatkan ketersediaan merentas peranti, tetapi NIST menyatakan bahawa penyegerakan melibatkan keboleheksportan kunci. Sama ada ia memenuhi tahap jaminan bergantung pada dasar pelaksanaan. Rekod kelayakan dan status sandaran; jangan sebut "boleh segerak" sebagai "telah disegerakkan" atau "terikat peranti."
Langkah 5: Reka bentuk pemulihan, penghijrahan, dan pembatalan
Apabila pengguna kehilangan peranti, utamakan passkey berdaftar yang lain, kunci pemulihan perusahaan, atau aliran identiti kukuh yang disemak. Token pemulihan mestilah berjangka pendek, sekali guna, terikat sesi, dan boleh dibatalkan. Selepas pemulihan, maklumkan kepada pengguna, putarkan sesi, dan benarkan pengguna menyemak serta mengalih keluar kelayakan lama.
Semasa penghijrahan kata laluan, kekalkan tempoh peralihan yang terkawal dan kurangkan kebergantungan kata laluan selepas passkey dicipta; jangan padamkan setiap faktor lama secara senyap dalam permintaan yang sama. Setiap kelayakan memerlukan status pembatalan bebas, manakala pembilang anomali, peranti berisiko, dan peristiwa pemulihan dimasukkan ke dalam aliran audit.
Contoh jawapan berkualiti tinggi
"Saya akan mulakan dengan menyusun matlamat keselamatan mengikut tahap. Pelayan mencipta cabaran sekali guna untuk setiap pendaftaran dan pengesahan serta menyimpannya dalam sesi jangka pendek. Ia mengesahkan cabaran, RP ID, origin, tandatangan, dan bendera UP/UV yang diperlukan oleh tindakan tersebut, kemudian menghanguskan cabaran. Pangkalan data menyimpan kunci awam, ID kelayakan, pembilang, akaun, dan status sandaran; kunci peribadi tidak pernah meninggalkan pengesah.
Saya tidak akan mendayakan penggunaan iframe silang-origin secara lalai. Jika diperlukan, saya akan meletakkan origin pemanggil, origin peringkat teratas, dan RP ID dalam matriks ujian. Log masuk biasa boleh menerima kelayakan boleh segerak yang mematuhi dasar, manakala tindakan sensitif memerlukan UV atau pengikatan peranti. Pemulihan mengutamakan passkey kukuh yang lain atau kunci pemulihan perusahaan, dengan tamat tempoh sekali guna, kawalan risiko, dan pemberitahuan. SMS boleh menjadi sandaran yang diterima secara eksplisit, bukan cara kekal untuk memintas pengesahan kukuh. Telemetri pengeluaran memantau mainan semula cabaran, ketidakpadanan origin, ketiadaan UV, kejayaan pemulihan, dan pembatalan anomali."
Kesilapan lazim
- Hanya mengesahkan tandatangan → tandatangan yang sah tidak membuktikan cabaran, RP ID, atau origin yang betul → periksa setiap medan dan hanguskan cabaran.
- Menganggap UP sebagai UV → menyentuh pengesah bukan pengesahan pengguna tempatan → wajibkan dan periksa UV untuk tindakan berisiko tinggi.
- Memanggil passkey boleh segerak sebagai terikat peranti → kelayakan penyegerakan dan penyegerakan sebenar adalah fakta yang berbeza → rekod bendera sandaran dan buat keputusan mengikut tahap jaminan.
- Memulihkan dengan pautan SMS serta-merta → laluan paling lemah boleh mengambil alih akaun → gunakan faktor kukuh sedia ada, token jangka pendek, semakan risiko, dan pemberitahuan.
- Hanya memeriksa domain boleh daftar → origin merangkumi skema, hos, dan port → bandingkan origin penuh yang dinormalkan.
- Menggunakan semula cabaran → penegasan yang dipintas boleh dimainkan semula → jadikan cabaran rawak, jangka pendek, sekali guna, dan terikat sesi.
Soalan susulan dan jawapan
Soalan susulan 1: Mengapakah passkey kalis pancingan data?
Pengesah memilih kelayakan berdasarkan origin dan RP ID serta menandatangani cabaran pelayan dengan konteksnya. Laman pancingan data tidak boleh mendapatkan bukti yang sah untuk perkhidmatan sebenar daripada pengesah. Pelayan masih mesti mengesahkan origin, RP ID, dan cabaran.
Soalan susulan 2: Mengapa tidak menyimpan cabaran hanya pada klien?
Pelayan mesti mengetahui nilai rawak yang dikeluarkannya untuk menghubungkan respons dengan niat log masuk semasa dan menolak mainan semula. Nilai yang dijana klien atau disimpan secara berasingan tidak membuktikan bahawa pelayan yang memulakan upacara ini.
Soalan susulan 3: Adakah kelayakan boleh segerak sememangnya tidak selamat?
Elakkan tuntutan binari. Penyegerakan meningkatkan pemulihan dan kebolehgunaan merentas peranti, manakala keboleheksportan, dasar penyedia, dan keperluan jaminan organisasi berbeza-beza. Pelayan harus memeriksa bendera sandaran mengikut tahap risiko dan mewajibkan faktor yang lebih kukuh untuk tindakan sensitif.
Soalan susulan 4: Bagaimana jika pengguna kehilangan semua peranti?
Layan pemulihan sebagai pengesahan berisiko tinggi: gunakan kunci pemulihan perusahaan, faktor kukuh lain yang disemak, atau semakan pengendali, dengan skop dan masa yang terhad, pemberitahuan, serta pembatalan kelayakan yang tidak diketahui. Kemudahan tidak boleh merendahkan tahap jaminan log masuk secara kekal.