Temu duga Backend: Bagaimanakah anda akan menaik taraf log masuk kuki kepada sesi terikat-peranti?

Gesaan dan konteks

Sistem log masuk sedia ada mengekalkan pengguna log masuk dengan kuki jangka panjang. Pasukan keselamatan ingin mengurangkan main semula rentas peranti (cross-device replay) selepas kecurian kuki, tetapi tidak boleh menaik taraf setiap klien secara serentak atau menyebabkan log keluar beramai-ramai semasa putaran kunci, permulaan semula penyemak imbas, atau pemulihan peranti. Reka bentuk penyepaduan DBSC yang merangkumi pendaftaran, pembaharuan, pembatalan, sandaran (fallback), audit, dan pelancaran beransur-ansur.

Perkara yang diuji oleh penemu duga

• Sama ada anda memisahkan sesi identiti jangka panjang, kuki kebenaran jangka pendek, dan kunci peribadi peranti.
• Sama ada anda boleh menerangkan titik akhir pendaftaran dan pembaharuan, cabaran-tindak balas (challenge-response), dan rekod pengikatan pihak pelayan.
• Sama ada anda mengendalikan kunci yang tidak boleh dieksport, penyemak imbas yang tidak disokong, kuki yang hilang, dan penghijrahan peranti.
• Sama ada anda mereka bentuk pembatalan, putaran kunci, pembaharuan serentak, dan pengesanan anomali.
• Sama ada sempadan keserasian dan keselamatan muncul dalam pelancaran, pemantauan, dan rollback.

Soalan untuk dijelaskan terlebih dahulu

1. Akaun atau operasi manakah yang memerlukan pengikatan peranti, dan yang mana boleh mengekalkan kuki biasa?
2. Apakah jangka hayat sesi maksimum, selang pembaharuan, dan kadar log masuk semula yang boleh diterima?
3. Adakah anda memerlukan berbilang peranti, proksi perusahaan, peranti tanpa TPM, atau subdomain rentas tapak?
4. Selepas kegagalan bukti, patutkah sistem melog keluar, beralih kepada MFA, atau membekukan tindakan berisiko tinggi?
5. Bolehkah get laluan sedia ada menghantar pengepala pendaftaran dan pembaharuan, dan medan manakah yang boleh dilog?

Jawapan 30 saat

"Saya akan mengekalkan keadaan log masuk sedia ada sebagai lapisan keserasian. Selepas log masuk, respons Secure-Session-Registration meminta penyemak imbas mencipta kunci peranti. Pelayan hanya menyimpan kunci awam, pengecam sesi, titik akhir pembaharuan, skop, dan status, kemudian menggantikan kuki jangka panjang dengan kuki jangka pendek. Apabila ia tamat tempoh, penyemak imbas memanggil titik akhir pembaharuan dengan bukti kunci; pelayan mengesahkan tandatangan, cabaran, sesi, dan dasar risiko sebelum mengeluarkan kuki baharu. Kegagalan pendaftaran atau pembaharuan beralih kepada sesi biasa atau MFA mengikut keupayaan dan risiko. Metrik pembatalan, putaran, audit, dan pelancaran mengawal peluasan."

Analisis mendalam langkah demi langkah

1. Tentukan sempadan kepercayaan dan keadaan (state)

Perkhidmatan log masuk masih mengesahkan pengguna; lapisan DBSC membuktikan bahawa penyemak imbas memegang kunci peribadi yang terikat pada sesi tersebut. Simpan sessionId, kunci awam, versi kunci, URL pembaharuan, skop, nama kuki jangka pendek, status, dan masa bukti terakhir. Jangan sekali-kali menyimpan kunci peribadi atau menganggap kunci awam itu sendiri sebagai identiti pengguna.

2. Daftar sesi terikat-peranti

Selepas log masuk berjaya, kembalikan pengepala respons pendaftaran. Penyemak imbas menjana pasangan kunci dan menyerahkan kunci awam ke titik akhir pendaftaran. Pelayan mengesahkan token pendaftaran sekali guna, sesi log masuk, dan asal (origin), menulis pengikatan, dan mengembalikan arahan sesi JSON serta kuki jangka pendek. Pendaftaran mestilah idempoten supaya percubaan semula tidak mencipta pengikatan yatim yang tidak boleh dibatalkan.

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

3. Sahkan bukti kunci semasa pembaharuan

Apabila kuki jangka pendek hampir tamat tempoh, penyemak imbas memanggil titik akhir pembaharuan dengan JWT bukti DBSC. Sahkan algoritma tandatangan, cabaran, pengecam sesi, tetingkap masa, versi kunci, dan skop, kemudian majukan cabaran atau pembilang pembaharuan secara atomik. Jangan lanjutkan kuki lama secara senyap selepas bukti gagal; kembalikan sebab yang boleh diperhatikan dan gunakan dasar risiko.

4. Kendalikan sandaran (fallback) dan berbilang peranti

DBSC bersifat tambahan (additive). Kekalkan sesi biasa apabila penyemak imbas atau perkakasan tidak menyokongnya, sambil memerlukan MFA untuk tindakan berisiko tinggi. Simpan satu pengikatan bagi setiap peranti; membatalkan satu peranti hanya memadamkan pengikatan tersebut, manakala log keluar global membatalkan semua pengikatan dan sesi biasa. Laluan sandaran memerlukan jangka hayat yang lebih pendek dan had kadar (rate limits) supaya ia tidak menjadi jalan pintas.

5. Reka bentuk putaran, keserentakan, dan pemulihan

Putaran kunci mencipta versi baharu dengan tetingkap pertindihan yang pendek; versi lama hanya dibenarkan satu penghijrahan terkawal. Gunakan kunci sesi (session lock) atau kemas kini versi bersyarat supaya pembaharuan serentak tidak menulis ganti cabaran satu sama lain. Pemulihan penyemak imbas, pembersihan data tapak, atau kehilangan kunci membatalkan pengikatan lama dan memerlukan pengesahan semula; kegagalan pembaharuan tidak seharusnya menjadi sekatan kekal secara automatik.

6. Pantau, audit, dan lancarkan secara beransur-ansur

Rekodkan kejayaan pendaftaran, kegagalan bukti, kependaman pembaharuan, kadar sandaran, sebab pembatalan peranti, dan pengedaran versi penyemak imbas, tetapi jangan sekali-kali kunci peribadi. Mulakan dengan akaun berisiko rendah dan bandingkan amaran perampasan dengan kejayaan log masuk. Jika kegagalan meningkat, alih keluar pengepala respons pendaftaran untuk menghentikan pengikatan baharu sambil mengekalkan laluan kuki biasa. Tulis perubahan dasar dan versi kunci ke dalam log audit yang tidak boleh diubah (immutable).

Contoh jawapan yang mantap

"DBSC hanya membuktikan bahawa penyemak imbas memegang kunci peribadi yang terikat pada sesi; sistem log masuk sedia ada masih mengesahkan pengguna. Selepas log masuk, pelayan menggunakan pengepala respons pendaftaran untuk membolehkan penyemak imbas mencipta kunci dan menyerahkan bahagian awamnya, kemudian menggantikan kuki jangka panjang dengan kuki jangka pendek. Titik akhir pembaharuan mengesahkan tandatangan JWT bukti, cabaran, sesi, masa, dan skop sebelum memajukan cabaran secara atomik dan mengeluarkan kuki baharu. Pelayan menyimpan kunci awam, status, versi, dan data audit, tidak sekali-kali kunci peribadi. Berbilang peranti mendapat pengikatan berasingan, dan pembatalan boleh menyasarkan satu peranti atau seluruh pengguna. Klien yang tidak disokong menggunakan sesi biasa terhad atau MFA. Semasa pelancaran, pantau kegagalan bukti, sandaran, dan kejayaan log masuk; jika risiko meningkat, alih keluar pengepala pendaftaran dan kekalkan keserasian."

Kesilapan lazim

• Menganggap kunci awam sebagai identiti pengguna → prinsipal pengikatan dan pengesahan bercampur aduk → gunakan ia hanya sebagai bahan bukti sesi.
• Hanya memendekkan kuki jangka panjang → pencuri masih boleh memainkan semula sepanjang jangka hayatnya → ikat kuki jangka pendek kepada bukti kunci.
• Melangkau perlindungan main semula semasa pembaharuan → satu bukti boleh digunakan semula → ikat cabaran sekali guna, tetingkap masa, dan kemas kini keadaan secara atomik.
• Melog keluar semua orang apabila tidak disokong → keserasian dan ketersediaan terjejas → beralih kepada sesi biasa atau MFA mengikut keupayaan dan risiko.
• Menganggap DBSC sebagai tidak boleh dibatalkan → peranti yang hilang tidak boleh diasingkan → sediakan pembatalan peringkat peranti dan peringkat pengguna berserta audit.

Soalan susulan dan respons

Adakah kunci peribadi menghalang setiap bentuk kecurian kuki?

Tidak. DBSC terutamanya mengurangkan main semula terus selepas kuki dieksport ke peranti lain. Perisian hasad yang mengawal peranti asal, serangan semasa log masuk, atau pelayan yang terjejas masih memerlukan pertahanan lain. Nyatakan model ancaman dan risiko baki secara eksplisit.

Mengapa mengekalkan laluan sesi biasa?

Keupayaan penyemak imbas, perkakasan, dan rangkaian perusahaan berbeza-beza, dan DBSC masih berkembang sebagai piawaian. Laluan keserasian terhad mengelakkan log keluar beramai-ramai; tindakan berisiko tinggi boleh memerlukan semakan yang lebih ketat dan bukannya menggagalkan log masuk.

Bagaimanakah anda mengelakkan perlumbaan pembaharuan serentak (concurrent refresh races)?

Gunakan kemas kini bersyarat pada sessionId dan versi kunci, terima hanya cabaran semasa, dan tulis cabaran seterusnya serta versi kuki secara atomik. Permintaan pendua boleh menerima hasil yang sama atau diminta untuk memperbaharui semula, menghalang respons daripada menulis ganti antara satu sama lain.

Apakah yang berlaku semasa penghijrahan atau pemulihan peranti?

Daftarkannya sebagai peranti baharu dan bukannya menyalin kunci peribadi lama. Kekalkan pengikatan lama untuk tempoh tangguh yang singkat dengan pemeriksaan risiko; selepas pengesahan semula, cipta pengikatan kunci awam baharu dan benarkan pengguna membatalkan rekod lama daripada pengurusan peranti.