Konteks dan arahan
Pertanyaan ini menguji apakah seorang insinyur frontend dapat mengintegrasikan ekstensi WebAuthn ke dalam alur enkripsi end-to-end yang sebenarnya. PRF dapat menyediakan output pseudorandom yang terikat pada kredensial untuk menurunkan materi kunci sisi klien; ini bukan tanda tangan login dan tidak menyelesaikan masalah penggunaan multi-perangkat, pencadangan, penghapusan, atau kompatibilitas peramban. Jawaban yang kuat mencakup API peramban, batas kriptografi, pengalaman pengguna, dan risiko pemulihan.
Apa yang dievaluasi oleh pewawancara
- Apakah Anda membedakan autentikasi passkey dari penggunaan materi kunci PRF.
- Apakah Anda memisahkan dukungan ekstensi, verifikasi pengguna, salt, derivasi, dan penyimpanan server.
- Apakah Anda menangani pendaftaran perangkat, penghapusan kredensial, sinkronisasi, dan kehilangan yang tidak dapat dipulihkan.
- Apakah Anda mendefinisikan fallback, status kesalahan, dan batasan yang menjaga materi kunci tetap berada di luar server.
Pertanyaan klarifikasi untuk diajukan terlebih dahulu
Perjelas model ancaman: apakah server tidak tepercaya, apakah rantai pasokan klien termasuk dalam cakupan, dan apakah sinkronisasi lintas perangkat diperlukan? Apakah data dienkripsi secara keseluruhan atau per bidang, dan dapatkah pengguna menerima kehilangan permanen setelah kehilangan kredensial? Apakah peramban target dan WebView terkontrol, dan bolehkah pengguna mendaftarkan beberapa passkey? Ciphertext, salt, ID kredensial, dan versi mana yang harus disimpan oleh server?
Kerangka kerja jawaban 30 detik
Saya akan memperlakukan PRF sebagai sumber materi kunci sisi klien, bukan menggunakan asersi login sebagai kunci enkripsi. Selama pendaftaran, buat atau pilih kredensial yang mendukung PRF dan hasilkan salt yang tidak dapat diprediksi untuk setiap tujuan. Selama pembukaan kunci, lakukan asersi dengan input PRF, turunkan wrapping key menggunakan KDF standar di peramban, dan buka pembungkus data key. Server menyimpan kunci publik, salt, ciphertext, dan versi, tidak pernah menyimpan output PRF. Saya akan memeriksa hasil ekstensi aktual dan verifikasi pengguna, menyiapkan pemulihan multi-kredensial atau peringatan kehilangan yang eksplisit, dan menolak untuk mengklaim enkripsi end-to-end ketika PRF tidak tersedia. Saya akan memperluas dukungan hanya setelah mengukur kegagalan, pemulihan, dan kompatibilitas.
Pembahasan mendalam langkah demi langkah
1. Memisahkan autentikasi dari kunci enkripsi
Login WebAuthn mengembalikan tanda tangan atas sebuah challenge untuk membuktikan kepemilikan kredensial. Ekstensi PRF menghasilkan output pseudorandom yang terkait dengan kredensial dari sebuah input. Tanda tangan, ID kredensial, atau JSON ekstensi klien tidak boleh digunakan secara langsung sebagai kunci AES. Desain tersebut membutuhkan data key yang independen serta hubungan derivasi dan pembungkusan yang eksplisit.
2. Merancang pendaftaran dan salt
Minta ekstensi PRF selama pendaftaran dan wajibkan verifikasi pengguna. Hasilkan salt acak per domain enkripsi atau versi kunci, lalu simpan salt, ID kredensial, dan versi algoritma sebagai metadata publik. Salt bukanlah rahasia, tetapi tujuannya harus dipisahkan; mengubah tujuan atau merotasi kunci memerlukan salt baru. Periksa output ekstensi klien yang dikembalikan daripada menyimpulkan dukungan hanya dari permintaan.
3. Merancang pembukaan kunci dan derivasi
Ambil salt dan metadata ciphertext dari server, lalu lakukan asersi dengan input PRF. Validasi struktur dan panjang ekstensi yang dikembalikan di peramban, turunkan wrapping key dengan KDF standar, buka bungkus data key yang dibuat secara acak, dan dekripsi kontennya. Simpan output PRF dan kunci perantara di memori hanya selama diperlukan; jangan pernah memasukkannya ke dalam log atau telemetri.
4. Menangani deteksi kemampuan dan kompatibilitas
Gunakan pemeriksaan kemampuan yang terdokumentasi dan getClientExtensionResults() untuk memeriksa hasil aktual. Bedakan antara ekstensi yang tidak didukung, pembatalan oleh pengguna, kredensial yang belum diinisialisasi, dan kegagalan jaringan. Status implementasi W3C masih memerlukan verifikasi di berbagai peramban target, sistem operasi, dan WebView; keberhasilan pada satu peramban bukanlah jaminan platform. Catat matriks kompatibilitas dan versi minimum dalam kebijakan peluncuran.
5. Merancang multi-perangkat dan pemulihan
Daftarkan kredensial terpisah per perangkat dan simpan salinan terbungkus terpisah dari data key yang sama untuk masing-masing perangkat. Perangkat baru memerlukan perangkat yang sudah tidak terkunci, recovery key, atau undangan terkontrol untuk membungkus ulang data key; login server saja tidak boleh dapat mendekripsinya. Jika setiap kredensial dihapus dan tidak ada materi pemulihan yang tersisa, nyatakan dengan jelas bahwa data tidak dapat dipulihkan dan mintalah konfirmasi sebelum mengaktifkan fitur tersebut.
6. Merencanakan fallback dan migrasi
Ketika PRF tidak tersedia, pertahankan mode enkripsi yang dapat dibaca server, arahkan pengguna ke peramban yang didukung, atau blokir mode end-to-end, tergantung pada model ancaman. Beri label fallback secara eksplisit; jangan mencampur tingkat keamanan dalam satu antarmuka pengguna. Berikan versi pada algoritma, salt, dan format ciphertext sehingga migrasi di masa mendatang dan pencabutan kredensial lama tetap memungkinkan.
Contoh jawaban berkualitas tinggi
Saya akan menggunakan WebAuthn PRF sebagai materi kunci sisi klien, dan tidak pernah memperlakukan tanda tangan login atau ID kredensial sebagai kunci enkripsi. Saat pendaftaran, minta PRF, wajibkan verifikasi pengguna, buat salt acak per domain enkripsi, dan simpan ID kredensial, salt, serta versi algoritma. Saat membuka kunci, ambil metadata, lakukan asersi dengan input PRF, turunkan wrapping key dengan KDF standar di peramban, buka bungkus data key yang dihasilkan secara acak, dan dekripsi. Server menyimpan kunci publik, ciphertext, dan metadata publik; output PRF, kunci perantara, dan teks biasa tetap berada di sisi klien. Saya akan memeriksa getClientExtensionResults() untuk membedakan status tidak didukung, belum diinisialisasi, dibatalkan, dan kesalahan jaringan. Setiap perangkat mendapatkan kredensialnya sendiri dan salinan data key yang dibungkus; menambahkan perangkat memerlukan perangkat yang tidak terkunci atau materi pemulihan, dan kehilangan semua kredensial secara eksplisit tidak dapat dipulihkan. Jika PRF tidak tersedia, saya akan menampilkan fallback eksplisit atau memblokir aktivasi, kemudian memperluas berdasarkan matriks peramban, tingkat kegagalan, dan keberhasilan pemulihan.
Kesalahan umum
- Menggunakan tanda tangan WebAuthn, ID kredensial, atau JSON ekstensi klien secara langsung sebagai kunci simetris.
- Hanya memeriksa bahwa permintaan berisi parameter PRF alih-alih memeriksa output aktual dan inisialisasinya.
- Memperlakukan salt sebagai rahasia atau menggunakan kembali satu salt untuk berbagai tujuan.
- Mengirim output PRF ke server atau mencatat materi kunci dalam log, tracing, atau analitik.
- Hanya merancang skenario ideal (happy path) untuk satu perangkat tanpa memikirkan pendaftaran, penghapusan, dan pemulihan.
- Beralih secara diam-diam ke mode yang lebih lemah sementara tetap melabelinya sebagai enkripsi end-to-end.
Pertanyaan lanjutan dan jawabannya
Bisakah output PRF digunakan langsung sebagai kunci AES-GCM?
Gunakan KDF standar dan pemisahan domain terlebih dahulu, kemudian turunkan wrapping key dengan panjang tetap. Jangan mengekspos output protokol ke beberapa tujuan enkripsi. Hasilkan data key acak dan bungkus kunci tersebut; jangan membuat setiap kunci ciphertext menjadi fungsi langsung dari kredensial.
Bisakah server membuka kunci pengguna di perangkat lain setelah login?
Server dapat menyediakan salt, ciphertext, dan metadata kredensial, tetapi tidak dapat merekonstruksi output PRF dari sebuah login. Perangkat yang tidak terkunci, recovery key, atau alur berbagi kunci yang dirancang secara eksplisit harus membungkus data key untuk perangkat baru tersebut.
Bagaimana Anda tahu peramban benar-benar mendukung PRF?
Deklarasikan ekstensi, baca output ekstensi klien dari asersi, dan periksa bidang yang diharapkan, panjang, serta status kesalahan. Pertahankan matriks empiris untuk peramban target, sistem operasi, dan WebView. API kemampuan menyatakan bahwa suatu ekstensi dapat diminta; itu tidak menggantikan proses interaksi (ceremony) yang sebenarnya.
Apakah enkripsi end-to-end tetap aman jika skrip yang dikirimkan server disuntikkan kode berbahaya?
PRF tidak menyelesaikan masalah manipulasi aktif pada skrip frontend. Anda juga memerlukan content security policy (CSP), integritas dependensi dan rilis, isolasi operasi sensitif, serta audit. Nyatakan dengan jelas bahwa "server tidak dapat membaca ciphertext historis" dan "runtime klien tepercaya" adalah dua asumsi yang berbeda.