Gesaan dan konteks
Soalan ini menguji sama ada jurutera frontend boleh menyepadukan sambungan WebAuthn ke dalam aliran penyulitan hujung-ke-hujung yang sebenar. PRF boleh menyediakan output pseudorawak yang terikat dengan kelayakan untuk menerbitkan bahan kunci pihak klien; ia bukan tandatangan log masuk dan tidak menyelesaikan isu penggunaan pelbagai peranti, sandaran, pemadaman atau keserasian pelayar. Jawapan yang kukuh merangkumi API pelayar, sempadan kriptografi, pengalaman pengguna dan risiko pemulihan.
Perkara yang dinilai oleh penemu bual
- Sama ada anda membezakan pengesahan passkey daripada penggunaan bahan kunci PRF.
- Sama ada anda mengasingkan sokongan sambungan, pengesahan pengguna, salt, penerbitan dan storan pelayan.
- Sama ada anda mengendalikan pendaftaran peranti, pemadaman kelayakan, penyegerakan dan kehilangan yang tidak boleh dipulihkan.
- Sama ada anda menentukan sandaran, keadaan ralat dan sempadan yang mengekalkan bahan kunci di luar pelayan.
Soalan penjelasan untuk ditanya terlebih dahulu
Jelaskan model ancaman: adakah pelayan tidak dipercayai, adakah rantaian bekalan klien dalam skop, dan adakah penyegerakan merentas peranti diperlukan? Adakah data disulitkan secara keseluruhan atau mengikut medan, dan bolehkah pengguna menerima kehilangan kekal selepas kehilangan kelayakan? Adakah pelayar sasaran dan WebView dikawal, dan bolehkah pengguna mendaftarkan beberapa passkey? Ciphertext, salt, ID kelayakan dan versi manakah yang mesti disimpan oleh pelayan?
Rangka kerja jawapan 30 saat
Saya akan menganggap PRF sebagai sumber bahan kunci pihak klien, bukan menggunakan penegasan log masuk sebagai kunci penyulitan. Semasa pendaftaran, cipta atau pilih kelayakan yang menyokong PRF dan jana salt yang tidak dapat diramalkan bagi setiap tujuan. Semasa buka kunci, lakukan penegasan dengan input PRF, terbitkan wrapping key dengan KDF standard dalam pelayar, dan nyahbalut data key. Pelayan menyimpan kunci awam, salt, ciphertext dan versi, tidak sekali-kali menyimpan output PRF. Saya akan menyemak hasil sambungan sebenar dan pengesahan pengguna, menyediakan pemulihan pelbagai kelayakan atau amaran kehilangan yang jelas, dan enggan mendakwa penyulitan hujung-ke-hujung apabila PRF tidak tersedia. Saya akan memperluas sokongan hanya selepas mengukur kegagalan, pemulihan dan keserasian.
Huraian mendalam langkah demi langkah
1. Asingkan pengesahan daripada kunci penyulitan
Log masuk WebAuthn mengembalikan tandatangan ke atas cabaran untuk membuktikan pemilikan kelayakan. Sambungan PRF menghasilkan output pseudorawak yang dikaitkan dengan kelayakan daripada sesuatu input. Tandatangan, ID kelayakan atau JSON sambungan klien tidak boleh digunakan secara terus sebagai kunci AES. Reka bentuk ini memerlukan data key yang bebas serta hubungan penerbitan dan pembalutan yang jelas.
2. Reka bentuk pendaftaran dan salt
Minta sambungan PRF semasa pendaftaran dan wajibkan pengesahan pengguna. Jana salt rawak bagi setiap domain penyulitan atau versi kunci, kemudian simpan salt, ID kelayakan dan versi algoritma sebagai metadata awam. Salt bukanlah rahsia, tetapi tujuan mestilah diasingkan; mengubah tujuan atau memutar kunci memerlukan salt baharu. Semak output sambungan klien yang dikembalikan dan bukannya membuat kesimpulan tentang sokongan daripada permintaan sahaja.
3. Reka bentuk buka kunci dan penerbitan
Dapatkan salt dan metadata ciphertext daripada pelayan, kemudian lakukan penegasan dengan input PRF. Sahkan struktur dan panjang sambungan yang dikembalikan dalam pelayar, terbitkan wrapping key dengan KDF standard, nyahbalut data key yang dijana secara rawak, dan nyahsulit kandungan. Simpan output PRF dan kunci perantaraan dalam memori hanya apabila diperlukan; jangan sekali-kali memasukkannya ke dalam log atau telemetri.
4. Kendalikan pengesanan keupayaan dan keserasian
Gunakan semakan keupayaan yang didokumenkan dan getClientExtensionResults() untuk memeriksa hasil sebenar. Bezakan antara sambungan yang tidak disokong, pembatalan pengguna, kelayakan yang belum dimulakan dan kegagalan rangkaian. Status pelaksanaan W3C masih memerlukan pengesahan merentas pelayar sasaran, sistem pengendalian dan WebView; kejayaan pada satu pelayar bukanlah jaminan untuk seluruh platform. Rekodkan matriks keserasian dan versi minimum dalam dasar pelancaran.
5. Reka bentuk pelbagai peranti dan pemulihan
Daftarkan kelayakan berasingan bagi setiap peranti dan simpan salinan berbalut berasingan bagi data key yang sama untuk setiap satu. Peranti baharu memerlukan peranti yang telah dibuka kuncinya, recovery key atau jemputan terkawal untuk membalut semula data key; log masuk pelayan sahaja tidak boleh menyahsulitkannya. Jika setiap kelayakan dipadamkan dan tiada bahan pemulihan wujud, nyatakan dengan jelas bahawa data tidak boleh dipulihkan dan dapatkan pengesahan sebelum mendayakan ciri tersebut.
6. Rancang sandaran dan migrasi
Apabila PRF tidak tersedia, kekalkan mod penyulitan yang boleh dibaca oleh pelayan, bimbing pengguna ke pelayar yang disokong, atau sekat mod hujung-ke-hujung, bergantung pada model ancaman. Labelkan sandaran secara eksplisit; jangan campurkan tahap keselamatan dalam satu UI. Letakkan versi pada algoritma, salt dan format ciphertext supaya migrasi masa hadapan dan pembatalan kelayakan lama kekal boleh dilaksanakan.
Contoh jawapan berkualiti tinggi
Saya akan menggunakan WebAuthn PRF sebagai bahan kunci pihak klien, dan tidak sekali-kali menganggap tandatangan log masuk atau ID kelayakan sebagai kunci penyulitan. Semasa pendaftaran, minta PRF, wajibkan pengesahan pengguna, jana salt rawak bagi setiap domain penyulitan, dan simpan ID kelayakan, salt serta versi algoritma. Semasa membuka kunci, dapatkan metadata, lakukan penegasan dengan input PRF, terbitkan wrapping key dengan KDF standard dalam pelayar, nyahbalut data key yang dijana secara rawak dan nyahsulit. Pelayan menyimpan kunci awam, ciphertext dan metadata awam; output PRF, kunci perantaraan dan teks biasa kekal pada pihak klien. Saya akan memeriksa getClientExtensionResults() untuk membezakan keadaan tidak disokong, belum dimulakan, dibatalkan dan ralat rangkaian. Setiap peranti mendapat kelayakan sendiri dan salinan data key yang dibalut; penambahan peranti memerlukan peranti yang tidak berkunci atau bahan pemulihan, dan kehilangan semua kelayakan secara eksplisit tidak boleh dipulihkan. Jika PRF tidak tersedia, saya akan memaparkan sandaran yang jelas atau menyekat pengaktifan, kemudian berkembang berdasarkan matriks pelayar, kadar kegagalan dan kejayaan pemulihan.
Kesilapan lazim
- Menggunakan tandatangan WebAuthn, ID kelayakan atau JSON sambungan klien secara terus sebagai kunci simetri.
- Hanya menyemak bahawa permintaan mengandungi parameter PRF dan bukannya menyemak output sebenar serta pemulaan.
- Menganggap salt sebagai rahsia atau menggunakan semula satu salt merentas pelbagai tujuan.
- Menghantar output PRF ke pelayan atau merekodkan bahan kunci dalam log, penjejakan atau analitik.
- Hanya mereka bentuk laluan lancar (happy path) bagi peranti tunggal tanpa pendaftaran, pemadaman dan pemulihan.
- Beralih secara senyap kepada mod yang lebih lemah sambil masih melabelkannya sebagai penyulitan hujung-ke-hujung.
Soalan susulan dan jawapan
Bolehkah output PRF digunakan secara terus sebagai kunci AES-GCM?
Gunakan KDF standard dan pengasingan domain terlebih dahulu, kemudian terbitkan wrapping key dengan panjang tetap. Jangan dedahkan output protokol kepada beberapa tujuan penyulitan. Jana data key rawak dan balutnya; jangan jadikan setiap kunci ciphertext sebagai fungsi langsung daripada kelayakan.
Bolehkah pelayan membuka kunci pengguna pada peranti lain selepas log masuk?
Pelayan boleh menyediakan salt, ciphertext dan metadata kelayakan, tetapi tidak boleh membina semula output PRF daripada log masuk. Peranti yang telah dibuka kuncinya, recovery key atau aliran perkongsian kunci yang direka bentuk secara eksplisit mesti membalut data key untuk peranti baharu tersebut.
Bagaimanakah anda mengetahui pelayar benar-benar menyokong PRF?
Isytiharkan sambungan, baca output sambungan klien daripada penegasan, dan semak medan yang dijangkakan, panjang serta keadaan ralat. Kekalkan matriks empirikal untuk pelayar sasaran, sistem pengendalian dan WebView. API keupayaan hanya menyatakan bahawa sambungan boleh diminta; ia tidak menggantikan upacara interaksi sebenar.
Adakah penyulitan hujung-ke-hujung masih selamat jika skrip yang dihantar oleh pelayan disuntik kod berniat jahat?
PRF tidak menyelesaikan masalah pengusikan aktif pada skrip frontend. Anda juga memerlukan dasar keselamatan kandungan (CSP), integriti kebergantungan dan keluaran, pengasingan operasi sensitif, serta pengauditan. Nyatakan dengan jelas bahawa "pelayan tidak boleh membaca ciphertext sejarah" dan "runtime klien dipercayai" adalah dua andaian yang berbeza.