題目與適用場景
使用者已登入帳戶並提交新信箱。系統要確認新地址確實由使用者控制，同時降低遭竊工作階段、信箱枚舉、重複點擊與並行請求造成的帳戶接管風險。請說明資料模型、權杖生命週期、舊信箱通知、工作階段策略、限流、稽核與失敗恢復。
回答前先約定：變更信箱會影響登入、找回密碼與安全通知，因此屬於高風險帳戶操作；目前工作階段可能已被竊取；新舊信箱都可能暫時無法使用；同一帳戶同時只能有一個有效變更請求。
面試官在考察什麼
面試官會看候選人是否區分「已登入」與「已重新證明身分」，以及是否要求高風險操作重新驗證或追加多因素驗證。也會看是否把新信箱先存成待驗證值，而不是立即覆蓋目前信箱。
安全細節同樣重要：一次性隨機權杖、短有效期、伺服器只保存權杖摘要、重放防護、舊信箱通知、統一錯誤訊息與稽核事件。優秀回答還會說明工作階段撤銷、恢復路徑與並行更新的不變量。
30 秒回答框架
「我先要求目前工作階段重新驗證；高風險帳戶再要求既有多因素驗證。伺服器把新信箱寫入獨立 pending 記錄，不立即替換目前信箱。向新信箱寄送一次性隨機權杖，資料庫只保存權杖摘要、用途、過期時間與已使用狀態。使用者點擊後，在交易中鎖定帳戶，驗證摘要、有效期與版本，成功才原子更新信箱並消費請求。舊信箱收到安全通知與可取消窗口，所有工作階段依風險重新驗證或撤銷。介面使用統一回應、按帳戶與網路限流，並記錄不含權杖的稽核事件。」
分步深入解答
第一步：定義帳戶與待處理請求
帳戶保留 currentemail，變更請求獨立存放 pendingemail_change：帳戶 ID、新信箱正規化值、權杖摘要、用途、過期時間、狀態、版本、建立時間與發起工作階段的風險脈絡。驗證前新信箱不能用於登入或找回密碼。
第二步：重新驗證並建立風險邊界
登入狀態只代表工作階段仍有效。開始流程時要求近期密碼或既有多因素驗證，必要時檢查裝置、IP 與異常行為。不要把「使用者知道新信箱」當作目前身分證明。重新驗證結果應是短時、單用途的 step-up 標記，不能成為長期萬用權杖。
第三步：產生並寄送一次性權杖
使用密碼學安全隨機數產生權杖，設定短 TTL 與單一用途。資料庫只保存不可逆摘要，信件連結攜帶原始權杖。信件內容不洩露帳戶是否存在，重寄操作保持節流；權杖被消費、過期或請求被替換後都不可再次使用。
第四步：驗證並原子提交
點擊連結後先做格式與速率檢查，再在交易中鎖定帳戶及待處理記錄。以常量時間比較摘要，檢查狀態、TTL、用途與版本。確認新信箱沒有被其他帳戶占用後，原子更新目前信箱、消費請求並寫入稽核事件。重複點擊回傳冪等成功或安全的已處理結果。
第五步：處理舊信箱、工作階段與通知
舊信箱收到「信箱即將或已變更」的安全通知，並可在短窗口內取消尚未完成的請求。成功後撤銷長期刷新權杖，或要求所有工作階段重新驗證；高風險情境可立即撤銷全部工作階段。新信箱不能成為唯一的即時恢復依據。
第六步：控制枚舉、濫用與競態
請求與驗證介面都使用統一回應時間與訊息，不告訴攻擊者某信箱是否註冊。按帳戶、目標信箱、裝置與網路組合限流。唯一約束、資料列鎖或版本條件更新防止兩個請求同時成功；占用檢查必須和更新在同一交易邊界內。
第七步：設計恢復與不可用情況
信件延遲時允許在額度內重寄並使舊權杖失效。使用者失去舊信箱時，不能只憑一個未驗證的新信箱直接接管，應轉入更強的帳戶恢復流程。投遞失敗、信箱已占用與策略拒絕不暴露內部細節，但稽核保留安全原因碼。
第八步：驗證威脅模型與指標
測試工作階段遭竊、權杖重放、過期權杖、並行點擊、舊信箱取消、刷新權杖撤銷、跨帳戶信箱占用與介面枚舉。指標包括 step-up 失敗率、權杖重放率、確認到工作階段撤銷延遲、通知投遞率與人工恢復量。
取捨、邊界與資訊增益
短 TTL 可縮小權杖暴露窗口，卻會增加信件延遲造成的重寄；可用限額重寄與明確狀態平衡。立即撤銷全部工作階段安全性高，但會中斷多裝置，因此可按帳戶風險分級。舊信箱取消窗口提高可恢復性，卻不能涵蓋已完成的高風險變更。
只保存權杖摘要可保護資料庫洩露，但應用日誌、信件連結、瀏覽器歷史仍可能洩露原始值，所以各鏈路都要脫敏並避免把權杖送入分析 URL。信箱唯一性約束簡化一致性，但產品必須明確一個信箱是否能綁定多個帳戶。
高品質示範回答
「我會把變更信箱視為高風險狀態機。使用者先完成近期重新驗證，必要時通過既有 MFA。新地址寫入獨立待處理記錄，目前信箱仍用於登入與恢復。系統以 CSPRNG 產生一次性權杖，設定短 TTL，資料庫只保存摘要與用途、版本、狀態。
驗證請求在交易中鎖定帳戶與記錄，檢查摘要、過期時間、版本與信箱唯一約束，接著原子更新目前信箱、消費請求並寫稽核事件。舊信箱收到安全通知；未完成請求可在短窗口內取消。成功後撤銷刷新權杖並要求其他工作階段重新驗證，程度由風險策略決定。
所有介面使用統一錯誤訊息，按帳戶、目標地址與網路限流，日誌只保留安全原因碼。重放、並行點擊、失去舊信箱與投遞失敗都有明確恢復路徑。」
常見錯誤
- 送出表單就立即替換信箱。 未驗證地址會鎖死使用者，也可能被遭竊工作階段利用。
- 只依賴目前登入狀態。 工作階段竊取者可以直接完成高風險操作。
- 把權杖明文存進資料庫或日誌。 這會把資料庫、日誌與支援系統變成接管入口。
- 權杖可以重複使用。 重放可能重複觸發通知或覆蓋地址。
- 驗證介面暴露信箱存在性。 攻擊者可藉此枚舉使用者。
- 忽略唯一約束競態。 兩個帳戶或請求可能同時占用同一地址。
- 變更後保留所有長期工作階段。 攻擊者可繼續使用已竊取的刷新權杖。
- 失去舊信箱時直接信任新信箱。 這繞過帳戶恢復所需的身分保證。
追問與參考答案
為什麼不先把新信箱寫入帳戶再非同步驗證？
登入、找回密碼與通知可能立即使用該值，非同步回滾會產生競態與錯誤窗口。獨立 pending 值讓未驗證輸入無法影響身分邊界。
權杖 TTL 應該多長？
沒有脫離威脅模型的固定數字。依郵件投遞分布與風險目標選擇短窗口，搭配限次重寄；重點是記錄並驗證從簽發到失效的實測上限。
舊信箱通知能取代 MFA 嗎？
不能。通知與取消窗口是縱深防禦與恢復訊號，無法證明操作者擁有高保證身分。高風險帳戶仍應要求既有 MFA 或更強恢復流程。
兩個分頁同時確認怎麼辦？
用記錄版本、單次狀態與交易鎖保證只有一個請求能從 pending 轉為 consumed。第二次回傳冪等結果，不重複更新信箱或撤銷工作階段。
如何避免權杖出現在分析系統？
使用一次性路徑並在邊緣、應用、追蹤與錯誤回報層過濾查詢參數；消費後重新導向到不含權杖的乾淨 URL，並禁止快取敏感回應。