後端面試：如何把現有 Cookie 登入升級為裝置綁定工作階段？

題幹與適用場景

一個既有登入系統使用長期 Cookie 維持工作階段。安全團隊希望降低竊取 Cookie 後的跨裝置冒用風險，但不能要求所有客戶端同時升級，也不能讓金鑰輪換、瀏覽器重新啟動或裝置還原導致大量登出。請設計 DBSC 接入方案，涵蓋註冊、更新、撤銷、降級、稽核和灰度發布。

面試官考察點

• 是否區分長期身分工作階段、短期授權 Cookie 和裝置私鑰。
• 是否能說清註冊端點、更新端點、挑戰回應和伺服器綁定記錄。
• 是否處理私鑰不可匯出、瀏覽器不支援、Cookie 缺失和裝置遷移。
• 是否設計撤銷、金鑰輪換、並行更新和異常偵測。
• 是否把相容性與安全邊界寫進灰度、監控和回滾流程。

回答前需要釐清的問題

1. 哪些帳戶或操作必須強制裝置綁定，哪些可以繼續使用普通 Cookie？
2. 工作階段最長存活時間、短期 Cookie 的更新週期和可接受的重新登入率是多少？
3. 是否支援多裝置並存、企業代理、無 TPM 裝置和跨站子網域？
4. 發現證明失敗時是立即登出、降級到 MFA，還是凍結高風險操作？
5. 現有閘道能否轉送註冊與更新回應標頭，日誌中哪些欄位允許留存？

30 秒回答框架

「我會保留現有登入態作為相容層，在登入成功後透過 Secure-Session-Registration 要求瀏覽器建立裝置金鑰。伺服器只保存公開金鑰、工作階段識別、更新端點、範圍和狀態，並把長期 Cookie 換成短期 Cookie。短期 Cookie 到期時，瀏覽器向更新端點發起帶金鑰證明的請求，伺服器驗證簽章、挑戰、工作階段和風控後簽發新 Cookie。註冊或更新失敗時按裝置能力與風險降級到普通工作階段或 MFA；撤銷、輪換、稽核和灰度指標決定是否擴大啟用範圍。」

分步驟深入解答

1. 定義信任邊界與狀態

登入服務仍負責使用者驗證，DBSC 層負責證明目前瀏覽器持有與工作階段綁定的私鑰。伺服器記錄 sessionId、公開金鑰、金鑰版本、更新端點、範圍、短期 Cookie 名稱、狀態和最後證明時間；不保存私鑰，也不把公開金鑰本身當作使用者身分。

2. 註冊裝置綁定工作階段

登入成功回應攜帶註冊回應標頭。瀏覽器產生金鑰對，並把公開金鑰提交到註冊端點。伺服器驗證一次性註冊權杖、登入工作階段和來源，寫入綁定記錄，然後回傳 JSON 工作階段設定與短期 Cookie。註冊操作必須具備冪等性，重複提交不能產生無法撤銷的孤兒綁定。

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

3. 更新時驗證金鑰證明

短期 Cookie 即將過期時，瀏覽器呼叫更新端點並攜帶 DBSC proof JWT。伺服器檢查簽章演算法、挑戰值、工作階段識別、時間視窗、金鑰版本和範圍，再以原子操作推進挑戰或更新計數。驗證失敗不能靜默延長舊 Cookie，應回傳可觀測的失敗原因並進入風險策略。

4. 處理降級與多裝置

DBSC 是增量能力。瀏覽器或硬體不支援時保留普通工作階段，但高風險操作可要求 MFA。多裝置對應多筆綁定記錄，使用者撤銷某一裝置只刪除該記錄；全域登出則撤銷使用者所有綁定和普通工作階段。降級路徑必須設定較短生命週期與速率限制，避免成為繞過點。

5. 設計輪換、並行與復原

金鑰輪換建立新版本並保留短暫重疊視窗，舊版本只允許一次受控遷移。更新請求使用工作階段鎖或版本條件更新，避免並行請求互相覆蓋挑戰。瀏覽器復原、清除網站資料或私鑰遺失時，伺服器撤銷舊綁定並要求重新驗證；不能把「更新失敗」直接視為永久封鎖。

6. 監控、稽核與灰度

記錄註冊成功率、證明失敗率、更新延遲、降級比例、裝置撤銷原因和按瀏覽器版本分布，但不記錄私鑰。先對低風險帳戶灰度，比較工作階段劫持告警與登入成功率；異常升高時移除註冊回應標頭即可停止新增綁定，保留普通 Cookie 相容路徑。所有策略和金鑰版本變更寫入不可變稽核記錄。

高品質示範回答

「DBSC 層只證明瀏覽器持有與工作階段綁定的私鑰，使用者驗證仍由原登入系統完成。登入後，伺服器透過註冊回應標頭讓瀏覽器產生金鑰並提交公開金鑰，再把長期 Cookie 換成短期 Cookie。更新端點驗證 proof JWT 的簽章、挑戰、工作階段、時間和範圍，原子推進挑戰後簽發新 Cookie。伺服器保存公開金鑰、狀態、版本和稽核資訊，不保存私鑰。多裝置使用獨立綁定記錄，撤銷可以按裝置或全域執行；不支援 DBSC 的客戶端走受限普通工作階段或 MFA。灰度階段監控證明失敗、降級和登入成功率，出現異常時移除註冊回應標頭並保留相容路徑。」

常見錯誤

• 把公開金鑰當作使用者身分 → 裝置綁定記錄與驗證主體混淆 → 公開金鑰只作為工作階段證明材料。
• 只把長期 Cookie 改短 → 竊取者仍可在有效期內冒用 → 短期 Cookie 必須和私鑰證明綁定。
• 更新端點不做挑戰重放保護 → 同一證明可被重複使用 → 綁定一次性挑戰、時間窗和原子狀態更新。
• 不支援就強制登出所有人 → 相容性和可用性風險過大 → 按能力與風險降級到普通工作階段或 MFA。
• 把 DBSC 當成不可撤銷憑證 → 裝置遺失後無法隔離風險 → 提供裝置級、使用者級撤銷和稽核。

追問及應對

私鑰真的能防住所有 Cookie 竊取嗎？

不能。DBSC 主要降低把 Cookie 匯出到另一台裝置後直接冒用的風險；已控制原裝置的惡意軟體、登入過程中的攻擊或伺服器失陷仍需要其他防護。回答應明確威脅模型和殘餘風險。

為什麼伺服器還要保留普通工作階段路徑？

瀏覽器、硬體和企業網路能力不一致，且 DBSC 仍處於標準演進階段。保留受限相容路徑可避免全量登出；高風險操作可以提高驗證要求，而不是讓登入系統失效。

如何防止並行更新導致工作階段錯亂？

按 sessionId 和金鑰版本做條件更新，只接受目前挑戰，成功後原子寫入下一挑戰與 Cookie 版本。重複請求回傳同一結果或要求重新更新，避免兩個回應互相覆蓋。

裝置遷移或復原備份時怎麼辦？

把它當成新裝置註冊，而不是複製舊私鑰。舊綁定可以保留短暫寬限期並觸發風控；完成重新驗證後再建立新公開金鑰綁定，使用者可在裝置管理頁撤銷舊記錄。