.htaccess Basic認証の設定方法について(.htpasswdの暗号化まで)
Basic認証はディレクトリ単位・ファイル単位・ユーザー単位で.htaccessファイルによるアクセス制限を掛ける機能です。
パスワードはハッシュ値に変換して暗号化する必要があるので、ご自身で別途管理する必要があります。
セキュリティ的には決して高いものではないので、多用は禁物です。通信自体を暗号化するためSSLを利用しましょう。
Basic認証とは.htaccessを使った認証システム
Basic認証とは特定WEBページの閲覧にユーザー名とパスワードを入力を求める認証システムです。
WEBページへアクセスした際画面上部にポップアップウィンドウが表示され、ユーザー名とパスワードの入力欄が出てくるのを見た事ありますよね。
これがBasic認証と呼ばれるアクセス制限がされているページです。
決められたユーザー名(ID)とパスワードをを入れないとログインすることができないので、ID・パスワードを知らない人はWEBページを見る事ができません。
Basic認証は.htaccessファイルを利用して簡単に実現できる仕組みなので、現在もよく使われています。
Basic認証はディレクトリ単位でアクセス制限ができる
Basic認証はディレクトリごとのアクセス制限が可能です。
つまり認証を掛ける区画(ディレクトリ)掛けない区画を分ける事ができるのですね。
特定ディレクトリへのBasic認証
例えばあるWEBサイトが以下のようなディレクトリ構造になっているとしましょう。
contents1/に.htaccessを設定した場合
llpeg.info/contents1/
↓ここから
llpeg.info/contens1/
llpeg.info/contens1/aaa.html
llpeg.info/contens1/bbb.html
↑ここまで全て認証が掛かる
↓以下は掛からない
llpeg.info/contens2/
llpeg.info/contens2/aaa.html
llpeg.info/contens2/bbb.html
contents1/というディレクトリにBasic認証を設定した場合、contents1/全体にBasic認証がかかります。
contents1/、contents1/aaa.html、contents1/aaa.htmlのいずれを直接開いても制限が掛かるのですね。
それに対し、contents2/のディレクトリには認証設定がされていないので、何もせずにWEBページを見る事ができます。
このように設置したいディレクトリのTOPに設定を掛ければ簡単に実現できます。
.htaccessファイルを置く位置により変わる
ここで.htaccessをllpeg.info/のTOPディレクトリに置くと、WEBサイト全体にアクセス制限が掛かってしまいます。
そうするとcontents1、contents2の全てが対象範囲となりますので、ディレクトリごとの操作ができなくなります。
ファイルを設置する位置には注意をしましょう。
ファイルは複数置けるので、制限したいディレクトリのTOPにそれぞれ置けばその区画だけを制限できます。
優先順位がある
上の階層にある.htaccessの効果は基本的に下層まで浸透します。
下層配下に.htaccessがあるとその効果の方が優先されます。
Basic認証の利用用途
このBASIC認証はどんな用途で利用されるのでしょうか。
主に以下のようなシーンで使われる事が多い様です。
公開前サイトの閲覧制限
・WEB制作会社が制作中のWEBサイトのクライアントへのテスト確認
・一般公開が許されていないWEBサイト
Basic認証をしておけばクライアントか関係者しかデータ閲覧ができないため便利です。
一般公開がOKになったらBasic認証を解除すればすぐに一般公開ができます。
特定ユーザー向けコンテンツ
・医療情報コンテンツ
・特定資格を持つ人限定のコンテンツ
・特定講座の講座内容
こういった特定の条件の人だけに公開するコンテンツの場合です。
BASIC認証を設定して、条件をクリアしている人にだけIDとパスワードを発行して閲覧してもらうなどの運用が可能になります。
検索エンジンにインデックスされたくないコンテンツ
Google等の検索エンジンは制限がない限りどのようなWEBページでもクロール・インデックスします。
クロール・インデックスされたものは必ず検索結果に表示されるようになります。
Googleの検索結果に表示させない方法
Googleの検索結果に表示させない対策としては以下が有名です。
・head内にnoindexタグを設置する
・robots.txtでアクセスをブロックする
しかし上記は100%確実な制限方法ではないとされています。
Basic認証を設定しておけばIDとパスワードがわからないため、Googleクローラーにも物理的な制限が掛かります。
そのためGoogleからは100%インデックスされません。
.htaccessの設定方法
Basic認証のために準備するのは、.htaccessファイルと.htpasswdファイルでいずれもメモ帳などのテキストファイルを使います。
いずれも文字コードはutf8で揃えて下さい。
・.htaccess…アクセス制限を掛ける指定をするファイル
・.htpasswd…パスワードを記載するファイル
.htaccessファイルへのBasic認証の書き方
.htaccess記述例
AuthUserFile /home/users/1/llpeg/web/llpeg/Webcontents/contents/type1/c3/mseks/.htpasswd AuthGroupFile /dev/null AuthName "Input ID and Password." AuthType Basic require valid-user <Files ~ "^.(htpasswd|htaccess)$"> deny from all </Files>
.htaccessファイルに書く内容は以下の通りです。
・AuthUserFile…IDとパスワードを明記したファイルの位置
・AuthGroupFile…グループ認証の欄(/dev/nullと記載)
・AuthName…認証画面のタイトルとなる文字
・AuthType…認証を使う命令(Basicと記載)
・require…認証ユーザーの種類(valid-userと記載)
・Files….htaccess・.htpasswdファイル自体へのアクセスを拒否
書く順番は自由です。
AuthGroupFileとは
本来AuthGroupFileには、ログインするグループのIDとパスワードを書いたファイルの場所を記載します。
しかしBasic認証はユーザーごとの認証で必要がないため、特に指定が無いという意味で/dev/nullと記載します。
.htaccess・.htpasswd自体へのアクセス制限
上記事例の下にFilesで始まる部分があります。
これは「.htaccess」「.htpasswd」というファイルは全てのアクセスを拒否するという意味です。
これにより直接URLを指定してファイルを開く事が出来なくなります。
ページ単位で設定をする事もできる
これまでBasic認証はディレクトリ(フォルダ)単位での設定ができると言いましたが、ファイル単位でも可能です。
<Files wp-login.php> AuthUserFile /llpeg/wp-admin/.htpasswd AuthGroupFile /dev/null AuthName "Member Only" AuthType Basic require valid-user </Files>
このようにFilesで囲む事で特定のファイルに対してのみBasic認証を掛ける事ができます。
サーバーパスについて
初心者の一番のネックとなるのが「AuthUserFile」のサーバーパスの欄ですね。
サーバーパスを記述するためには、設定するWEBサイトのサーバーを調べる必要があります。
レンタルサーバー等であれば、コントロールパネル内にログインすると契約しているサーバーのサーバーパスが記載されています。
※必ず「/」から始まります。サーバー情報やアカウント情報などの欄にあります。
サーバーパスはサーバーごとに違うので、上のをコピペするのではなくきちんと調べましょう。
サーバーパスの記載(一部例)
ロリポップ
コントロールパネル内ユーザー設定からアカウント情報のページ
/home/users/2/ユーザー名/web/独自ドメインの公開フォルダ名/.htpasswd
Xserver
コントロールパネル内サーバー情報の欄
上記のパスに加えて、独自ドメイン名とpublic_html/までが入ります。
/home/サーバーID/独自ドメイン名/public_html/認証をかけるディレクトリ名/.htpasswd
さくらインターネット
さくらいインターネットはサーバーパスがコントロールパネル内に記載がありません。
一般ルールとして以下の様になっています。
/home/ユーザ名/www/ユーザー名/認証をかけるディレクトリ名/.htpasswd
.htpasswdの設定方法
次は.htpasswdファイルの書き方です。.htaccessと同様にメモ帳に書き込みます。
ユーザーID:暗号化パスワード
ユーザーID:暗号化パスワード
ユーザーID:暗号化パスワード
.htpasswd例
20062690:aV7mdHyRP4Kv2 20063224:AWTsT4BjlHLhA 20061535:AWDzJHTcxCiVY 20061789:5vQqhpVp.F93I 20061882:V.nqpo1XF8fiI 20060539:A1HsSZZND2JsI 20063088:BDm8YYXjS5Alk 20061255:FK0uSjq2v6Msw
上記の様に改行して複数のIDとパスワードを設定する事ができます。
ここで設定した組み合わせのパスワードであればどれでも認証を許可する事になります。
IDとパスワードは一番上から記述して構いませんし、間で改行を入れて1段間を入れても大丈夫です。
ポイントは、パスワードをファイル内にそのまま書かず暗号化したものを入れる事です。
パスワードの暗号化
パスワードはこのhtpasswdファイルに直接書くのではなく、必ず暗号化をする必要があります。
具体的には、パスワードを「ハッシュ値」という別の文字列に変換するのです。
仮にこの.htpasswdが流出してユーザーIDまでは盗み見られても、記載されている英数字は暗号化されていますので、そのままパスワードを入力しても認証は通りません。
セキュリティ上の設定と言えますね。
暗号化しているので自分で見てもわからない
パスワードには「ハッシュ値」を書く訳ですから、書いた後はあなた自身この.htpasswdファイルを開いてもパスワードがわかりません。
なので、パスワードを何にしたのかをご自身で別途管理しておく必要がありますね。
慣れない人は忘れてしまう事が多く、忘れた場合パスワードを設定し直す事になります。
パスワードを直接.htpasswdに書いても認証されない
仮に暗号化を忘れてパスワードをそのまま.htpasswdに書いてても、実際には入力パスワードははじかれ認証がされません。
.htpasswdに記述された文字列は「ハッシュ値」と判断されるため、そのハッシュ値が導き出すパスワード文字列は違うものになっているのです。
ハッシュ値化された値が「パスワード」の羅列になるような半角英数字の入力が必要になります。当然わかりませんよね。
ハッシュ生成サービス
繰り返しますが、パスワードを暗号化するには「ハッシュ値」に変更する必要があります。
パスワードは半角英数字(大文字・記号あり)で自由に設定できますが、これをハッシュ値に変換すると全く違う文字列になります。
ハッシュ値は自動で決まるため、自分の好きな半角英数の文字列にする事はできません。
ハッシュ生成サービスサイトを利用すれば、パスワードに対するハッシュ値が簡単に取得できます。
ハッシュ値出力おすすめサイト
特に3つ目はパスワード部分だけ貼り付ければすぐにハッシュ値が出ますので、個人的におススメです。
特定IPアドレスのみ許可する
場合によって、特定環境のユーザーは認証不要で閲覧できる様にする必要があります。
サイトの管理者やクライアント担当者などが、毎回ユーザー名とパスワードを入れるのは正直面倒です。
それ以外に外部サーバーとの通信が必要なサービスを受けている場合は、そのサーバー先も許可しておく必要があります。
特定IPを許可する
そのためには、特定環境のユーザーやサーバーのIPアドレスを調べ、そこからのアクセスを許可しなければなりません。
そうすれば特定IPアドレスからのアクセス時には認証画面が出ず、それ以外は認証画面が出る様になります。
.htaccessのBasic認証記述に以下の様な追加をします。
特定IPを許可する.htaccess記述例
AuthUserFile /home/users/1/llpeg/web/llpeg/Webcontents/contents/type1/c3/mseks/.htpasswd AuthGroupFile /dev/null AuthName "Input ID and Password." AuthType Basic require valid-user <Files ~ "^.(htpasswd|htaccess)$"> deny from all </Files> ##ここから追記 <RequireAny> Require ip xxx.xxx.xxx.xxx Require ip 185.87.175.0/22(書き方例) require valid-user </RequireAny> ##ここまで
上記の様にRequireでくくり、中にIPアドレス(複数あれば複数段)を入れます。
IPアドレスは、ipv4とipv6とで書き方が違いますので注意して下さい。
Satisfy Anyについて
たまに「Satisfy Any」を使った書き方をしているものがありますが、今現在これを書くと特定IPアドレスに限らず全て解除されてしまいます。
過去に特定IPを許可したBasic認証を掛けたサイトは、動作確認をしてみて下さい。
Apache2.4以降の仕様変更
これは「Satisfy Any」の記述自体が、Apache2.2系の書き方であるためです。
Apache2.4以降は許可するIPを<RequireAny></RequireAny>に挟んで書く方法になっています。特定IPアドレスを許可する場合は、Satisfy Anyを用いた書き方はしない様にしましょう。
Basic認証を掛けるメリット
まずは何と言っても比較的容易にアクセス制限を掛けれる部分ですね。
共通パスワードを発行したり、個別パスワードにしたりと自在ですし、アクセス制限のON・OFFも簡単です。
そして複数個所と複数パスワードでアクセス制限管理ができる点もBasic認証のメリットと言えると思います。
ファイルは一度記述をしておけば基本的には複製して使いまわしができます。
あとは状況に応じて部分的に書き換えるだけです。
Basic認証のパターン
いくつかよくある設置事例パターンを紹介します。
1つのディレクトリに1つのパスワードでアクセス制限を設ける場合
・.htaccessファイルを該当ディレクトリに設置
・.htpasswdファイルを指定位置に設置
1つのディレクトリに対し複数ユーザーに個別にアクセス制限を設ける場合
・.htaccessファイルを該当ディレクトリに設置
・.htpasswdにパスワードを複数設置
・.htpasswdファイルを指定位置に設置
複数ディレクトリにパスワードは共通1つのアクセス制限を設ける場合
・.htaccessファイルを複製して複数個所に設置
・.htpasswdファイルを指定位置に1つ設置
複数ディレクトリにそれぞれ別々のパスワードでアクセス制限を設ける場合
・.htaccessファイルを複製して複数個所に設置(名前は全て.htaccess)
・.htpasswdファイルを複製して複数個所に設置(名前は全て.htpasswd)
・.htaccessファイルのAuthUserFile欄(対応するhtpasswdのパス)を書き換える
・.htpasswdファイルのパスワードをそれぞれ変更する
※1つの.htaccessに対し1つの.htpasswdが対応する様に設置します。
Basic認証を掛けるデメリット
慣れれば使い勝手の良いと思われるこのBasic認証ですが、デメリットもちゃんとあります。
・初心者には少し設定が高度
・.htpasswdのサーバーパスの記載
・ディレクトリごとに.htaccessファイル設置が必要
・通信自体は暗号化されていない
特にAuthUserFileの欄はWEBサーバーのパスを調べる必要があるので、少し敷居が高いかも知れません。
あくまでも簡易的な認証方法である
このBasic認証はその名の通りベーシックな認証方法であり、あくまでも簡易的な機能です。
一度設定さえしてしまえば簡単・手軽な点で重宝されているのですが、常時多用は禁物です。
・Basic認証の構成は共通である
・ブラウザを閉じるまでずっと認証され続ける
・ディレクトリ間の往来時に認証維持ができない
セキュリティ面の不安
Basic認証は.htaccessと.htpasswdで構成されている事は誰でも知っています。
場合によっては設置場所が特定されて、中身が流出してしまう事も考えられるのです。
さらにBasic認証は一度認証をしたらブラウザを閉じない限りずっと認証され続けます。
認証状態をハッキングされれば第三者に認証情報が盗まれる危険性が出ますよね。
機能不足の面
例えばディレクトリAとディレクトリBのみにBasic認証を掛ける場合、共通パスワードでもAとBにそれぞれ個別にhtaccessを置く必要があります。
つまり一つ一つ手作業による設定になるので、ミスも増える事になります。
以上のようなセキュリティ面における脆弱性および機能不足は否めません。
通信自体は暗号化されていない
Basic認証はコンテンツへの入出時のみで、通信内容自体が保護されているわけではありません。
通信自体を保護するためにはSSL(https)暗号化が必要です。
Basic認証はパスワードも暗号化しているのでセキュリティ性能が高そうですが、単にアクセスする人を制限しているだけですので気を付けるべきです。
まとめ
.htaccessによるBasic認証は最初は難しく感じるかも知れませんが、一度書いて動作検証できればあとは部分的に複製・変更するだけです。
.htaccessを使ったBasic認証のポイントをまとめておきます。
Basic認証はディレクトリ単位・ファイル単位・ユーザー単位で.htaccessファイルによるアクセス制限を掛ける機能です。
・パスワードはハッシュ値に変換して暗号化する必要があるので、ご自身で別途管理する必要があります。
・セキュリティ的には決して高いものではないので、多用は禁物です。通信自体を暗号化するためSSLを利用しましょう。