密碼很複雜，登入頁就安全？別讓三道防線只剩一把鎖

資安檢測

資安檢測｜奧微軟體開發企業社｜2026-10-14

摘要：登入頁能成功登入，不等於防線完整。企業應把密碼品質、第二因素與失敗登入限制分開驗收，再確認 App、API 與帳號復原沒有留下旁門。本篇提供一張可交給開發團隊的檢查表，避免把「有設定」誤當「有保護」。

分類：資安檢測作者：奧微軟體開發企業社日期：2026-10-14

先問三件事，不要只看密碼規則

公司網站要求大小寫、數字、符號，登入時還會跳驗證碼，於是驗收表寫了「登入安全完成」。但企業主真正要問的是：密碼被猜中時還有沒有第二道門？有人持續嘗試時會不會被攔下？換到手機 App 或登入 API，保護還在不在？

我們的判斷是：登入安全不是一個勾選框，而是三道不同責任的防線。密碼品質降低容易被猜中的風險；第二因素讓拿到密碼不等於直接入場；嘗試限制控制線上猜測的機會。它們不能互相冒充，也不代表能解決所有帳號盜用。以下是防守方的驗收建議，不是對任何企業系統做過實測的結論。

NIST SP 800-63B-4 的密碼指引要求檢查常用、可預期或已外洩的密碼，並不以強制混合字元類型取代這件事；也不要求無理由定期換密碼，有被入侵的證據時才應強制更換。這是美國數位身分技術指引，不是台灣所有公司的法律義務。NIST 密碼驗證規則

企業可以先請團隊回答：新密碼是否有弱密碼封鎖檢查？使用者能否貼上密碼管理器產生的密碼？密碼長度規則是否有依單因素或多因素使用方式設計？不要只交一張「含特殊符號」的截圖。也不要要求同事把真密碼交給檢測人員；驗收應使用獨立測試帳號與核准的範圍。

多因素驗證要來自不同類型的因素；再問一次安全問題，不等於補上一個持有因素。更容易漏掉的是入口差異：網頁有第二因素，App、另一個登入 API 或帳號復原卻沒有同等保護。OWASP 提醒，多種登入方式都應要求 MFA，或有其他保護；復原機制也不能變成接管帳號的捷徑。OWASP 多因素驗證指引

先盤點實際登入路徑，再確認管理員等高影響帳號是否強制完成註冊，而不只是提供可選功能。若評估通行金鑰（passkey），要確認實作有使用者驗證與伺服器端檢查；不能把任何「碰一下金鑰」都當成雙因素。換手機、遺失裝置、重設因素的流程，也要有身分核驗、通知與紀錄。

只擋同一個 IP，不等於已控制同一帳號的持續猜測。OWASP 建議失敗計數與帳號關聯，並設計嘗試門檻、觀察時間窗與鎖定時間，同時避免讓他人藉鎖帳造成服務阻斷。圖形驗證碼只能作為多層防禦的一部分，不是萬能保證。OWASP 登入節流與鎖定

門檻不是照抄一個數字就完工。請先依系統用途訂好規則，在測試環境確認超過門檻會出現什麼行為、等待後如何恢復、事件是否留下可追查的紀錄。操作前要有書面授權、測試帳號與停止條件；不要拿正式客戶帳號連續試錯，更不要用真實流量做壓力試驗。

下表是奧微整理的實務檢查表，不是官方條文的完整替代，也不是滲透測試結果。

例如，一間虛構的訂單公司在網頁加了第二因素，卻仍保留舊 App 的密碼登入。此時不能因網頁通過就結案：應先列出舊入口的用途、負責人與限制方式，再在核准環境確認不能繞開保護。這是教學情境，不是奧微客戶案例，也不代表某套產品存在漏洞。

不一定。若使用成熟的身分服務，重點可以是確認租戶設定、應用程式接法與復原流程，而不是再寫一套密碼系統。反過來，購買服務也不能代替驗收：應用程式仍可能接錯入口或留下較弱的備援路徑。這是工程判斷，需要依實際架構確認。

若公司說不清楚有哪些登入入口、規則在哪裡生效，可以帶著系統清單與已知疑問，討論智盾資安服務的檢測範圍。官網列有網站、內部系統、資料庫與程式源碼四面向檢測，AI 輔助滲透測試加人工驗證，以及風險分級報告與修補建議；實際範圍依需求確認，不保證帳號永不被盜。

最後把驗收問題從「登入做完了嗎」改成「三道防線在哪些入口有效，拿什麼證明」。測得出來、有人負責、出問題能處置，才比多一個安全勾選框有用。

來源與查核日期：上述 NIST、OWASP 兩份指引與奧微智盾官網，查核日 2026-10-14。本文沒有採用未核實的近期事故、統計或法規適用結論。

作者與商業關係：本文由奧微軟體開發企業社撰寫，奧微提供軟體開發與資安檢測服務。檢查表、教學情境與工程判斷為作者整理，與 NIST、OWASP 無隸屬或背書關係。