隨機數能當密碼嗎？亂數來源、長度與用途要一起看

六位抽籤號碼，不適合直接當長期密碼

六位抽籤號碼，我不建議直接拿來當長期帳號密碼。它不像生日、看不出規律，可能組合仍然有限。就算亂數來源適合安全用途，也補不了長度、秘密保存和帳號驗證的不足。要保護帳號，應依服務限制，用密碼產生器取得足夠長、每個帳號獨立的一串，再安排保存與復原。

例如替社團建立工作帳號，想從隨機數工具取六個數字。這是自擬情境：抽籤只要從指定範圍選結果，帳號密碼卻要面對可能反覆嘗試的人，還得看服務怎麼限制猜測。來源、組合數、是否公開過，都要一起判斷。

若你已把這串數字貼到群組作為演練範例，就不要再把它當成真實密碼。公開範例即使原本隨機產生，也已經失去秘密性。本文不提供任何可直接使用的密碼字串。

六位數有多少組合，要看能否重複和前導零

從000000到999999，共有10⁶，也就是一百萬種。如果第一位不能是0，剩九十萬種；六個數字都不能重複但可含前導零，則是10×9×8×7×6×5＝151,200種。再固定前幾位或加排除規則，範圍還會縮小。「限制更多」不一定讓密碼更難猜。

那為什麼有些服務會用六位驗證碼？它們可以搭配期限、嘗試限制及其他驗證條件，不是只靠這六個字元。長期帳號密碼的使用方式不同，不能看到長度相同，就把兩者當成一樣的保護。要看的仍是整個流程。

長期帳號應依服務允許的條件產生足夠長且獨立的密碼，並妥善保存。不要自行拿六位抽籤號碼取代服務的驗證碼系統。其他工具若有強度提示，也不能用它證明服務端如何儲存密碼。

安全亂數來源，仍要搭配足夠長度

JavaScript 的 Math.random 適合一般模擬等用途，但 MDN 明確說明它不提供密碼學安全的亂數。涉及安全用途應使用適當的 Web Crypto 能力。不能因為連續產生幾次看不出規律，就判定來源適合密碼。

本站隨機數和密碼產生器都用瀏覽器的 crypto.getRandomValues，沒有安全來源可用時，也不會悄悄改成 Math.random。但如果範圍只設1～100，再難預測也只有一百種可能。我會把來源是否合適、結果有多少可能分開看，不因來源用了 Web Crypto，就把任意輸出都當成安全密碼。

密碼產生器還需要按字元集合、長度及限制組成結果。若自己寫程式，也要避免不均勻的映射或錯誤的失敗備援。沒有可用安全來源時，不應悄悄改成較弱來源，卻讓使用者以為品質相同。

符合網站限制後，完成保存與帳號管理

有人會把產生的密碼改成「姓名縮寫＋隨機四碼」，讓自己比較好記；有人在每個網站用同一串，尾端只加網站名稱。這些做法加入可猜的結構或重複使用，不能沿用修改前的組合估計。

遇到網站不收某種符號，我會回產生器調整允許字元，再重新產生。把不喜歡的字元全部改成固定驚嘆號，雖然好記，卻又加上了可猜的規律。要配合的是網站限制，不必順手把結果改成自己熟悉的樣子。

本站密碼產生器提供8～128個字元、字元種類及排除易混淆字元的選擇。產生後檢查服務是否收下完整內容，留意輸入欄位有沒有截斷或拒絕字元。「已產生新密碼」只表示此頁生成成功，不能證明另一個網站已保存整串。

用自己能妥善管理的方式保存新密碼，對應正確網站和帳號，測試登入後再完成交接。每個帳號用不同密碼，避免一處外洩牽連其他服務。若網站支援，再設定適合的多因素驗證及復原方式。

如果是多人工作共用的帳號，我會先看看服務能不能改用個別帳號與權限。把同一串密碼傳給所有人，之後有人離隊，撤銷存取和查核都比較難處理。換成更長的字串也不會解決這件事，還得回到帳號怎麼分配。

回到原來的問題：抽籤輸出能不能拿來保護帳號，得同時看亂數來源、組合空間和保存流程。只知道「這是隨機產生的」，還少了後面這些條件。

• 密碼產生器選擇服務接受的長度與字元，為每個帳號獨立產生結果。
• 產生新密碼之後的保存與復原接續安排保存、正常登入、多因素驗證與可用的復原方式。

參考來源

• MDN：Math.random 的安全限制一般亂數不適用密碼學安全用途。
• MDN：Crypto.getRandomValues提供密碼學用途的亂數來源；不代表任意長度及用途都安全。