Pertanyaan dan latar belakang
Aplikasi mengenkripsi data lokal di browser dan memerlukan kunci yang tetap ada di seluruh sesi. Rancangan harus mengurangi paparan kunci, namun harus menyatakan batasannya: kode yang berjalan di origin yang sama masih dapat memanggil operasi yang diizinkan dan pengguna dapat kehilangan kemampuan pemulihan data.
Hal yang diuji oleh pewawancara
- Pemahaman tentang secure context, kemampuan ekstraksi (extractability) CryptoKey, dan penggunaan kunci (key usages).
- Pemisahan penyimpanan data terenkripsi dari pemulihan kunci dan pemodelan ancaman (threat modeling).
- Menjelaskan mengapa kriptografi browser tidak membuat XSS menjadi tidak berbahaya.
Pertanyaan klarifikasi sebelum menjawab
- Apakah ancamannya berupa rekaman penyimpanan yang dicuri, penyerang pasif, atau skrip aktif dari origin yang sama?
- Apakah data harus bertahan setelah logout, kehilangan perangkat, reset kata sandi, dan penghapusan profil browser?
- Bisakah passphrase yang diberikan pengguna atau kredensial WebAuthn membuka wrapping key?
- Algoritma, key usages, dukungan browser, dan jalur migrasi apa saja yang diperlukan?
Kerangka jawaban 30 detik
Saya akan mewajibkan HTTPS, membuat atau mengimpor CryptoKey dengan extractable diatur ke false dan hanya dengan usages yang diperlukan, lalu menyimpan handle kunci di IndexedDB daripada mengekspor byte kunci mentah. Teks tersandi (ciphertext), nonce, parameter algoritma, dan versi tetap terpisah dari kunci. Saya akan menggabungkan ini dengan CSP, kontrol dependensi yang ketat, dan rencana pemulihan, sambil menyatakan bahwa skrip aktif dari origin yang sama masih dapat memanggil API enkripsi atau membaca plaintext saat aplikasi terbuka.
Pembahasan mendalam langkah demi langkah
1. Tentukan model ancaman
Non-extractability membatasi ekspor yang tidak disengaja dan banyak jalur pencurian penyimpanan. Hal ini tidak menghentikan penyerang yang mengeksekusi skrip di origin untuk meminta aplikasi mendekripsi data atau membaca plaintext di memori. Nyatakan batasan tersebut sebelum menjanjikan keamanan.
2. Buat atau impor kunci
Gunakan algoritma yang didukung dan penggunaan khusus untuk tujuan tertentu seperti encrypt dan decrypt. Buat kunci dalam secure context atau impor materi yang di-wrap dengan flag extractability yang diinginkan. Tolak parameter algoritma yang tidak diharapkan dan hindari menyimpan materi kunci mentah di penyimpanan lokal.
3. Simpan ciphertext dengan aman
Simpan ciphertext, nonce baru untuk setiap enkripsi, metadata terautentikasi, versi kunci, dan versi skema. Gunakan enkripsi terautentikasi seperti AES-GCM dengan nonce unik di bawah satu kunci. Simpan cakupan tenant atau pengguna dalam data terkait (associated data), bukan sebagai keputusan kepercayaan implisit.
4. Rencanakan pemulihan dan rotasi
Kunci yang non-extractable dapat menjadi tidak dapat digunakan setelah penghapusan profil atau kehilangan perangkat. Sediakan jalur pemulihan yang dirancang dengan matang, misalnya wrapping key yang diturunkan dari passphrase atau alur enkripsi ulang yang dimediasi server, tanpa menurunkan standar keamanan ke plaintext secara diam-diam. Buat versi kunci dan migrasikan rekaman secara transaksional.
5. Uji dan operasikan
Uji algoritma yang tidak didukung, konteks tidak aman, kesalahan kuota, penulisan yang terputus, penggunaan ulang nonce, migrasi versi, logout, dan kegagalan pemulihan. Terapkan CSP dan tinjauan dependensi, hindari log sensitif, dan ukur kegagalan dekripsi tanpa mencatat plaintext.
Contoh jawaban berkualitas tinggi
“Saya akan mewajibkan HTTPS, membuat CryptoKey dengan tujuan terbatas dan extractable bernilai false, serta hanya menyimpan handle yang dikelola browser di IndexedDB. Setiap rekaman menyimpan ciphertext, nonce unik, metadata terautentikasi, dan versi kunci. Saya akan mendefinisikan pemulihan sebelum merilis fitur karena kehilangan profil dapat membuat kunci non-extractable tidak dapat dipulihkan. CSP dan kontrol dependensi mengurangi risiko skrip aktif, tetapi muatan (payload) XSS yang berjalan di origin masih dapat menjalankan operasi dekripsi yang diizinkan atau membaca plaintext saat aplikasi terbuka.”
Kesalahan umum
- Menyimpan kunci mentah di localStorage → pencurian penyimpanan mengekspos akses plaintext → simpan handle kunci non-extractable.
- Menggunakan kembali nonce dengan AES-GCM → kerahasiaan dan integritas dapat gagal → buat nonce unik per kunci dan rekaman.
- Mengklaim XSS telah teratasi → kode dari origin yang sama dapat menggunakan otoritas aplikasi → nyatakan batasan skrip aktif.
- Melewatkan perancangan pemulihan → kehilangan profil menghancurkan akses data → tentukan alur wrapping, reset, dan migrasi.
Pertanyaan lanjutan dan tanggapan
Apakah IndexedDB membuat kunci aman dari XSS?
Tidak. Ini menghindari penempatan byte mentah di API penyimpanan sederhana, tetapi skrip dari origin yang sama dapat mengakses database atau memanggil kode aplikasi. Gunakan CSP, dependensi tepercaya, dan model ancaman yang realistis.
Bagaimana pengguna dapat memulihkan data setelah kehilangan perangkat?
Wrap kunci data dengan kunci yang diturunkan dari rahasia yang dipegang pengguna atau kredensial pemulihan, atau lakukan enkripsi ulang melalui alur server yang terautentikasi. Jelaskan pertimbangan trade-off luring (offline) dan reset; jangan pernah secara diam-diam membuat kunci baru yang tidak dapat mendekripsi data lama.
Bisakah kunci diekspor selama rotasi?
Hanya jika kebijakan mengizinkannya. Lebih disukai untuk membuat kunci baru dan mengenkripsi ulang rekaman saat kedua versi tersedia; jika wrapping diperlukan, lindungi wrapping key dan audit proses transisinya.