登入防護

這一頁解決什麼

登入頁是唯一對外的入口，會被拿來猜密碼、探測帳號是否存在。 這一頁講三件事：怎麼擋住猜測、回應為什麼不告訴對方哪裡錯了、 以及使用者的登入狀態放在哪裡。

兩道互補的防線

來源限流

登入端點對來源位址限流，擋的是換帳號輪流試的密碼噴灑。 超速回 429，回應不透露剩餘額度或重置時間。 來源位址取自系統的可信代理設定，不無條件相信請求標頭； 部署在反向代理後方時，.env 的 TRUSTED_PROXIES 要填。

單一登入的相關端點另外有自己的來源速率與整體容量上限。

帳號鎖定

鎖定門檻與時長由安全政策決定，出廠是連續 10 次失敗鎖 30 分鐘。 密碼失敗與雙因素驗證失敗共用同一個計數，成功登入即歸零。 目錄帳號同樣納入這個計數。鎖定期間的回應只說帳號已暫時鎖定，不說還要等多久、也不說試了幾次。 管理員可以在「使用者管理」手動解鎖。

回應為什麼那麼像

帳號不存在、密碼錯誤、帳號已停用而密碼也錯，這三種情形回同一個狀態碼與同一個錯誤碼， 而且帳號狀態的判定發生在憑證驗證之後。這是刻意的：不讓沒有憑證的人拿登入頁當帳號名單來查。

憑證正確但帳號已被停用是例外，這種情形回一個專屬的錯誤碼， 因為使用者需要知道自己該去找管理員。

憑證放在哪裡

存取憑證固定 15 分鐘有效，只存在分頁的記憶體裡， 不寫入 localStorage、sessionStorage、IndexedDB 或 cookie。 換發用的憑證唯一的載體是 HttpOnly cookie，附 SameSite 限制，路徑收斂在認證端點群。

頁面載入時，導覽守衛放行受保護的頁面之前，會先用這個 cookie 換一次存取憑證。 跨分頁之間只傳事件，不傳憑證本體，所以任一分頁登出，同瀏覽器的其他分頁立即清乾淨。

cookie 要不要限定在加密連線上送出，由安全政策的 「登入狀態僅在 https 連線保存」控制，出廠開啟，設定方式見 TLS 與憑證。

工作階段治理

換發要同時滿足四個條件：憑證未被撤銷、未超過絕對壽命（出廠 12 小時）、 距上次活動未超過閒置上限（出廠 60 分鐘）、來源位址落在該帳號的允許清單內。

每次成功換發都會輪替憑證。舊憑證被重放時，該帳號的全部換發憑證一併撤銷。 登出撤銷當前憑證；改密、帳號停用、帳號鎖定撤銷全部憑證；帳號停用同時中斷進行中的連線。 角色變更會推進憑證世代，讓舊憑證失效。

存取憑證只從 Authorization 標頭接受，不放在網址上。

稽核看得到什麼

• 登入成功與失敗各留一筆，含帳號、來源位址、結果。
• 限流以聚合列記錄，含原因、來源位址、次數與起訖時間。
• 憑證換發以三種狀態留痕：正常輪替、被拒、偵測到重放。
• 來源位址被拒留紀錄，含位址與判定依據，而且不計入失敗登入次數。
• 帳號首次自某個來源位址登入時另留一筆觀測紀錄。