密碼產生器的隨機性最終來自熵源，也就是亂數的原始來源；長度與字元集只決定猜測空間的形狀，來源本身可預測時，再長也只是降低表面難度。核心判斷只有一句：先問這組密碼是在哪一層產生、依賴誰提供的亂數，再看介面能調哪些選項。本篇以 密碼產生器 這類線上工具為例，拆成硬體、作業系統、瀏覽器、頁面環境四層做對照，並給出依用途選擇的順序。
熵源決定了什麼？先講結論：長度與字元集補不回來
順序反了，就會把精力花在補不了根本問題的地方。例如在一個來源不明的網頁上把長度調到 64 位、勾滿所有字元集，猜測空間看似龐大，但若產生邏輯由遠端控制或種子可預測，輸出仍可能落在可重現的範圍內。反過來說，建立在作業系統密碼學安全亂數之上的工具，即使只用預設的 16 位、基本字元集，來源本身也站得住。
這篇適合兩種讀者：想確認工具是否可靠的開發人員，以及要替主密碼或重要帳號把關的使用者。只想偶爾換一組蝦皮、momo 或 PChome 帳號密碼的人，把下方的判斷當檢查清單即可，不必逐項深究。
四類熵源各自有什麼風險？硬體、作業系統、瀏覽器、頁面環境
硬體熵源（處理器亂數指令、晶片上的隨機數產生器）提供最底層的物理亂度，通常由作業系統彙整後再輸出；缺點是開發者與使用者多半只能透過系統間接取得，難以自行審計。作業系統的密碼學安全亂數產生器（CSPRNG）會混入多個熵源並定期重新播种，是多數桌面與行動裝置環境的標準來源，公開文件完整、可審計程度高，屬最常見的可靠層級。
瀏覽器提供的亂數 API 屬於應用層，實際仍仰賴底層作業系統；風險點不在 API 本身，而在頁面是否真的呼叫它，而非以時間、滑鼠軌跡、固定種子等可預測方式湊數。頁面與擴充環境是最弱的一層：若產生邏輯在遠端伺服器執行、程式碼可被替換或擴充可讀取頁面內容，即使底層是 CSPRNG，你仍無法確認這組密碼從頭到尾經過了誰。
|
維度
|
硬體熵源
|
作業系統 CSPRNG
|
瀏覽器亂數 API
|
頁面／擴充環境
|
|
可預測性風險
|
低，來自物理亂度
|
低至中，取決於混入熵與重新播种
|
中，仍仰賴底層系統
|
高，可能以時間、固定種子湊數
|
|
可審計程度
|
低，多半只能間接取得
|
高，文件完整
|
中，API 行為可查、實作難驗
|
低至中，程式碼可替換或遠端執行
|
|
使用者可見度
|
幾乎不可見
|
可由系統間接觀察
|
開發者工具可確認是否呼叫
|
可檢查是否本機產生與擴充權限
|
|
一句話評價
|
最底層的亂度來源
|
桌機與手機的標準可靠層級
|
可靠與否取決於頁面實作
|
最依賴對提供方的信任
|
四層的差異不在「有沒有亂數」，而在可預測性風險與可審計程度：越接近硬體與作業系統越難被外部預測，越接近頁面與第三方環境越依賴信任。
介面上看不到熵源，一般使用者能驗證到什麼程度？
多數使用者無法從介面判斷實際熵源，只能靠兩件事評估：工具是否公開說明生成位置（本機或遠端）與所依賴的亂數來源，以及提供方本身是否可信、程式碼是否可查。像 隨機密碼產生器 這類工具，若對熵源與生成位置語焉不詳，只強調「高強度」「24 位」等標語，屬於無法驗證的宣稱——標語不是熵源證據。
開發者可用較明確的檢核方式：確認是否使用作業系統或瀏覽器提供的密碼學安全亂數 API（例如 crypto.getRandomValues）、產生邏輯是否在可檢視的環境執行、是否排除以時間戳或固定種子當隨機來源；挑 密碼產生器chrome 這類擴充時，則多看一項：擴充取得了哪些頁面權限。
兩個常見誤判也要留意。其一，密碼產生器 多組 一次產生多組，只能看表面多樣性，無法證明熵源品質；其二，工具是否離線只影響傳輸風險，不等於熵源可靠。
該依什麼條件選？適合誰、不適合誰與局限
高敏感用途（密碼管理器主密碼、金鑰類憑證、公司系統帳密）：優先選擇能說明或可驗證熵源、且生成在本機可信環境的工具，來源不明或生成位置不清的工具不適合這類用途。一般註冊與帳號換密碼：作業系統或瀏覽器內建、或知名開源線上工具通常已足夠，重點在跨站不重複使用與妥善保存，不必追求硬體級熵源。不推薦的組合包括：把遠端執行、程式碼不公開的網頁工具用在主密碼，或在共用電腦、雲端同步的環境產生高敏感密碼。
局限要先講清楚：本篇只提供熵源分層的通用判斷原則，不等同資安稽核或法規符合性評估；企業、金融與公務系統另有指定密碼政策時，以該系統規範為準。任何熵源都只能決定產生這一步，整體安全仍取決於保存方式、是否重複使用與雙因素認證是否啟用。想知道更多產生方式的差異，可再看這篇 亂數密碼產生器 說明。