.htpasswd 檔案生成器
在瀏覽器中安全生成用於 Apache 和 Nginx Basic 認證的 .htpasswd 檔案。支援 bcrypt、APR1-MD5 和 SHA-1。密碼不會發送到伺服器。
什麼是 htpasswd 檔案
htpasswd 檔案是一種純文字檔案，每一行儲存一筆 使用者名稱:雜湊密碼 資料，用於 Apache 與 Nginx 的 Basic 驗證。一般會透過伺服器上的 htpasswd 指令產生，但許多環境難以直接存取命令列或伺服器，能在瀏覽器中直接產生相同格式檔案的工具便顯得相當實用。
本工具會依照你選擇的 bcrypt、APR1-MD5 或 SHA-1 演算法將密碼雜湊化，產生 使用者名稱:雜湊值 格式的一行內容。所有雜湊運算皆透過 JavaScript 在瀏覽器端完成，明碼密碼不會經由網路傳送。產生的檔案應放置於伺服器 DocumentRoot 之外，並透過 AuthUserFile 指令引用其路徑。
.htpasswd 檔案產生步驟
- 新增使用者列 依需求點擊「新增使用者」按鈕，每次新增一列，一列對應一位使用者。
- 輸入使用者名稱與密碼 在每一列輸入使用者名稱與密碼，可利用顯示/隱藏切換來核對輸入內容。
- 選擇演算法與成本值 為每一列選擇 bcrypt、APR1-MD5 或 SHA-1；選擇 bcrypt 時還須調整成本值（運算強度）。
- 點擊生成 點擊「生成」按鈕後會立即執行雜湊運算，下方會顯示 .htpasswd 檔案內容預覽。
- 複製或下載 將結果複製到剪貼簿，或下載為檔案後部署到伺服器上。
用好本工具的小技巧
- 推薦使用 bcrypt：目前最安全的演算法，適用於 Apache 2.4+ 和 Nginx。成本值越高，雜湊計算越慢，抵禦暴力破解的能力越強（通常推薦值為 10）。
- APR1-MD5（
$apr1$）適用於需要相容 Apache 2.2 或更舊版本的場景，幾乎所有 Apache 和 Nginx 版本都支援。 - SHA-1（
{SHA}）抗碰撞性較弱，不推薦使用。僅在必須向後相容的舊環境中使用。 - 建議將 .htpasswd 檔案放置在 Web 根目錄（
DocumentRoot）之外，防止被直接訪問。 - 務必配合 HTTPS 使用。Basic 認證的憑據僅經過 Base64 編碼，未加密，在 HTTP 連線下相當於明文傳輸。
應用情境
保護上線前的測試環境
透過簡單的 Basic 驗證，避免搜尋引擎與第三方存取尚未正式公開的測試站台。
限制未內建登入功能的管理後台
為內部管理面板、維運工具等尚未自行實作登入功能的頁面加上存取限制。
與 IP 限制搭配形成雙重防護
當僅靠 IP 白名單難以因應外部協作需求時，疊加 Basic 驗證形成雙重防線。
僅保護特定 API 端點
透過 location 或 Directory 指令，只針對特定路徑而非整個網站啟用驗證。
為既有服務新增使用者
在運作中的服務新增授權使用者時，只需產生要追加的列，附加到既有檔案末尾即可。
詞彙表
- Basic 驗證
- HTTP 標準驗證方式之一，將使用者名稱與密碼進行 Base64 編碼後隨每次請求送出，由伺服器端進行驗證。
- bcrypt
- 一種帶鹽值的密碼雜湊演算法，可調整成本係數，即使硬體效能提升也能維持較慢的運算速度，是目前建議採用的演算法。
- APR1-MD5
- Apache 自訂的 MD5 雜湊格式，雜湊值以
$apr1$開頭，主要為相容舊版 Apache 而保留。 - SHA-1（{SHA}）
- 雜湊值以
{SHA}開頭的格式，不使用鹽值，抗碰撞能力較弱，不建議用於新專案。 - 鹽值（Salt）
- 在雜湊運算前附加到密碼上的隨機字串，使相同密碼每次產生的雜湊值都不同，藉此抵禦彩虹表攻擊。
- DocumentRoot
- Web 伺服器對外公開檔案的根目錄。若將 .htpasswd 放在其中，可能會被瀏覽器直接存取到。
- AuthUserFile
- Apache 設定指令，用於指定 Basic 驗證所使用的 .htpasswd 檔案路徑。
常見問題
.htaccess 或 httpd.conf 中新增以下配置，並將 AuthUserFile 指向生成的 .htpasswd 檔案路徑：AuthType Basic AuthName "Restricted Area" AuthUserFile /etc/apache2/.htpasswd Require valid-user
nginx.conf 或相應的 server 塊中新增：location /admin {
auth_basic "Restricted Area";
auth_basic_user_file /etc/nginx/.htpasswd;
}Nginx 同時支援 bcrypt 和 APR1-MD5。使用者名稱:雜湊值 格式）追加到檔案末尾即可。每行對應一個使用者，空行和以 # 開頭的註釋行會被忽略。
閒話 ― Basic 認證為何歷久不衰
HTTP Basic 認證於 1999 年由 RFC 2617 定義（後更新為 RFC 7617），原理其實極為簡單：將使用者名稱與密碼以 : 拼接，經 Base64 編碼後放入 Authorization 請求頭即可完成身份宣告。誕生至今已有二十多年，它依然是 Web 世界裡最古老、也最廣泛支援的認證方式之一。
也正是這種簡潔性，讓它歷經二十多年依然沿用至今。它常被用於測試環境、內部工具，或與 IP 白名單結合構成雙重防護——只需兩三行配置，無需額外中介軟體或資料庫，可以說是最輕量的訪問控制方案之一。這也是為什麼即便認證技術已經發展出許多更精細的方案，Basic 認證仍然在快速搭建臨時防護時被反覆選用。
當然，它也並非沒有侷限：沒有登出機制（關閉瀏覽器前會話會一直持續），不支援密碼過期管理和多因素認證。因此對於安全要求較高的正式服務，通常還是建議考慮 OAuth 2.0 或 OIDC 等更完善的方案，把 Basic 認證留給那些"快、簡單、臨時"的場景。