密碼雜湊是當單向數學函式轉換您的密碼時所產生的固定長度字串,而產生它的第一個實際步驟,是建立一個值得進行雜湊的長且隨機的密碼。密碼產生器是最快速、最安全的做法,因為它會從密碼學安全的隨機數產生器中抽取字元,並提供雜湊演算法(例如 bcrypt、Argon2 或 PBKDF2)後續會處理的原始輸入。您可以在瀏覽器中使用 密碼產生器 來產生一個強大、可立即雜湊的密碼,複製結果,然後將它輸入到您的應用程式、框架或主機控制面板所使用的任何雜湊流程中。內容不會上傳,也不會被記錄,唯一的輸出就是您決定保留的密碼字串。
大多數讀者會接觸到這個主題,不外乎以下三個原因之一:正在為 Flask、PHP、ASP.NET 或 Node.js 串接使用者帳號的開發人員,需要一組強大的測試密碼;聽過「雜湊密碼」比較安全、想要了解其實際意義的安全意識使用者;或是正在評估是否該信任線上產生器的人。這三種人都能從同一個答案中受益,那就是使用以長度為優先、本機產生的密碼,再讓您真正的系統執行雜湊。
「密碼雜湊」的真正含義
當系統儲存密碼雜湊時,它儲存的不是您的密碼,而是單向函式的輸出。這個單向函式會接收您的密碼以及一個稱為 salt 的隨機值,並產生一個固定長度的字串。下次您登入時,系統會對您輸入的內容執行相同的函式,然後比較輸出結果。即使攻擊者竊取了資料庫,他們得到的也只是雜湊值而非密碼,而且當演算法與參數選擇得當時,反轉這些雜湊值在運算上是極為昂貴的。
關鍵的洞察在於:雜湊只有在輸入夠強時才能保護您。使用世界上最好的演算法來雜湊「password123」,得到的仍然是一個可輕易猜測之字串的雜湊值。使用同一個演算法來雜湊一個 20 字元的隨機密碼,即使雜湊值落入攻擊者手中,也無法實際猜出來。
這正是密碼產生器可以發揮作用的地方。它的工作不是進行雜湊,因為那是您的應用程式或平台的責任。它的工作是產生隨機、高熵的輸入,讓雜湊演算法去保護它。
為什麼長度勝過字元多樣性
密碼強度是以熵(entropy)來衡量,以位元表示。每一個額外的字元,大致會將可能的密碼數量乘以字元池的大小。從大小寫字母、數字和符號組成的字元集中取出的 12 字元密碼,比一個包含您能想到的所有字元類別、卻只有 8 字元的密碼具有更高的熵,因為長度是以指數方式擴展,而多樣性則是線性擴展。
NIST 關於數位身分的指南(以 SP 800-63B 發布)建議人工選擇的密碼最少 8 個字元,並鼓勵對隨機產生的密碼使用更長的長度。對於用於雜湊和儲存的機器產生密碼,16 個字元是合理的預設值,20 到 32 個字元在系統或密碼管理工具能順利處理長度的情況下會更好。
密碼產生器會顯示即時的熵估計值,讓您親眼看到這個原則的運作。將長度滑桿從 8 拉到 16,觀看位元數攀升;關閉某個字元類別,觀看位元數下降。這是一種快速、直覺的方式,讓您感受數學是如何運作的。
使用密碼產生器產生密碼雜湊輸入
- 在瀏覽器中開啟 密碼產生器 工具。這個頁面完全在您的裝置上執行,所以一旦載入完成,您就可以離線使用。
- 使用滑桿或數字框設定密碼長度。從 16 開始作為強力的預設值,如果將要雜湊該密碼的服務接受更長的字串,則可以將其推到 20 或更高。
- 切換您想要包含的字元類型:大寫字母、小寫字母、數字和符號。保留全部四種啟用會為每個字元產生最高的熵,但您可以停用任何類別以符合特定網站的規則。
- 選擇性地啟用排除容易混淆字元(例如 0、O、1、l 和 I)的選項。當密碼將被大聲朗讀、抄寫下來,或在那些字元看起來一模一樣的手機上輸入時,這非常有用。
- 查看螢幕上顯示的強度計和熵估計值。在個人用途上,大約 80 位元以上就算強;在保護敏感資料的帳號上,超過 100 位元則是極佳。
- 按一下「複製」將密碼放入剪貼簿,或者如果第一組不符合您的需求,再按一下「產生」來重新產生一個新值。每次點擊都會從安全 RNG 產生一個新的獨立輸出。
- 將產生的密碼貼到任何正在進行雜湊的系統的輸入欄位中,無論是註冊表單、CLI 工具,還是程式碼中的測試資料。
根據使用情境選擇字元類別
字元類別的存在是為了擴展攻擊者必須涵蓋的搜尋空間,但它們也施加了並非每個系統都遵守的規則。有些舊系統會拒絕符號,有些會在 14 個字元處截斷,有些則強制定期重設密碼,這些都與長隨機密碼相衝突。
如何使用 Google 和本機工具產生安全的密碼 指南詳細說明了基於瀏覽器的產生器與其他來源之間的權衡取捨。對於大多數現代網頁應用程式來說,以 16 個字元以上的長度產生所有四個類別是最佳平衡點。如果某個服務拒絕符號,請提高長度來補償,因為每增加一個字元的長度所恢復的熵,比缺少一個符號類別所損失的熵還要多。
在 Chrome 本機產生強密碼(不進行同步) 指南是很好的延伸閱讀,如果您想了解為什麼在瀏覽器中執行且不將資料傳送出去的工具,比需要帳號或雲端同步的工具更安全。本站的密碼產生器遵循相同的原則:隨機位元組永遠不會離開這個頁面。
產生的密碼該如何處理
| 情境 | 建議長度 | 字元類別 | 下一步 |
|---|---|---|---|
| 在現代網頁應用程式上註冊新使用者 | 16 或以上 | 全部四種 | 提交到網站的註冊表單;伺服器會進行雜湊並儲存 |
| 開發人員測試 Flask、PHP 或 ASP.NET 的雜湊函式 | 20 或以上 | 全部四種 | 傳遞給 generate_password_hash 或對等的函式以進行單元測試 |
| 拒絕符號或限制長度的舊系統 | 系統接受的最長長度 | 三個類別(去掉符號) | 以長度而非符號來補償 |
| 需要大聲朗讀或抄寫下來的密碼 | 12 到 14 | 三個類別,排除容易混淆的字元 | 作為備份儲存在密碼管理工具中 |
「下一步」這一欄才是真正進行雜湊的地方,而且它幾乎總是存在於您的應用程式碼中,而不是在產生器中。在 Flask 中,werkzeug.security.generate_password_hash 函式接收產生的字串,並回傳一個準備好存入資料庫的加 salt 雜湊值。在 PHP 中,password_hash 使用 bcrypt 或 Argon2 完成同樣的工作。在 ASP.NET Core Identity 中,當您設定密碼屬性時,框架會在儲存時進行雜湊。除了強大的輸入字串(也就是您剛剛複製的內容)之外,這些都不需要從產生器取得任何東西。
搭配強密碼的良好安全習慣
剛產生且強度高的密碼,只是健康安全設定中的一層。將它與信譽良好的密碼管理工具搭配使用,這樣您就不必記住那串長長的隨機字串,並在每個提供雙因素驗證的帳號上啟用該功能。如果您是開發人員,請確保您的雜湊函式設定了目前的工作因子:bcrypt 成本至少為 12、根據您的硬體調整的 Argon2 參數,以及每個使用者唯一的 salt(這是現代函式庫的預設行為)。
避免將同一組產生的密碼重複用於多個網站。產生器只要點擊一下就能產生一組新的密碼,為每個服務複製不同字串所花費的額外心力,遠低於一次漏洞連環波及多個帳號的代價。在極少數必須手動輸入密碼的情況下,請使用「排除容易混淆字元」選項,這樣您就不必花十分鐘懷疑那到底是大寫 I 還是小寫 l。
常見的誤解
值得釐清幾個常見的混淆。密碼產生器不會產生雜湊值,因為雜湊值是您無法複製回登入表單的東西;它產生的是純文字密碼,接著由雜湊演算法進行轉換。如果將產生器的輸出當作已經是雜湊值一樣存入資料庫,將會是嚴重的錯誤,因為任何讀取資料庫的人都會看到可用的密碼,而不是單向字串。
另一個誤解是:長度越長總是越難記住。使用密碼管理工具時,您不需要記住任何東西,因此長度就成為純粹的安全優勢。長度會成為問題的唯一情況,是當有缺陷的系統默默截斷輸入時,這就是為什麼確認服務的政策很重要。如果網站允許 64 個字元,就產生 32 個;如果只允許 12 個,就產生 12 個、接受較低的熵,並考慮換一個網站。
最後,在網路上「隨機」並不總是代表密碼學上安全。有些自製工具使用 JavaScript 較舊的 Math.random,它的速度很快但可預測。本站的密碼產生器使用瀏覽器的安全 RNG,這也是嚴謹的安全函式庫所依賴的同一種基礎機制,因此它產生的字串適合用於任何您在意的帳號。
如果您正在權衡各種選項,用淺白英語解說二進位對文字的轉換原理 對此有詳細說明。
如果您正在權衡各種選項,如何計算檢查碼:XOR-8 與 Modbus LRC 對此有詳細說明。