システム開発をしている永松です。
自転車で完全に迷った時の感覚が好きです。
今はどうしようもなくなったらスマホですぐに現在地、知っている道までの道順を調べることができますが、昔はコンビニなどで道を聞いたりしてました。
シンプルな方向音痴。
さて、Web開発をしているとBasic認証を設定して欲しいとお願いされることがあります。
気楽にID、パスワードでの認証をWebサイトに設定出来るこの機能はわりと皆さん使われるんじゃないでしょうか。
ただ、Basic認証を使う際にこんなことも一緒に質問もらうことがあります。
・ログイン機能が欲しいんだけどBasic認証でいけるかな。
・Basic認証ってセキュリティ弱いんだよね。
こんなに使われてるBasic認証なのにすごく勘違いされてるな、と思ったので今日のお話はBasic認証についてです。
今日の記事を読んでもらった後、なんとなくBasic認証の機能がわかってもらえれば幸いです。
そもそもBasic認証って何？
ややこしい言い方をするとHTTP通信に用意されてる認証機能という言い方になります。
早い話、レンタルサーバーなどで気軽に使える認証機能である、と思ってもらって大丈夫です。
さらに、ID、パスワードの組み合わせは1通りだけではなく、複数登録することも出来ます。
ということはログイン機能がBasic認証でできるってこと？
答えとしては、多分思ってることは出来ないとなります。
というのが認証機能とは言っていますが、サーバーではID、パスワードが一致した人だ、というのはわかりますが、どの人で認証が通ったかは管理していません。
つまり、10個のID、パスワードの組み合わせがあった場合に、どの組み合わせでログインした人かはわからない、ということになります。
そのため、ID、パスワードを知っている人だけがログインできるページという意味でのログイン機能はBasic認証で可能ですが、この人にだけ見れる情報を表示したい場合や、ポイントをそれぞれのIDに割り振りたい、といったいわゆるマイページ的なことはBasic認証では出来ません。
ログイン機能が欲しいと言われる場合は、おそらくこちらの動きを求められていると思うので，多分思っていることは出来ないという答えとなります。
こういう場合は独自のログイン機能が必要となってきます。
なお、サーバー側のプログラムで頑張ればBasic認証でも動的に切り替えたりポイント管理といった機能を作れなくはないですが、これをやろうとすると、Basic認証用、サーバー用でアカウントの2重管理が発生してしまうなど開発の時間が独自に作成するよりかかってしまうため、あまりおすすめできません。
Basic認証はセキュリティが弱い？
おそらくですが、これを言われる方はどういうセキュリティの弱さの話をしているのかがわかってないと思います。
そしてこういうことを言うと、出たよ開発者の面倒なやつと言われ、もはや私達の声は届かず生まれ故郷の風景を思い出してることでしょう。
ただ、これは嫌がらせではなくかなり重要なところなので、面倒だとは思いますがグッと我慢して続きを読んで下さい。
Basic認証のセキュリティで考えられるパターンとして、以下3つのパターンが考えられます。
1.Basic認証を行うためのファイル「.htpasswd」のセキュリティ問題
2.何度もID、パスワードの組み合わせを試せてしまうセキュリティ問題
3.通信盗聴に関するセキュリティ問題
以下、それぞれのセキュリティについて考えてみましょう。
1.Basic認証を行うためのファイル「.htpasswd」のセキュリティ
.htpasswdファイルを作れるサイトもたくさんあり、今となってはすごく気軽に作れるようになりました。
ちなみに、昔はサーバー上でコマンド打って作ってました。
そんな気軽に作れるファイルなのでセキュリティ上弱いんじゃないか、と思われてるのかなと思いますが、実際はそんなことはありません。
仮に.htpasswdが漏洩したとしても、パスワードはMD5という方法でハッシュ化と呼ばれる、まぁ暗号化されたもので保存されています。
そのため、.htpasswdを取得して中身を見てもパスワードを推測することはかなり難しいです。
ただ、もしダウンロード出来てしまうと、プログラムでパスワードを探索することが出来てしまうため、漏洩しないに越したことはないです。
しかし、昔はパスワードをCRYPTという暗号化方式で作成していました。
この場合、パスワードを復号化出来てしまうため、MD5のハッシュ化に比べればセキュリティは下がってしまいます。
もしかすると、この頃の話が伝わってセキュリティの弱さに繋がっているのかもしれません。
どちらにせよ、.htpasswdは漏洩しないに越したことはないため、可能な限りの漏洩対策はしておきましょう。
2.何度もID、パスワードの組み合わせを試せてしまうセキュリティ問題
この攻撃、ブルートフォースアタック（Brute Force Attack）というなんともカッコよろしい名前がついています。
名前はかっこいいですが、攻撃方法としてはパスワードを総当りで調べる攻撃というすごく原始的な攻撃方法です。
この攻撃の防御方法は一定回数間違えたらアクセスを拒否するという防御方法となるのですが、Basic認証にはこの防御方法は用意されていません。
そのため、Basic認証を使う場合はブルートフォースアタックには無力です。
※厳密には対策方法はありますが、これやるくらいならファイアーウォール導入するなど別の対策のほうが楽です。
ただ、相当簡単なパスワードを設定していない限り、おそらく攻撃成功の前にレンタルサーバー側から接続拒否される、またはサーバーが落ちることで攻撃は失敗する可能性が高いです。
もし何か対策をしたいと思われた場合、答えとしてはBasic認証でブルートフォースアタック対策するぐらいなら自前で作ったほうが早いし安いし確実、という答えになります。
3.通信盗聴に関するセキュリティ問題
おそらくBasic認証のセキュリティが低いという一番の理由はこれです。
というのが、Basic認証の通信を覗いてみると以下のような文字が見つかります。
authorization: Basic XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
この文字列、実は結構簡単に復元して中身が見れてしまい、その中にはID、パスワードがそのまま入っています。
そのため、通信が盗聴されてしまうと結構簡単にID、パスワードが盗まれてしまうということになります。
ここから、Basic認証のセキュリティは弱いとなっていましたが、今となってはこの問題は解消しています。
なぜかというと、以前ブログでも書かせてもらった常時SSL化により、最近の通信はHTTPSで暗号化されているため、上の文字も暗号化されており、盗聴されても復元することが難しくなっているためです。
なので、テストサイトが「http」で通信している場合は、この問題が再発するため注意が必要です。
面倒ですが、テストサイトでも極力https設定しておきましょう。
結局Basic認証を使うときはどうすればいいのか
気をつけることは以下2つです。
・.htpasswdファイルは漏洩しにくい設定にしておく
・証明書を設定してhttps通信で通信するようにする
この点さえ気をつけておけばまず大丈夫です。
ただ、ブルートフォースアタックの問題は残っており、簡単に突破できる訳じゃないですが鉄壁でもない、という意識を持ってもらい、ものすごく重要な情報の場合はBasic認証は使わないようにしてください。
セキュリティは難しく、面倒な問題ですが場面に合った使い方が重要になります。
特に珍しくもない10円硬貨を金庫に入れるのはやり過ぎですし、100万円をビニール袋に入れて道端に置いておくのは緩すぎます。
今日の記事でBasic認証の特徴がふわっとわかってもらえ、適切な情報に設定してもらえるようになれば嬉しいです。
上がれ、正しい日本のセキュリティ意識。
おまけ1：そもそものログイン
Basic認証の盗聴問題で、盗聴されるとID、パスワードが丸見えになるというお話をしましたが、じゃあいわゆるページにID、パスワードを設置したログインページにすれば大丈夫なんだね、と思われる方もいるかも知れませんが、正解はNOです。
ページでのログインでもHTTP通信で盗聴されればID、パスワードは丸見えです。
そのため、ログインが必要なページは常にHTTPS（SSL）となるよう気をつけてください。
おまけ2：暗号化とハッシュ化の違い
暗号化は方法がわかれば復元出来ます。
対してハッシュ化は復元は出来ません。
復元できる、ということは、暗号化された文字に正解が書かれているということになります。
そのため、パスワードが流出した場合、ハッシュ化された文字のほうが暗号化された文字よりセキュリティは上がります。
おまけ3：辞書攻撃
ブルートフォースアタック、総当たりで試すということは、つまり英数字を0から始めるということなので、組み合わせの数としては気が遠くなるような計算量となります。
それであれば実質不可能ではないかと思われがちです。
しかし、この世には攻撃用の辞書というものが存在します。
この辞書にはよく使われるパスワードの文字が書かれており、ブルートフォースアタックをする場合はまずこの辞書にかかれている文字から試していくのが定石です。
なお、辞書を使ったブルートフォースアタックのことをディクショナリアタックと別の呼び方をします。
意味はそのまま辞書攻撃ですね。
そのため、パスワードを設定する場合は、極力ランダムな文字列を設定するようにしましょう。
永松
この記事を書いた人黙々とパソコンに向き合い、少々の無理難題にも粛々と応える、お悟りお開き系エンジニア。AND SPACEの様々なシステム案件を任されているだけでなく、会社全体の運営にも的を射た意見で常々存在感を発揮する。顧客や同僚にいくら駄々をこねられても、淡々と正論を繰り出す姿は、「ナガえもん」と呼ばれて然り。いかなるシステム案件も、最初は粗々で構わないと言い切れるのは、ユーザー目線の「実際の使用感」が大切なことを重々承知しているから。そこからの喧々諤々こそ真骨頂。皆々、度々、多々、救われる。
