Wawancara Backend: Bagaimana Anda meningkatkan login cookie ke sesi terikat-perangkat (device-bound)?

Petunjuk dan konteks

Sistem login yang ada mempertahankan pengguna tetap masuk dengan cookie berumur panjang. Tim keamanan ingin mengurangi pemutaran ulang lintas perangkat (cross-device replay) setelah pencurian cookie, tetapi tidak dapat meningkatkan versi semua klien sekaligus atau menyebabkan logout massal selama rotasi kunci, browser dimulai ulang, atau pemulihan perangkat. Rancang integrasi DBSC yang mencakup pendaftaran, refresh, pencabutan, fallback, audit, dan peluncuran bertahap.

Apa yang sedang diuji oleh pewawancara

Apakah Anda memisahkan sesi identitas berumur panjang, cookie otorisasi berumur pendek, dan kunci privat perangkat.
Apakah Anda dapat menjelaskan endpoint pendaftaran dan refresh, tantangan-tanggapan (challenge-response), serta rekaman pengikatan sisi server.
Apakah Anda menangani kunci yang tidak dapat diekspor, browser yang tidak didukung, cookie yang hilang, dan migrasi perangkat.
Apakah Anda merancang pencabutan, rotasi kunci, refresh bersamaan (concurrent), dan deteksi anomali.
Apakah batasan kompatibilitas dan keamanan terlihat dalam peluncuran, pemantauan, dan rollback.

Pertanyaan untuk diklarifikasi terlebih dahulu

Akun atau operasi mana yang memerlukan pengikatan perangkat, dan mana yang boleh tetap menggunakan cookie biasa?
Berapa masa pakai sesi maksimum, interval refresh, dan tingkat login ulang yang dapat diterima?
Apakah Anda memerlukan dukungan multi-perangkat, proksi perusahaan, perangkat tanpa TPM, atau subdomain lintas-situs?
Setelah kegagalan pembuktian (proof failure), apakah sistem harus mengeluarkan pengguna, beralih ke MFA, atau membekukan tindakan berisiko tinggi?
Bisakah gateway yang ada meneruskan header pendaftaran dan refresh, serta kolom mana saja yang boleh dicatat dalam log?

Jawaban 30 detik

"Saya akan mempertahankan status login yang ada sebagai lapisan kompatibilitas. Setelah login, respons Secure-Session-Registration meminta browser untuk membuat kunci perangkat. Server hanya menyimpan kunci publik, pengidentifikasi sesi, endpoint refresh, cakupan (scope), dan status, kemudian mengganti cookie berumur panjang dengan cookie berumur pendek. Saat kedaluwarsa, browser memanggil endpoint refresh dengan bukti kunci; server memverifikasi tanda tangan, challenge, sesi, dan kebijakan risiko sebelum menerbitkan cookie baru. Kegagalan pendaftaran atau refresh akan dialihkan (fallback) ke sesi biasa atau MFA sesuai kemampuan dan risiko. Pencabutan, rotasi, audit, dan metrik peluncuran mengontrol ekspansi."

Pembahasan mendalam langkah demi langkah

1. Tentukan batasan kepercayaan dan status (state)

Layanan login tetap mengautentikasi pengguna; lapisan DBSC membuktikan bahwa browser memegang kunci privat yang terikat pada sesi. Simpan sessionId, kunci publik, versi kunci, URL refresh, cakupan, nama cookie berumur pendek, status, dan waktu pembuktian terakhir. Jangan pernah menyimpan kunci privat atau memperlakukan kunci publik itu sendiri sebagai identitas pengguna.

2. Daftarkan sesi yang terikat ke perangkat

Setelah login berhasil, kembalikan header respons pendaftaran. Browser menghasilkan pasangan kunci dan mengirimkan kunci publik ke endpoint pendaftaran. Server memvalidasi token pendaftaran sekali pakai, sesi login, dan asal (origin), menulis pengikatan, serta mengembalikan instruksi sesi JSON ditambah cookie berumur pendek. Pendaftaran harus idempoten agar percobaan ulang tidak menciptakan pengikatan yatim (orphan) yang tidak dapat dicabut.

http

Secure-Session-Registration: (ES256); path="/StartSession"
Set-Cookie: auth_cookie=short-lived; Max-Age=600; Secure; HttpOnly; SameSite=Lax

3. Verifikasi bukti kunci selama refresh

Saat cookie berumur pendek mendekati masa kedaluwarsa, browser memanggil endpoint refresh dengan JWT bukti DBSC. Validasi algoritma tanda tangan, challenge, pengidentifikasi sesi, jendela waktu, versi kunci, dan cakupan, lalu tingkatkan challenge atau penghitung refresh secara atomik. Jangan memperpanjang cookie lama secara diam-diam setelah bukti gagal; kembalikan alasan yang dapat diobservasi dan terapkan kebijakan risiko.

4. Tangani fallback dan multi-perangkat

DBSC bersifat aditif. Pertahankan sesi biasa jika browser atau perangkat keras tidak mendukungnya, sembari mewajibkan MFA untuk tindakan berisiko tinggi. Simpan satu pengikatan per perangkat; mencabut satu perangkat hanya menghapus pengikatan tersebut, sedangkan logout global mencabut semua pengikatan dan sesi biasa. Jalur fallback membutuhkan masa pakai yang lebih pendek dan batas laju (rate limits) agar tidak menjadi celah pintas (bypass).

5. Rancang rotasi, konkurensi, dan pemulihan

Rotasi kunci membuat versi baru dengan jendela tumpang tindih yang singkat; versi lama hanya diizinkan melakukan satu migrasi terkontrol. Gunakan kunci sesi (session lock) atau pembaruan versi bersyarat sehingga refresh yang bersamaan tidak menimpa challenge satu sama lain. Pemulihan browser, penghapusan data situs, atau kunci yang hilang akan mencabut pengikatan lama dan memerlukan autentikasi ulang; kegagalan refresh tidak boleh langsung menjadi pemblokiran permanen.

6. Pantau, audit, dan luncurkan secara bertahap

Catat keberhasilan pendaftaran, kegagalan bukti, latensi refresh, tingkat fallback, alasan pencabutan perangkat, dan distribusi versi browser, tetapi jangan pernah mencatat kunci privat. Mulai dengan akun berisiko rendah dan bandingkan peringatan pembajakan dengan keberhasilan login. Jika kegagalan meningkat, hapus header respons pendaftaran untuk menghentikan pengikatan baru sambil tetap mempertahankan jalur cookie biasa. Tulis perubahan kebijakan dan versi kunci ke dalam log audit yang tidak dapat diubah (immutable).

Contoh jawaban yang kuat

"DBSC hanya membuktikan bahwa browser memegang kunci privat yang terikat pada suatu sesi; sistem login yang ada tetap mengautentikasi pengguna. Setelah login, server menggunakan header respons pendaftaran agar browser membuat kunci dan mengirimkan bagian publiknya, lalu mengganti cookie berumur panjang dengan yang berumur pendek. Endpoint refresh memvalidasi tanda tangan JWT bukti, challenge, sesi, waktu, dan cakupan sebelum memajukan challenge secara atomik dan menerbitkan cookie baru. Server menyimpan kunci publik, status, versi, dan data audit, tidak pernah kunci privat. Beberapa perangkat mendapatkan pengikatan terpisah, dan pencabutan dapat menargetkan satu perangkat atau seluruh pengguna. Klien yang tidak didukung menggunakan sesi biasa yang dibatasi atau MFA. Selama peluncuran, pantau kegagalan bukti, fallback, dan keberhasilan login; jika risiko meningkat, hapus header pendaftaran dan pertahankan kompatibilitas."

Kesalahan umum

Memperlakukan kunci publik sebagai identitas pengguna → prinsipal pengikatan dan autentikasi menjadi tercampur → gunakan hanya sebagai materi bukti sesi.
Hanya memperpendek cookie berumur panjang → pencuri masih dapat memutarnya ulang selama masa aktifnya → ikat cookie berumur pendek ke bukti kunci.
Melewatkan perlindungan replay saat refresh → satu bukti dapat digunakan kembali → ikat challenge sekali pakai, jendela waktu, dan pembaruan status atomik.
Mengeluarkan semua orang saat tidak didukung → kompatibilitas dan ketersediaan terganggu → beralihlah ke sesi biasa atau MFA berdasarkan kemampuan dan risiko.
Memperlakukan DBSC sebagai hal yang tidak dapat dibatalkan → perangkat yang hilang tidak dapat diisolasi → sediakan pencabutan tingkat perangkat dan tingkat pengguna disertai audit.

Pertanyaan lanjutan dan tanggapan

Apakah kunci privat menghentikan semua bentuk pencurian cookie?

Tidak. DBSC terutama mengurangi pemutaran ulang langsung setelah cookie diekspor ke perangkat lain. Malware yang mengendalikan perangkat asli, serangan selama login, atau server yang disusupi tetap memerlukan pertahanan lain. Nyatakan model ancaman dan risiko residual secara eksplisit.

Mengapa mempertahankan jalur sesi biasa?

Kemampuan browser, perangkat keras, dan jaringan perusahaan berbeda-beda, dan DBSC masih terus berkembang sebagai standar. Jalur kompatibilitas terbatas menghindari logout massal; tindakan berisiko tinggi dapat memerlukan pemeriksaan yang lebih ketat daripada menggagalkan proses login.

Bagaimana Anda mencegah kondisi perlombaan (race condition) pada refresh yang bersamaan?

Gunakan pembaruan bersyarat pada sessionId dan versi kunci, terima hanya challenge saat ini, dan tulis challenge berikutnya serta versi cookie secara atomik. Permintaan duplikat dapat menerima hasil yang sama atau diminta untuk melakukan refresh lagi, mencegah respons saling menimpa satu sama lain.

Apa yang terjadi selama migrasi atau pemulihan perangkat?

Daftarkan sebagai perangkat baru daripada menyalin kunci privat lama. Pertahankan pengikatan lama selama masa tenggang singkat dengan pemeriksaan risiko; setelah autentikasi ulang, buat pengikatan kunci publik baru dan izinkan pengguna mencabut rekaman lama dari manajemen perangkat.