Apache、.htaccessで簡単に!Webサイトにパスワード認証をかける方法

Apache / .htaccess

Webサイトを運営していると、一部のページにアクセス制限をかけたい場面が出てきます。例えば、テスト中のサイトや関係者のみが閲覧できるページにパスワードを設定することで、セキュリティを確保することが可能です。本記事では、.htaccessと.htpasswdを使ってサイトに認証を設定する方法をご紹介します。特別な知識は不要ですので、ぜひ参考にしてください!

basic認証

パスワードアルゴリズム:bcrypt(安全) ➝ MD5 ➝ crypt
パスワードの送信形式:Base64(実質平文)
通信時の安全性: ❌ HTTPでは漏洩 / ✅ HTTPSで安全

# パスワード認証の設定
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /絶対パス/.htpasswd
Require valid-user
.htaccess

.htpasswdファイルも用意する。

パスワード生成ツールで、認証用のパスワードを生成し、下記のように記述。

こちらのページからbcryptのパスワードを作成できます。↠Bcrypt ハッシュジェネレーター

id:password
.htpasswd

ダイジェスト認証

パスワードアルゴリズム:MD5
パスワードの送信形式:ハッシュ(MD5)で送信
通信時の安全性: ✅ 平文送信なし(ただしMD5)

.htaccess

# ダイジェスト認証の設定
AuthType Digest
AuthName "Restricted Area"
AuthDigestProvider file
AuthUserFile /path/to/.htpasswd
Require valid-user
.htaccess

ダイジェスト認証では、Username、Realm、Passwordの3つを設定する。RealmはAuthNameと同じにする。

.htpasswd

.htpasswdファイルも用意する。

パスワード生成ツールで、認証用のパスワードを生成し、下記のように記述。
ダイジェスト認証のパスワードを作成できるサイトです。↠サイト

各入力欄に入れる内容

  1. Username (ユーザー名)
    • ダイジェスト認証で使用するユーザー名を入力します。
  2. Realm (認証領域名)
    • ダイジェスト認証で使用する「領域名 (Realm)」を入力します。
    • これは .htaccess ファイルで指定する AuthName と一致させる必要があります。
    • 例: Restricted Area
  3. Password (パスワード)
    • 認証で使用するパスワードを入力します。
    • 例: mypassword(任意の安全なパスワード)。
  4. Confirm Password (パスワードの確認)
    • 再確認のため、上記と同じパスワードを入力します。

入力が終わったらGENERATEを押します。

Paste the following line into your .htdigest file(次の行をファイルに貼り付けます)と書かれたすぐ下に、ダイジェスト認証用の.htpasswdファイルに保存される形式が表示されます。コピーします。

id:AuthName:password
.htpasswd

.htpasswdファイルは、.htaccessと同じ階層でよいです。
.htaccessファイルのAuthUserFileで最終的に場所(パス)は指定します。

Digest認証は廃れた

〜なぜ今はBasic認証 + HTTPSが主流なのか?〜


Webサイトのアクセス制限といえば、Basic認証とDigest認証が代表的な手法です。
Digest認証はかつて、Basic認証の弱点を補う“進化版”として登場しました。
しかし現在、Digest認証はほとんど使われておらず、非推奨の扱いになりつつあります。

セキュリティが中途半端

Digest認証では、ユーザー情報をMD5でハッシュ化して送信します。
一見安全そうですが、MD5は現代の基準では非常に脆弱です。
また、送信されるハッシュ値は一定条件下で再利用されることもあり、完全に安全とは言えません

ブラウザやアプリとの互換性が低い

Digest認証はモダンなWeb環境と相性が悪く、

  • 一部ブラウザでは非対応や不安定
  • SPAやAPIとの連携が面倒
  • ヘッダーの扱いが特殊

といった問題があり、開発・運用の負担が大きいのが現実です。

HTTPSの普及で役割を終えた

Digest認証は「HTTP通信でパスワードを安全に送る」ことを目的に生まれました。
しかし今ではLet’s Encryptなどで無料SSLが普及し、HTTPSが当たり前の時代です。

その結果、Basic認証 + HTTPS という組み合わせで十分安全に通信できるようになり、Digestの必要性が薄れました。

他の認証方式が強すぎる

現在では以下のようなより優れた選択肢が広く使われています。

  • Basic認証 + HTTPS(シンプル&安全)
  • フォームログイン + Cookie認証(UIや制御が柔軟)
  • JWTやOAuth(モバイルやAPI連携に最適)

これらの登場により、Digest認証のメリットは完全に霞んでしまいました

まとめ

Digest認証は、かつてBasic認証の弱点を補う“改良版”として登場しました。
しかし、セキュリティ・互換性・運用性・代替手段の豊富さなどを考えると、
現在では「中途半端で不便な古い方式」となり、使われなくなっています。

いま選ぶなら?

  • Basic認証 + HTTPS → シンプルで十分安全
  • アプリ側でのログイン認証 → 柔軟でセキュリティも高い

コメント

タイトルとURLをコピーしました