テスト中のサイトやWordPressの管理画面を「関係者だけに見せたい」。そんなときに使うのが Basic認証 です。設定手順を初心者にもわかるように解説し、途中で必ず出てくる「パスワードのハッシュ化」の仕組みも、なぜ・どうやってを含めてやさしく説明します。
MENU
Basic認証とは？
Basic認証は、Webページにアクセスしたときに 「ユーザー名とパスワードを入力してください」というダイアログを表示し、正しく入力した人だけを通す 仕組みです。
こんな場面で使われます。
- 公開前のテストサイトを、社内メンバーだけに確認してもらいたい
- WordPressの管理画面を、不正ログインから守りたい
- 特定のディレクトリ（フォルダ）を限定公開したい
ポイントは、Basic認証は サーバーのレベルで働く ということ。WordPressなどのアプリよりも「手前」でブロックするので、ログイン画面にたどり着く前に弾くことができます。
パスワードの「ハッシュ化」とは？
Basic認証を設定するとき、パスワードは そのままの文字（平文）では保存しません。「ハッシュ化」という処理をしてから保存します。ここが初心者のつまずきポイントなので、じっくり説明します。
ハッシュ化＝「元に戻せない一方通行の変換」
ハッシュ化を一言で言うと、こうです。
元の文字列を、元に戻せない別の文字列に変換すること
例えば、パスワードが test1234 だとすると、ハッシュ化するとこうなります。
大事なのは 「一方通行」 だということ。
- test1234 → ハッシュ に変換するのは簡単
- でも、ハッシュ $2y$10$Mbc… → test1234に戻すことはできない
これが「暗号化」との違いです。暗号化は鍵があれば元に戻せますが、ハッシュ化は原理的に元に戻せません。
なぜハッシュ化して保存するの？
もしパスワードを test1234 と平文のまま保存すると、そのファイルを誰かに見られた瞬間にパスワードがバレます。
でもハッシュ化して保存しておけば、ファイルを見られても$2y$10$Mbc…としか書かれていません。そこから元のパスワードは割り出せないので、万一ファイルが漏れてもパスワード本体は守られるのです。
「元に戻せない」のに、どうやってログインを判定しているの？
ここが一番不思議に感じるところだと思います。「元に戻せないなら、入力されたパスワードが正しいかどうやって確認するの？」仕組みはこうです。
- あなたがログイン時にtest1234 を入力する
- サーバーが、そのtest1234を 同じ方法でハッシュ化 する
- 出てきたハッシュと、保存済みのハッシュを 見比べる
- 一致すれば「正しいパスワード」と判断 → 認証OK
つまり、保存されたハッシュを元に戻すのではなく、入力されたパスワードを毎回ハッシュ化して見比べているのです。同じパスワードなら必ず同じハッシュになるので、これで照合できます。たとえるなら――
- パスワード ＝ 鍵
- ハッシュ ＝ その鍵で取った 「指紋」
- 指紋から鍵は作れないが、鍵を持ってくれば指紋を取って「同じ指紋か」確認できる
bcrypt という方式
ハッシュ化にはいくつか方式があり、先頭の記号で見分けられます。
この記事では、現在もっとも安全とされる bcrypt を使います。$2y$10$… の 10 は「計算の手間（コスト）」を表す数字で、大きいほど頑丈ですが処理も重くなります。10 が標準的な値です。
なぜ bcrypt がおすすめなのか
ポイントは、bcrypt が 「わざと計算を遅くしてある」 という点です。一見デメリットに聞こえますが、これがそのまま強さになります。
パスワードが破られるときは、攻撃者が 「候補のパスワードを片っ端からハッシュ化して、漏れたハッシュと一致するか試す」（総当たり攻撃）という方法が使われます。つまり 1回のハッシュ化が速いほど、攻撃者は短時間で大量に試せてしまうのです。
1秒間に何十億回も試せてしまう。安価なGPUを使えば、短いパスワードは現実的な時間で破られる。
1回に意図的に時間をかける設計。総当たりが極端に非効率になり、破るコストが跳ね上がる。
さらに bcrypt には、次の2つの仕組みが最初から組み込まれています。
- コスト（$2y$10$ の「10」）で強度を調整できる… コンピューターの性能が上がって破りやすくなっても、この数字を増やすだけで対抗できます。将来にわたって強度を保てる設計です。
- ソルト（毎回ランダムな値）が自動で付く… 同じパスワードでも生成されるたびに違うハッシュになるため、「よくあるパスワードのハッシュ一覧」（レインボーテーブル）を使った攻撃が効きません。
MD5・SHA-1 はもう使わないの？
結論から言うと、パスワードの保存用途では避けるべきです。理由は大きく2つあります。
- 速すぎる… 上で説明したとおり、総当たり攻撃に弱いです。もともとファイルの改ざんチェックなど「速さが求められる別の用途」のために作られたもので、パスワード保存には向いていません。
- SHA-1 は「衝突」が実証済み… 異なる入力から同じハッシュを作り出せることが研究で示されており、安全性が破られたと見なされています。主要ブラウザやOSでも、SHA-1 は段階的に廃止されてきました。
これらは 歴史的な経緯で今も選べるだけで、新しく設定するなら選ぶ理由はありません。
htpasswd に -Bを付けて bcrypt を明示的に指定するのが安全です（-B を付けないと、環境によっては古い方式が使われることがあります）。
必要な2つのファイル
Basic認証は、2つのファイルの組み合わせで実現します。役割がはっきり分かれているので、混同しないようにしましょう。
.htaccess = 指示書
「このフォルダは Basic認証で守り、名簿を見て照合しなさい」とサーバーに指示する。
↓参照する
.htpasswd = 名簿
ユーザー名と ハッシュ化されたパスワード を保存しておく。
どちらもファイル名の先頭が ドット（.） で始まる隠しファイルです。ファイルマネージャーによっては、設定で「隠しファイルを表示」をONにしないと見えないことがあります。
設定手順
STEP1.パスワードのハッシュを作る
まず .htpasswd に入れる「ユーザー名 + ハッシュ化パスワード」を作ります。Apache に付属する htpasswd というツールを使うのが確実です。（XAMPP を使っている場合、C:\xampp\apache\bin\htpasswd.exe にあります）
Windows の PowerShell で実行する例：
cd C:\xampp\apache\bin
.\htpasswd.exe -nbB "ユーザー名" "パスワード"-n… ファイルに書かず、結果を画面に表示する-b… パスワードをコマンドで直接指定する-B… bcrypt 形式で作る
実行すると、こんな1行が出力されます。これが .htpasswd の中身になります。
ユーザー名:$2y$10$xxxxxxxxxxxxxxxxxxxx...XAMPP がない場合の作り方
htpasswd ツールが手元にない場合でも、次のいずれかの方法で同じ bcrypt ハッシュを作れます。どれも「ユーザー名:ハッシュ」の1行が得られれば結果は同じです。使いやすいものを1つ選べば大丈夫です。
■Mac / Linux のターミナル
多くの Mac / Linux には htpasswd が最初から入っています（無ければ Ubuntu 系は apt install apache2-utils、Mac は brew install httpd で導入）。
htpasswd -nbB "ユーザー名" "パスワード"■PHP が使えるなら
レンタルサーバーなど PHP が動く環境なら、次の1行を実行するとハッシュだけ作れます（ユーザー名は自分で頭に付けます）。コマンドラインなら php -r で、Webなら .php ファイルに書いてアクセスします。
php -r 'echo password_hash("パスワード", PASSWORD_BCRYPT);'STEP2. .htpasswd を作る
作ったハッシュの行を、.htpasswd というファイルに保存します。中身はこの1行だけです。
ユーザー名:$2y$10$xxxxxxxxxxxxxxxxxxxx...このファイルを、サイトのフォルダ（ドキュメントルートなど）に置きます。
STEP3. .htaccess に認証の設定を書く
次に .htaccess に、認証の指示を書きます。すでに .htaccess がある場合（WordPressなど）は、既存の内容を消さずに、以下を追記します。
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /絶対パス/.htpasswd
Require valid-userAuthUserFile には、.htpasswd の絶対パス（サーバー上のフルパス）を書きます。ここが最重要ポイントです。
STEP4. WordPress の場合は一部を「除外」する
サイト全体にBasic認証をかけると、WordPress の一部の内部処理まで巻き込んでしまい、動作がおかしくなることがあります。特に次の2つは、認証から除外しておくのがおすすめです。
<Files "wp-cron.php">
Require all granted
</Files>
<Files "admin-ajax.php">
Require all granted
</Files>wp-cron.php… 予約投稿やバックアッププラグインなどの「時間で動く処理」に使われるadmin-ajax.php… 管理画面やブロックエディタの裏側の通信に使われる
これらを除外しないと、予約投稿が動かない、編集画面が不調になる、といった副作用が出ることがあります。
■完成形の .htaccess（STEP 3 + STEP 4）
ここまでを1つにまとめると、WordPress サイトの .htaccess は次のようになります。既存の WordPress 用の記述（# BEGIN WordPress 〜 # END WordPress）は消さず、その前後に追記するイメージです。
# ===== Basic認証 =====
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /絶対パス/.htpasswd
Require valid-user
# ----- 認証から除外する（WordPress用）-----
<Files "wp-cron.php">
Require all granted
</Files>
<Files "admin-ajax.php">
Require all granted
</Files>
# BEGIN WordPress（既存のまま残す）# … WordPress が自動生成した記述 …# END WordPressAuthUserFile の /絶対パス/.htpasswd を、自分のサーバーの実際のパスに置き換えれば完成です。
STEP5. 動作確認
設定できたら、シークレットウィンドウ（プライベートブラウズ） でサイトを開いて確認しましょう。なぜなら、普段のブラウザには一度入力した認証情報が記憶されていて、正しく確認できないことがあるためです。まっさらな状態で試すのが確実です。
✓ 認証ダイアログが出て、設定したユーザー名・パスワードで入れれば 成功
！500エラーが出たら → .htpasswd のパス（AuthUserFile）が間違っている可能性が高い
まとめ
- Basic認証は、サーバーレベルで「関係者だけに見せる」仕組み
- パスワードは ハッシュ化（元に戻せない一方通行の変換）して保存するので、ファイルが漏れても安全
- 照合は「入力を毎回ハッシュ化して見比べる」ことで実現している
- 設定は .htpasswd（名簿） と .htaccess（指示書） の2ファイル
- WordPressでは
wp-cron.phpとadmin-ajax.phpの除外を忘れずに AuthUserFileの絶対パスを間違えると500エラーになるので注意
仕組みを理解すれば、「なんとなく怖い」設定も、安心して自分でできるようになります。ぜひテスト環境で試してみてください。
