很多公司修訂密碼政策時卡在兩邊：稽核清單還寫著「大小寫、數字、符號都要有，而且定期強制更換」，美國 NIST 在 2025 年 7 月定案的 SP 800-63B-4 卻明文禁止這兩種做法，改為要求更長的密碼、比對外洩密碼黑名單，並允許貼上與密碼管理器[1]。另一方面，台灣《資通安全責任等級分級辦法》在 2026 年 1 月 7 日修正後[2]，附表十「資通系統防護基準」仍要求「最低密碼複雜度」與依機關規定的效期變更密碼[3]。

這篇寫給正在撰寫或修訂公司密碼政策的 IT 人員與主管：先整理 NIST 與台灣規定的實際條文、兩者衝突時怎麼兼顧，再談密碼管理器的選擇與風險、通行金鑰，以及共用帳號與服務帳號，最後附一份可以直接改寫的政策大綱。MFA 的種類與導入順序，請見多因素驗證導入指南。

NIST SP 800-63B-4：密碼規則改了什麼

NIST SP 800-63B-4 於 2025 年 7 月正式發布，取代 2020 年版的 SP 800-63B[1]。它是為美國聯邦政府資訊系統訂定的指引，對台灣企業沒有法律效力，但常被當作密碼政策的技術依據。條文用「SHALL」（必須）與「SHOULD」（建議）區分強度，以下照原文整理[1]：

  • 最短長度：密碼若是唯一的驗證因素，至少 15 字元；只作為多因素驗證其中一環的密碼可以較短，但至少 8 字元（SHALL）。
  • 最長長度與字元：應允許至少 64 字元，並接受所有可列印的 ASCII 字元、空白與 Unicode 字元（SHOULD）。
  • 不設組成規則：除了黑名單之外，不得再要求混用不同類型的字元（SHALL NOT）。
  • 不定期強制更換：不得要求使用者定期改密碼（SHALL NOT）；但有證據顯示密碼已遭盜用時，必須強制更換（SHALL）。
  • 黑名單比對：設定或變更密碼時，必須把整個密碼和常用、可預期或已外洩的密碼清單比對，例如過去外洩事件中的密碼、字典單字，以及服務名稱、帳號名稱與其變形；命中時要求使用者另選，並說明原因（SHALL）。
  • 不用提示與安全提問：不得讓未通過驗證的人看到密碼提示，也不得要求使用者設定「第一隻寵物叫什麼」這類知識型問題（SHALL NOT）。
  • 允許密碼管理器與貼上：必須允許密碼管理器與自動填入（SHALL），並應允許「貼上」（SHOULD）。
  • 限制錯誤次數：同一帳號連續驗證失敗的上限不得超過 100 次，機關可以訂得更低（SHALL）。
  • 安全儲存：密碼必須加鹽，並以適當的密碼雜湊機制儲存，以抵抗離線破解（SHALL）。

NIST 在附錄說明了理由：外洩密碼資料庫的分析顯示，組成規則的效益不如預期，對使用性與記憶的負擔卻很重；使用者的反應也很好預測，原本會用「password」的人，被要求大寫加數字後就改成「Password1」，再要求符號就變成「Password1!」[1]。因此 NIST 把重點放在長度與黑名單。同一份附錄也提醒，鍵盤側錄、釣魚與社交工程對長而複雜的密碼一樣有效；規範本文更直接寫明密碼不抗釣魚[1]。這部分要靠 MFA 與端點防護，密碼被惡意程式整批偷走的情境見資訊竊取程式與外洩帳密。

黑名單怎麼做：外洩密碼比對

自己蒐集外洩密碼並不實際，常見做法是查詢 Have I Been Pwned（HIBP）的 Pwned Passwords 服務。它的範圍查詢 API 採 k-匿名（k-anonymity）設計：系統在本機算出密碼的 SHA-1 雜湊後，只送出前 5 個字元，API 回傳所有以這 5 個字元開頭的雜湊後綴與各自在資料集中出現的次數，比對在本機完成[4]。一次查詢通常回傳約 800 筆；加上 Add-Padding: true 標頭，每次回應都會填充到 800 至 1,000 筆，旁人無法從回應大小推測查了哪個前綴[4]。這個 API 不需要 API 金鑰、沒有速率限制，也能以 NTLM 雜湊格式查詢；不想依賴線上服務的話，也可以下載完整的雜湊清單離線比對[4]。

實作上，可以在自建系統的註冊、變更與重設密碼流程加入這項檢查。使用現成身分平台的公司，先確認平台本身是否已提供禁用密碼或外洩密碼檢查的功能。

台灣的規定：附表十與上市櫃指引

附表十要求什麼

《資通安全責任等級分級辦法》第 11 條規定，公務機關與特定非公務機關自行或委外開發的資通系統，要依附表九完成防護需求分級（高、中、普），並依附表十「資通系統防護基準」執行控制措施[2]。A、B、C 級機關的應辦事項（附表一至附表六）都列有這一項：A、B 級在初次受核定或等級變更後一年內完成；C 級一年內完成分級、二年內完成控制措施[2]。本辦法最近一次修正是 2026 年 1 月 7 日，修正條文自發布日施行[2]。哪些組織屬於特定非公務機關，見資通安全管理法重點整理。

附表十「識別與鑑別」構面中，和密碼有關的條文如下[3]：

  • 普級（中、高級也要做）：以預設密碼初次登入後應立即變更；身分驗證相關資訊不以明文傳輸；登入驗證失敗達五次後，至少十五分鐘內不允許該帳號繼續嘗試，或使用機關自建的失敗驗證機制；使用密碼驗證時，應強制最低密碼複雜度，並依機關密碼效期規定變更密碼；變更密碼時，至少不可與前三次使用過的密碼相同；後兩項對外部使用者，機關得自行規範。
  • 中級與高級另外要求：身分驗證機制要防範自動化程式的登入或密碼更換嘗試；密碼重設時，要在重新確認使用者身分後，發送一次性且具時效性的符記。
  • 使用者識別：各等級都要求系統識別及鑑別使用者，並禁止使用者使用共用帳號；高級系統另要求採用多因子鑑別。
  • 鑑別資訊保護：各等級都要遮蔽鑑別過程中的資訊；中級與高級另要求密碼經雜湊或其他適當方式處理後儲存。

附表十沒有規定「複雜度」要包含哪些字元，也沒有規定效期天數。2026 年修正前，效期部分寫的是「強制密碼最短及最長之效期限制」，修正後改為「依機關密碼效期規定變更密碼」；修正說明指出，內部使用者應依機關定義的密碼效期規定「更改密碼或展延密碼」，外部使用者則可依機關規範自行辦理[5]。

上市櫃公司

證交所 2026 年 11 月公布修正的《上市上櫃公司資通安全管控指引》第二十二條（修正前為第二十一條），要求公司建立使用者密碼管理的作業規定，例如預設密碼、密碼長度、密碼複雜度、密碼歷程記錄、密碼最短及最長的效期限制、登入失敗鎖定機制及首次登入變更密碼，並評估在核心資通系統採取多因子鑑別等零信任架構；修正說明表示，這次修正參考了分級辦法防護基準的要求[6]。這條列的是作業規定要涵蓋哪些項目，並沒有規定數值。

和 NIST 衝突時怎麼兼顧

逐項對照，五次鎖定、不可與前三次密碼相同、預設密碼初次登入即變更、雜湊儲存，都和 NIST 相容；NIST 只要求錯誤次數上限不超過 100 次，允許訂得更低[1][3]。真正衝突的有兩點：附表十要求強制最低密碼複雜度，NIST 禁止組成規則；附表十要求依效期變更密碼，NIST 禁止定期強制更換[1][3]。受附表十拘束的機關可以這樣處理：

  • 條文要求的項目要有，不要自行拿掉：系統要能設定複雜度與密碼效期，政策也要寫明，否則稽核時就是缺項。
  • 在條文沒有定義的地方採用 NIST 的做法：附表十沒有定義複雜度內容與效期天數[3]，可以提高最短長度、加上外洩密碼黑名單、允許長密碼與密碼管理器，效期也不必訂得很短；修正說明已明文提到密碼可以「展延」[5]。具體寫法與天數，建議連同依據（NIST 條文、已導入的黑名單與外洩監控）寫進風險評估，事先和稽核單位或主管機關確認。
  • 外部使用者可直接採用 NIST：複雜度與效期、密碼歷程這兩點，對外部使用者機關得自行規範[3]，會員與客戶登入可以照 NIST 的長度與黑名單規則設計。
  • 減少靠密碼登入的系統：複雜度與效期條文的前提是「使用密碼進行驗證時」[3]；系統改接 SSO 並啟用 MFA 或通行金鑰後，需要套用密碼規則的地方就會變少。
  • 做不到的例外走正式程序：個別系統因技術限制等因素顯有困難時，第 11 條訂有經等級提交或核定機關同意、報主管機關備查後免予執行的程序[2]，不要私下略過。
  • 留意產業主管機關的規定：中央目的事業主管機關可以就特定類型資通系統另訂防護基準，報主管機關核定後適用[2]。

不在資安法範圍內的一般企業，附表十並不直接適用，可以直接以 NIST 為準。不過，若承接政府機關或特定非公務機關的系統開發案，附表十要求委託方把各階段的安全需求納入委外契約[3]，這些條文可能就會透過合約落到你身上。

密碼管理器與通行金鑰

個人版、企業版與瀏覽器內建

NIST 指出，研究顯示密碼管理器能提高使用者選用強密碼的機率，內建密碼產生器時效果更明顯[1]。英國國家網路安全中心（NCSC）在密碼管理器採購指南中也表示，密碼管理器並不完美，但整體而言利大於弊[7]。NCSC 把密碼管理器分成資料只存在單一裝置的「裝置型」，以及可跨裝置同步的「雲端同步型」；兩者都可能是獨立軟體，也可能內建在瀏覽器或作業系統中，而雲端同步型還要考慮傳輸過程的安全，以及遠端攻擊者登入管理器帳號的風險[7]。

個人版和企業版的差別在集中管理：共用密碼的權限與存取紀錄、管理者權限的稽核、強制以 MFA 開啟保險庫、工作與個人保險庫隔離，以及完整的使用日誌，都是 NCSC 列出的企業版考量[7]。瀏覽器內建的管理器對個人帳號很方便，但公司帳號若存在員工個人的瀏覽器同步帳號裡，公司難以集中管理，離職時也難以收回。公司帳號應放進公司管理的企業版產品；瀏覽器存密碼的風險與關閉方式，見資訊竊取程式與外洩帳密。

保護保險庫：主密碼加上 MFA

保險庫等於所有帳密的總鑰匙。主密碼要夠長、不與任何服務重複，因為解開保險庫的金鑰通常就是由主密碼衍生；NCSC 建議所有雲端同步型管理器，以及存放特權或敏感帳號密碼的管理器，都要啟用多因素驗證[7]。忘記主密碼時的復原方式也要事先決定，NCSC 提醒復原機制本身可能被濫用來取得密碼[7]。

LastPass 事件的教訓

LastPass 在 2022 年 12 月 22 日的公告中說明，攻擊者利用同年 8 月事件取得的資訊，鎖定另一名員工取得憑證與金鑰，從雲端儲存複製了客戶帳號資料（公司名稱、使用者名稱、帳單地址、電子郵件、電話與 IP 位址）以及客戶保險庫的備份[8]。保險庫中的帳號、密碼、安全筆記與表單資料是加密的，只能用由各使用者主密碼衍生的金鑰解開，但網站網址等資料沒有加密[8]。LastPass 表示，自 2018 年起主密碼至少要 12 字元；主密碼若未符合預設設定，被猜中所需的嘗試次數會大幅減少，應考慮更換保險庫裡存放的網站密碼；並提醒攻擊者可能對用戶發動釣魚、撞庫或其他暴力破解攻擊[8]。2023 年 3 月 1 日的更新進一步說明，攻擊者鎖定一名資深 DevOps 工程師，利用有漏洞的第三方軟體植入惡意程式，取得的資料包括所有客戶保險庫的備份，以及 MFA／聯合登入資料庫的備份[9]。

對企業的教訓有四點：

  • 保險庫備份外洩後，只剩主密碼擋著：加密欄位只能用主密碼衍生的金鑰解開[8]，攻擊者可以離線慢慢猜，登入時的 MFA 在這種情境派不上用場。
  • 未加密的中繼資料也是情資：網址會透露你用了哪些服務，可用來設計針對性的釣魚。選產品時確認哪些欄位有加密，NCSC 也建議考慮網域等欄位是否加密[7]。
  • 握有關鍵權限的人與裝置就是目標：攻擊者鎖定的是一名資深 DevOps 工程師[9]，管理者與工程師的端點和保險庫，都要比照特權帳號保護。
  • 供應商出事時要有輪換順序：先換管理者、財務、雲端主控台等高價值帳號，以及保險庫裡的 API 金鑰與憑證。

選擇時看什麼

不推薦特定產品，以下依 NCSC 指南整理評估項目[7]：

  • 靜態資料以可靠的演算法加密，解密金鑰只有使用者持有，連服務商都拿不到；
  • 匯出功能受到保護，管理者可以停用或稽核；
  • 廠商回應漏洞的速度與揭露政策，以及更新方式能否配合公司的修補流程；
  • 自動填入只對儲存時的網站提供密碼，密碼產生器能配合各系統的規則；
  • 支援公司使用的所有作業系統與瀏覽器；
  • 企業版的管理者不能檢視或使用個人密碼，管理者的操作留有稽核紀錄。

通行金鑰：逐步離開密碼

FIDO 聯盟把通行金鑰定義為以 FIDO 標準為基礎、用來取代密碼的登入憑證；它採用公開金鑰密碼學，使用者和服務之間沒有共同持有的祕密，因此永遠夠強，也能抗釣魚[10]。通行金鑰可以在使用者的裝置間同步，也可以綁定在單一裝置；建立與管理通行金鑰的「提供者」，可以是作業系統、瀏覽器，也可以是第三方密碼管理器[10]。換句話說，挑選密碼管理器時，可以一併確認它是否支援存放通行金鑰。同步與裝置綁定的取捨、管理者帳號該用哪一種，以及帳號復原的設計，見多因素驗證導入指南。

共用帳號與服務帳號

附表十要求資通系統識別及鑑別使用者，並禁止使用者使用共用帳號[3]；NCSC 也不建議在個人之間共用密碼[7]。能拆成個人帳號加上權限委派的，就先拆；暫時拆不掉的，例如設備唯一的管理帳號或緊急用的破窗帳號，至少要做到：

  • 存放在企業密碼管理器的共用保險庫：不要放在試算表、聊天群組或便利貼上；由指定的人控制誰能存取，並記錄誰在何時取用[7]。
  • 人員異動或有外洩跡象就更換：離職、調職或專案結束時更換密碼，企業密碼管理器能讓新密碼自動同步給仍有權限的人[7]；有外洩跡象則立即更換，和 NIST 對個人密碼的要求一致[1]。
  • 列冊管理：記錄每個共用帳號的用途、負責人與存放位置，定期檢討能否拆成個人帳號。

服務帳號與程式使用的祕密（資料庫連線密碼、API 金鑰、憑證）不是給人記的密碼，管理方式不同。OWASP 的祕密管理指引建議[11]：

  • 集中並標準化祕密管理方案，不要把祕密寫死在原始碼或設定檔中，並在提交程式碼前就偵測祕密；
  • 盡量自動輪換，讓被偷的憑證只在短時間內有效，能用動態或短效祕密的就用；
  • 稽核誰在何時存取了哪個祕密，並對異常存取告警；
  • 祕密外洩時立即撤銷、換發新值，並從程式碼與日誌中刪除。

所以「人的密碼不定期換、機器的祕密定期換」並不矛盾：機器祕密由系統自動產生與輪換，沒有人需要記住它。Windows 網域的服務帳號可以改用群組受管理的服務帳戶（gMSA），由 Windows 代為管理密碼，不必由管理者手動更換[12]；網域管理員與本機管理員帳號的管理，見 Active Directory 特權帳號。

密碼政策大綱範例

以下大綱可以直接改寫成公司的密碼管理規定。寫明「受附表十拘束者」的部分，適用於須執行附表十的機關；其他企業可以直接採用 NIST 的版本。

  • 適用範圍：所有員工、約聘人員與委外廠商的帳號，以及所有以密碼登入的系統；會員與客戶帳號另訂。
  • 長度：只靠密碼登入的帳號至少 15 字元，搭配 MFA 的帳號至少 8 字元；至少允許 64 字元，接受空白與所有可列印字元，鼓勵使用由多個單字組成的密碼片語[1]。
  • 組成規則：不強制混用字元類型，改以黑名單把關；受附表十拘束者，在規定中寫明「最低複雜度」的具體內容，並事先與稽核單位確認[3]。
  • 黑名單：設定與變更密碼時，比對外洩密碼、字典單字，以及服務或公司名稱、帳號名稱與其變形，拒絕時說明原因[1]。
  • 更換時機：不定期強制更換，發現外洩或遭盜用跡象時立即強制更換[1]；受附表十拘束者，依機關自訂的效期規定變更或展延[5]。
  • 密碼歷程：變更時不得與前三次使用過的密碼相同[3]。
  • 錯誤鎖定：受附表十拘束者，連續失敗五次後至少鎖定十五分鐘[3]；其他系統的上限不超過 100 次，並可搭配逐次拉長的等待時間[1]。
  • 預設密碼：以預設密碼初次登入後立即變更[3]。
  • 提示與輸入：不提供密碼提示、不使用知識型安全提問；允許貼上、自動填入與密碼管理器[1]。
  • 儲存與傳輸：密碼加鹽並以密碼雜湊機制儲存，驗證資訊不以明文傳輸[1][3]。
  • 重設流程：重新確認身分後，才發送一次性且具時效性的重設符記，例如重設連結或代碼[3]。
  • 密碼管理器：使用公司指定的企業版產品，保險庫必須啟用 MFA，主密碼不與其他服務重複，工作與個人保險庫分開[7]。
  • MFA：所有對外登入入口與特權帳號強制 MFA，管理者優先使用抗釣魚 MFA，細節依多因素驗證導入指南。
  • 共用與服務帳號：原則禁止共用帳號，例外須列冊並存放於共用保險庫；服務帳號的祕密集中管理、自動輪換、不得寫入原始碼[11]。

行動清單

  • 確認公司適用哪些規範：是否為資安法納管的機關及其責任等級、是否為上市櫃公司，以及客戶合約有沒有引用附表十。
  • 把現行密碼政策逐條對照 NIST SP 800-63B-4 與附表十，標出衝突項目，並把處理方式與依據寫進風險評估。
  • 在自建系統的註冊、變更與重設密碼流程加入外洩密碼比對，並確認現有身分平台是否提供禁用密碼功能。
  • 檢查各系統是否允許至少 64 字元、空白與貼上，移除密碼提示與安全提問。
  • 選定企業版密碼管理器，強制以 MFA 開啟保險庫，並建立到職與離職時的保險庫交接程序。
  • 盤點共用帳號與服務帳號：能拆的拆成個人帳號，其餘移入共用保險庫或祕密管理系統，並寫下輪換時機。
  • 從管理者與高價值帳號開始導入通行金鑰或硬體安全金鑰，逐步減少靠密碼登入的系統。
  • 需要外部協助檢查帳號與驗證設定時，可參考資安健診服務。