はじめに
Apacheなどで公開した開発用モジュールをブラウザから確認したいケースがある。
その際、認証をかけるとすればBasic認証やDigest認証を検討することになるが、
- どちらを採用すべきか
- 実装するときの手順はなにか
本記事にまとめてみた。
認証の実装方式（設定管理の方法）
下記認証方式が考えられる。
認証用のファイルを用いたBasic認証／Digest認証
- .htaccessを使用したBasic認証
- .htaccessを使用したDigest認証
認証用のファイルを用いるケースとしては、
複数のアプリベンダが利用する共通環境でApache設定ファイルを各アプリベンダが触れない場合が考えられる。
メリット
アプリベンダが自由に設定をオーバーライドできるためインフラ管理者が設定作業を行う必要がない
デメリット
インフラ管理者が各ディレクトリにどのような設定がされているか全体を把握できない
設定ファイルを用いたBasic認証／Digest認証
- 設定ファイルで管理／設定するBasic認証
- 設定ファイルで管理／設定するDigest認証
設定ファイルを用いるケースとしては、
インフラ管理者が設定ファイルで設定内容を一元管理したいときが考えられる。
メリット
設定ファイルの内容がすべてであるため、設定の全体を把握しやすい
デメリット
仮に、複数のアプリベンダが利用する共通環境でApache設定ファイルを各アプリベンダが触れない場合、設定変更依頼をアプリベンダから受領したのち、インフラ管理者が設定するため手間がかかる。
どちらを選択すべきか
ケースによって状況が変わってくるので案件等で採用する方式は変わってくるが、
個人的には設定ファイルを用いたBasic認証／Digest認証を使用するようにしたいと考えている。
なぜなら、様々な関係者がApacheの設定に関与すると、全体像の把握して管理することが難しくなるため。
実装方式（Basic認証かDigest認証か）
では、Basic認証とDigest認証どちらを採用すべきか。
方式としては以下が考えられる。
- SSLを使用しない状況下でのBasic認証
- SSLを使用した状況下でのBasic認証
- SSLを使用しない状況下でのDigest認証
- SSLを使用した状況下でのDigest認証
それぞれ認証としてどれだけの強度があるかが焦点になる。
SSLを使用するかどうかについて
SSLを使用する場合、通信自体の暗号化が担保されているので
Basic認証でもDigest認証でもどちらを使ってもかまわないと考える。
SSLを使用しない場合については、以下で検討した。
SSLを使用しない状況下でのBasic認証
- 通信時の暗号化
ユーザーIDとパスワードをBase64で変換し、リクエストヘッダーに付加して送信する。
Base64の復号は容易であり、傍受された場合は情報が筒抜けとなる。
参考：https://madalinazaharia.com/column/basic-authentication-and-digest-authentication/
- 設定ファイルの暗号化
パスワード自体はハッシュ化した状態で置いておくことができる。
bcrypt、MD5、SHA1、cript()を使用できるようだが、強度的にbcrypt一択と考えられる。
形式はuser:password(ハッシュ)
参考：https://httpd.apache.org/docs/2.4/misc/password_encryptions.html
SSLを使用しない状況下でのDigest認証
- 通信時の暗号化
ユーザーIDとパスワードをMD5で変換したハッシュ値を送信するとのこと。
MD５は脆弱であるという認識が広まっているように思うが、
ユーザーIDとパスワードのハッシュ値を攻撃者が取得しても、
ハッシュ値から原文を復号することはまだ難しいとのこと。
参考：https://ja.wikipedia.org/wiki/MD5#%E3%83%8F%E3%83%83%E3%82%B7%E3%83%A5%E3%81%AE%E8%A1%9D%E7%AA%81%E8%80%90%E6%80%A7%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6
参考：https://sylph01.hatenablog.jp/entry/20171207/1512615600#:~:text=%E5%BC%B1%E8%A1%9D%E7%AA%81%E8%80%90%E6%80%A7%20vs%20%E5%BC%B7,%E8%80%90%E6%80%A7%E3%81%A8%E5%91%BC%E3%81%B0%E3%82%8C%E3%81%BE%E3%81%99%E3%80%82
ただし、wikiにもある通り、将来的には攻撃手法や計算能力の進化により突破される可能性があるとのこと。
- 設定ファイルの暗号化
パスワード自体はハッシュ化した状態で置いておくことができる。
ただし、Basic認証と違い、MD5ハッシュでなければならない。
形式はuser:realm:password(MD5ハッシュ)
参考：https://httpd.apache.org/docs/2.4/misc/password_encryptions.html
SSLを使用しない状況下についてまとめ
通信でのMD5はまだ突破が難しいため、Digest認証であれば使用できる。
※ ただしAuthorizationヘッダの情報以外は暗号化されていない点に注意。
Basic認証についてはSSLを使用しない場合は、傍受されればIDとパスワードが漏れてしまう。
それぞれの実装方法
.htaccessを使用したBasic認証
・.htpasswdの作成（パスワードはBcryptでハッシュ化して書き込み）
$ htpasswd -nbB ユーザ名 パスワード > /etc/httpd/conf/.htpasswd
・.htaccessの作成（アクセス制御をかけたいディレクトリに作成する）
$ vi .htaccess
↓.htaccessの中身
AuthType Basic
AuthName "TEST"
AuthUserFile /etc/httpd/conf/.htpasswd
require valid-user
※ そもそも.htaccessの書き込みが対象のディレクトリに対して許可されている必要がある。
対象ディレクトリに対して「AllowOverride All」もしくは「AllowOverride AuthConfig」が設定されていること。.htaccessを使用したDigest認証
・.htdigestの作成（パスワードはMD5でハッシュ化して書き込み）
$ sudo htdigest -c /etc/httpd/conf/.htdigest 'realm名' ユーザ名
・.htaccessの作成（アクセス制御をかけたいディレクトリに作成する）
$ vi .htaccess
↓.htaccessの中身
AuthType Digest
AuthName "realm名"
AuthUserFile /etc/httpd/conf/.htdigest
require valid-user
※ そもそも.htaccessの書き込みが対象のディレクトリに対して許可されている必要がある。
対象ディレクトリに対して「AllowOverride All」もしくは「AllowOverride AuthConfig」が設定されていること。設定ファイルで管理／設定するBasic認証
・.htpasswdの作成（パスワードはBcryptでハッシュ化して書き込み）
$ htpasswd -nbB ユーザ名 パスワード > /etc/httpd/conf/.htpasswd
・下記を対象の設定ファイルに追記
（例）
AuthType Basic
AuthName "TEST"
AuthUserFile /etc/httpd/conf/.htpasswd
require valid-user
AllowOverride None
AllowOverride Noneは.htaccessによる設定を禁止している。設定ファイルで管理／設定するDigest認証
・.htdigestの作成（パスワードはMD5でハッシュ化して書き込み）
$ sudo htdigest -c /etc/httpd/conf/.htdigest 'realm名' ユーザ名
・下記を対象の設定ファイルに追記
（例）
AuthType Digest
AuthName "realm名"
AuthUserFile /etc/httpd/conf/.htdigest
require valid-user
AllowOverride None
AllowOverride Noneは.htaccessによる設定を禁止している。おわりに
SSL通信下であればBasic認証、Digest認証いずれを使用してもかまわないが、
SSL通信下でないなら、Digest認証一択になると考えた。
設定は.htaccessと設定ファイルどちらに書くかについては、それぞれメリット／デメリットがあるので都度考えていきたい。
