第2章 1.ユーザ認証を自製する場合

本ページの情報は2007年6月時点のものです。
記載の資料は資料公開当時のもので、現在は公開されていないものも含みます。

ユーザ認証とアクセス認可

コンテンツへのアクセスは、ユーザ認証とアクセス認可の 2段階の機能で構成するのが一般的である。

1. ユーザ認証
   アクセス要求してきた実体（entity）が本人であることを確かめる機能
2. アクセス認可
   ユーザ認証の関門を通過した実体に対して、コンピュータのリソースへのアクセスを許可あるいは禁止する機能

• 

Webアプリケーションのユーザ認証においては次のような点を考慮する。

常にユーザIDとパスワードを求める

ユーザ認証とは、アクセスを要求するユーザが本人であることを確認する仕組みであり、ユーザ固有の識別子である「ユーザID」とユーザのみが知っていると仮定される「パスワード」を照合することにより判定される。

ユーザの個人情報や秘密情報等へのアクセスは、許可されているユーザのみに限定する。
そのためにユーザの個人情報や秘密情報等を扱う場合には、必ずユーザ認証を行うべきである。

なお認証時のユーザIDとパスワードの照合処理をクライアント側で行ってしまうと、その処理の回避や改ざんのおそれがあるため、必ずサーバで行うことが重要である。

アカウントのロックアウト

ユーザ認証時に、一定時間内のログイン失敗回数が基準値を超えた場合には、そのアカウントを使用禁止にするべきである。

例えば、あるアカウントに対するログインが10回連続して失敗した場合に、そのアカウントのログインを数時間禁止する。ロックアウトを行わずに無制限にログイン失敗を許容してしまうと、パスワードやユーザIDを総当りで検証する攻撃「ブルートフォースアタック」により、認証を突破されてしまうおそれがある。

このように、ログイン失敗時にアカウントの使用を禁止する仕組みを「ロックアウト」と呼び、ログインの失敗回数やロックアウト期間等を任意に設定することができる。

ログイン失敗回数やロックアウト期間は、利用上の利便性との兼ね合いにより設定する。

ロックアウトは、同じユーザIDや同じパスワードでのログイン試行に対して反応する方がよい。またロックアウトは、そのアカウントが実在することの証明にもなってしまうので「ロックアウトした」旨のエラーメッセージは表示すべきではない。

パスワードフィルタ

パスワードの発行・登録時には「パスワードフィルタ」を用い、文字数が少なかったり、文字種が単純すぎる安易なパスワードが使用されるのを防ぐべきである。

パスワードフィルタとは、あらかじめ決めた規則(最低文字数、最低使用文字種等)に従ってパスワードの検証を行うものであり、安易なパスワード(ユーザIDと同じもの、生年月日、一般名詞等)を設定しようとした場合に、そのパスワードを拒否するものである。もしパスワードがユーザIDと同じであったり、一般名詞を使用している場合には、類推、辞書攻撃、総当り攻撃で容易にパスワードが盗まれてしまうおそれがあるからである。

パスワードフィルタの規則として、例を挙げる。

• 8文字以上で英字と数字と記号がそれぞれ1文字以上含まれるものを許可する
• ユーザIDが含まれるものは許可しない
• 生年月日が含まれるものは許可しない
• 以前4回と同じパスワードは許可しない
• 初期パスワード等を含むよくあるパスワードが登録されたパスワード辞書にあるものは許可しない

パスワードの変更

有効期限を定めてパスワードを長期間が変更していないユーザに変更を促すべきである。
変更されていないパスワードの長期使用は、長期になるほど攻撃者にパスワードが盗まれている可能性は高くなる。

管理者はユーザがパスワードをいつ変更したかを記録しておく必要がある。
例えばパスワードが漏えいした可能性が発生した際に、パスワードが変更された時期等の情報をもとにパスワードの変更をユーザにさせる必要がある。

パスワード等個人情報を変更する際には、必ず現行パスワードの再入力をさせ、ユーザ自身の意思で行われ、勝手に個人情報が変更されてしまうことを防ぐ必要がある。
また、変更があったことをユーザがあらかじめ登録している電子メールアドレス宛へ通知する等を行うことが望ましい。

ランダム化桁とチェック桁

パスワードのみならず、ユーザIDも、ランダム桁やチェック桁を含ませる等を行い、推測が困難なものとすべきであり、シーケンシャルな数値を含むものや、他人に知られている可能性のあるもの(電子メールアドレス、口座番号、社員番号、会員番号等)を使用すべきではない。なぜならば、攻撃者にユーザIDが知られた場合、総当り攻撃でパスワードが盗まれるおそれがあり、またユーザIDをいくつか採取された場合に、それらを比較することで他のユーザIDの推測が可能となり、攻撃の対象が広がるおそれもあるからである。

ログインエラーメッセージ

ログイン場面に限ってはエラーメッセージの説明については、あいまいにし、具体的に何を間違えたのかをユーザに伝達すべきではない。例えば、数組のユーザIDとパスワードを用いて、ログインを試行した結果、以下のメッセージが表示されたとする。

• 1組目のエラーメッセージ：ユーザIDが正しくありません
• 2組目のエラーメッセージ：パスワードが正しくありません
• 3組目のエラーメッセージ：ユーザIDが正しくありません

これらのメッセージから、1組目と3組目のユーザIDは存在せず、2組目に入力したユーザIDは存在することが判明してしまう。

このように具体的な内容をエラーメッセージに含めることは、攻撃の手がかりを与えてしまうことになり避けるべきである。上記の場合は「ユーザIDまたはパスワードが正しくありません」とした方がよい。

パスワードリマインダの慎重な設置

パスワードリマインダとは、ユーザがパスワードを忘れた際の救済措置である。本人しか知らない秘密情報(合言葉)をユーザに登録してもらい、パスワード忘れの際には、その情報をユーザ認証の代用とすることで、パスワードを再発行する仕組みである。

パスワードリマインダは、認証の機会が増えることでセキュリティが弱くなるため、できればパスワードリマインダを設けない方がよい。もし設ける場合には、次のようにすることを推奨する。

• パスワードリマインダのリスクをユーザに説明するとともに、「合言葉」として本人しか知らないような情報を選ぶようユーザを指導する
• パスワードリマインダを使う・使わないをユーザが選べるようにする
• パスワードリマインダの「合言葉」をWebページ上に表示しない
• パスワードリマインダの「合言葉」を平文メールでユーザに通知しない
• 一定回数試行に失敗したらパスワードリマインダをロックする（ロックアウト機能）

パスワード再設定/再発行手順

パスワードリマインダの「合言葉」が一致したら、パスワード再設定に次の手順を踏むことを推奨する。なお、要求されるセキュリティレベルによっては手続きを簡略化してもよい。

1. パスワードリマインダのWebページ上（https:）で1回限り有効なキー(短め)をユーザに発行する。
2. 1回限り有効な別のキー(長め)を含むURL（https:）を、ユーザがあらかじめ登録している電子メールアドレス宛送信する。
3. ユーザにそのURLのWebページにアクセスしてもらい、先ほどのキーを入力してもらう。
4. キーが照合できたらパスワードの再設定あるいは再発行を行う。
5. 一定回数以上照合に失敗したら 2つのキーは無効にする(ロックアウト機能)。

管理者権限の制限

管理者が個人情報を漏洩したり、一般ユーザに成りすましたりする機会を与えないよう、以下のように考慮すべきである。

• パスワードファイルを暗号化する。
• データベースへのアクセスを制御する。
• ひとりの管理者が多くの情報へアクセスできないよう権限の分割を行う。
• 不正なアクセスがないか、管理者以外の人間が定期的に監査する。