一份好的密碼政策，應該能讓帳戶更難遭到入侵，同時又不會讓安全行為變得不必要地困難。最好的政策是明確、實用，並符合人們實際工作的方式。這樣的政策會鼓勵使用長且唯一的密碼、支援密碼管理器、適當地要求多重身分驗證（MFA），並移除那些會讓使用者出現可預期行為的過時規則。
\n本文將說明現代密碼政策的該做與不該做的事、哪些應避開、最佳實踐，以及您可以調整後帶回自己組織直接使用的範本。
\n密碼政策是一套規範，定義密碼應如何建立、儲存、使用、共用、變更與保護。其適用於員工、承包商、管理員、服務帳戶，有時甚至涵蓋客戶，因視系統範疇而異。
\n一份好的密碼政策應該解答這些實際問題：
\n目標不是制定最複雜的規則，而是要真正降低風險。
\n密碼長度是抵禦猜測及暴力破解攻擊的最佳方式之一。統一全組織的最短長度需求，通常比針對一般使用者、管理員或特殊帳戶訂不同規則更容易理解與執行。實際的作法是：所有人工帳戶至少需 16 個字元。如用戶依賴密碼管理器或隨機產生的通關密語，長度越長越好。
\n密碼建議可遠超於最小長度，避免設定 16 或 20 這種過低的最大字數限制。最小至少開放至 64 字元，許多系統甚至可以安全支援更長。
\n若使用通關密語（多個單詞組成），只要夠長且非引用常見名言、歌詞、企業名稱或可預測的片語即可。例如，由幾個隨機單詞組成的通關密語，通常比強行替換字母而成的短密碼更安全。
\n每個帳戶都應有獨特的密碼。密碼重用正是某系統遭入侵後，造成其他帳戶被盜用的主因。使用密碼管理器可以讓獨一無二的密碼變得實用，因為使用者不用記住所有憑證。
\n政策應明確允許並鼓勵使用核可的密碼管理器。允許用戶將密碼貼上登入欄位、使用自動填充並產生隨機密碼。封鎖貼上功能看似安全，其實常會令用戶放棄強密碼管理器的使用。
\n若密碼出現在已知外洩清單、常用密碼清單或自訂禁止清單內，則應直接拒絕。這比強迫用戶增加一個大寫、一個數字、一個符號更有意義。
\n多重身分驗證應在所有技術可行處啟用，尤其針對管理員、遠端訪問、雲端服務、電子郵件、密碼管理器、財務系統等高價值目標。MFA 無法取代強密碼，但能降低憑證被盜的影響。
\n建議優先採用抗釣魚的 MFA 方式，如 Passkeys（無密碼驗證）、硬體安全金鑰或平台驗證器。App 類認證器通常優於 SMS 簡訊。若技術可行絕不可用 SMS 簡訊型 MFA，因手機號碼可能遭攔截、SIM 卡調包、轉號、或透過帳戶恢復流程被濫用。
\n這不是理論問題。2018 年 Reddit 就曾公告攻擊者攔截 SMS 二步驟驗證並入侵內部系統：https://www.reddit.com/r/announcements/comments/93qnm5/wehadasecurityincidenthereswhatyouneed_to/。2021 年 Coinbase 也曾報告攻擊者利用憑證及 SMS 帳戶恢復流程弱點，竊取至少 6,000 名客戶的加密幣：https://www.reuters.com/technology/coinbase-says-hackers-stole-cryptocurrency-least-6000-customers-2021-10-01/。
\n只要有發現或合理懷疑密碼被盜用，就應該立即變更。例如：釣魚、用戶裝置感染惡意程式、外洩事件憑證暴露、可疑登入行為、或不小心洩露密碼。
\n若能採用個人帳號就避免共用密碼。的確非共用不可時，必須存放於核可的密碼管理器、僅限授權者存取，並在可行時對共用行為進行紀錄。
\n密碼重置往往是帳戶安全的最薄弱一環。應驗證身份、限時失效重設連結、使用一次性代碼，並在密碼更換時通知用戶。
\n強制 30、60、90 天換密碼，只會讓密碼變得更弱。用戶傾向於做些小且可預期的修改，例如加個數字或變更季節。NIST 的數位身份指引已經捨棄例行週期性密碼更換，僅規定出現被盜疑慮時才強制更換。請參閱 3.1.1.2 節：https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver。僅於懷疑遭竊、職務異動、帳戶恢復、或密碼不符政策時要求修改。
\n強制「必須包含大寫、小寫、數字、符號」這類規則，不代表就安全。像 Password1! 就滿足多數複雜性要求，實際上則很弱。應以長度、唯一性、隨機性與外洩篩查為優先。
封鎖貼上，讓密碼管理器變難用，只會讓用戶改用較短、易輸入的密碼。除非有明確紀錄的安全理由，否則應允許貼上與自動填充。
\n提示語常常洩漏太多資訊。如果用戶能靠提示回憶，攻擊者通常也能猜出。應改用更安全的重設流程。
\n絕不可在系統內使用明文或可逆加密儲存密碼。密碼應交由現代、安全且慢速、加鹽的演算法如 Argon2id、bcrypt、scrypt 或 PBKDF2 去雜湊。按實際系統能力與合規需求選擇。
\n通用雜湊演算法如 MD5、SHA-1、SHA-256 或 SHA-512，不應單獨作為密碼雜湊用途，因它們執行太快，資料庫外洩時更利於暴力破解。詳細可參見我們的密碼雜湊演進介紹。
\n密碼不得經由郵件、聊天、工單、文件、或螢幕截圖傳送。請用密碼管理器的安全共用功能與存取控管。
\n密碼不能包含姓名、生日、公司名、鍵盤規律、重複字元或常見替換（如 @ 代表 a、0 代表 o）。攻擊者會優先測試這些模式。
要求必須易於理解：
\n管理員、服務帳號、正式環境存取，應有更嚴格控制。要求更強的密碼、MFA、存取限制、監控、權限異動即時重設。
\n再強的密碼也彌補不了過多的授權。只允許用戶存取其角色所需的系統與資料。
\n及時偵測異常登入、不可思議的出差地點、重複失敗登入、從新國家嘗試登入、以及不尋常上班時間。密碼政策須搭配監控與資安事件處理。
\n訓練聚焦於密碼重用、釣魚、假登入頁、MFA 疲勞攻擊、安全共用，以及懷疑憑證外洩時如何回報。切勿責怪用戶，重點是讓安全行為成為易事。
\n密碼政策要易於理解。若太長、太模糊或太嚴厲，人們只會想方設法繞過。最好的政策是確實可落實、能執行的政策。
\n可將下列範本視為起點，請根據貴組織、系統、風險等級與法律要求調整括弧內的內容。
\n密碼政策\n\n版本： [1.0]\n負責單位： [資安／資訊部]\n施行日期： [YYYY-MM-DD]\n檢討週期： [每12個月]\n\n1. 目的\n\n本政策定義[組織名稱]內建立、使用、儲存、共用與變更密碼之要求。目的是降低未授權存取、憑證竊取、帳戶被盜用與資料遺失之風險。\n\n2. 適用範圍\n\n本政策適用於所有員工、承包商、臨時人員、服務商及其它存取[組織名稱]系統、應用、網路、雲端服務或資料之使用者。\n\n本政策適用於一般用戶帳戶、特權帳戶、服務帳戶、共用帳戶及任何採密碼驗證的系統。\n\n3. 密碼建立要求\n\n所有密碼必須符合以下規定：\n\n- 人工帳戶密碼長度不得少於16字元。\n- 密碼必須唯一，且不得重複用於工作與個人帳戶。\n- 密碼不得包含姓名、用戶名、公司名、生日、鍵盤規律、重複字元或其他易猜資訊。\n- 密碼不得以常見片語、名言、歌詞或可預測替換為基礎。\n- 密碼不得出現在已知外洩或常用密碼清單中。\n- 密碼可包含空格、符號、數字、大寫及小寫字母。\n- 通關密語只要夠長且唯一，亦可用，但不得基於可預測或公開片語。\n\n4. 密碼管理器\n\n[組織名稱]要求或強烈建議使用核可的密碼管理器建立、儲存、共用密碼。\n\n可使用管理器內的密碼產生、自動填寫與複製貼上功能。不得將密碼儲存在瀏覽器、試算表、文件、記事本App、電子郵件、聊天訊息、截圖或未經核可的工具中。\n\n5. 多重身分驗證\n\n多重身分驗證（MFA）應於所有技術可行處啟用，包括但不限於：\n\n- 電子郵件帳戶\n- 遠端存取系統\n- 密碼管理器帳戶\n- 雲端服務\n- 管理員帳戶\n- 財務、人資及其它高風險系統\n- 所有標記為[機密／關鍵]之系統\n\n可用時必須使用抗釣魚MFA（如Passkeys、硬體安全金鑰、平台驗證器）。認證App優於SMS簡訊。若有更安全MFA方式，嚴禁僅用SMS，僅在無更高強度MFA可用時例外。\n\n6. 密碼更換\n\n密碼必須於下列情形下立即更改：\n\n- 密碼已知或懷疑外洩。\n- 用戶於可疑釣魚網站輸入密碼。\n- 密碼被分享給未授權人士。\n- 檢測到用戶裝置感染惡意程式或未授權存取。\n- 密碼出現在已知外洩資料中。\n- 特權使用者職務或身份變動。\n- 資訊／資安部門要求用戶更改密碼時。\n\n例行性密碼週期到期不得列為必須條件，除非受法律、合約或系統限制所約束。密碼不得僅以可預測的小幅變更方式更改。\n\n7. 密碼共用\n\n不得透過郵件、聊天、工單、文件、截圖、電話、口頭訊息共用密碼。\n\n若無法技術上分別帳戶，或經[資安／資訊部門]明確核可，方可使用共用帳號。共用憑證必須由核可之密碼管理器妥善保存並僅授權存取對象。\n\n8. 特權帳戶\n\n特權帳戶密碼不得與一般用戶帳號共用。特權帳號必須盡可能啟用多重身分驗證（MFA）並定期審查。\n\n管理員離職、職務異動、不再需要權限或發現有疑慮時，必須即時更換特權密碼。\n\n9. 服務帳戶及應用憑證\n\n服務帳戶密碼、API Key、Token及應用程式憑證需儲存在經核可之秘密管理系統或密碼管理器。\n\n不得將服務帳戶憑證嵌入於原始碼、設定檔、映像檔、文件或腳本內，除非有經核可的秘密管理防護流程。\n\n10. 密碼重設與帳戶恢復\n\n密碼重設過程必須驗證使用者身份。重設連結與臨時密碼需為一次性使用、限時失效，並採核可管道傳送。\n\n密碼重設或變更時，必須通知該使用者。首次登入時，臨時密碼必須強制變更。\n\n11. 技術控管\n\n系統如儲存或處理密碼，須：\n\n- 絕不儲存明文密碼。\n- 使用經核可且加鹽之雜湊法儲存密碼（PBKDF2、scrypt、bcrypt或Argon2）。\n- 不得僅用MD5、SHA-1、SHA-256、SHA-512或其他太快的雜湊算法。\n- 為驗證端點設置嘗試次數限制等防護措施。\n- 拒絕常見、弱、及已知洩漏的密碼。\n- 允許用戶複製貼上密碼以利密碼管理器使用。\n- 支援合理密碼長度，原則上至少64字元。\n- 記錄所有影響安全之認證事件。\n\n12. 懷疑外洩應即時回報\n\n如懷疑密碼外洩、釣魚、異常登入驗證、未本人發起之MFA提示、或他人誤洩密碼時，用戶應立即向[資安／資訊單位聯絡資訊]回報。\n\n13. 例外處理\n\n例外必須有紀錄、風險評估、設限期限、並經[資安／資訊部門主管]核可。必要時應採補充控管措施。\n\n14. 違規處理\n\n未依本政策辦理，可能導致帳號權限移除、資安訓練、懲戒處分，或依[組織名稱]規定及相關法律執行後續處理。\n\n15. 政策審查\n\n本政策應每年至少審查一次，或因系統、威脅、法律、營運重大變更時立刻調整。\n強化密碼政策的目的不是讓人痛苦，而是要根除危險習慣、支援密碼管理器、應用 MFA、在憑證外洩時能迅速應對。請保持政策貼近實務、確實可執行，並聚焦於釣魚、憑證填塞、密碼重用、帳戶淪陷等現實威脅。
","frontmatter":{"date":"May 07, 2026","slug":"password-policy-dos-donts-best-practices","title":"密碼政策：該做與不該做的事、最佳實踐與可複製範本","description":"學習現代密碼政策應有的要求、哪些過時規則需要避免，並複製適用於您組織的實用範本。","author":"Sascha Pfeiffer","featuredImage":null}}},"pageContext":{"slug":"password-policy-dos-donts-best-practices","lang":"zh-Hant","langPathPrefix":"/zh-Hant"}},"staticQueryHashes":["2149092236","3128451518","3192060438"]}