ユーザー登録機能を持つWebアプリケーションのセキュリティにおいて、緩いパスワードポリシーで設計されたアプリケーションの場合、ブルートフォースアタック（総当たり攻撃）を受けると時間の問題でユーザーアカウントを奪われてしまうことがある。

ブルートフォースアタックへの対抗策として有効なのがアカウントロック機能だ。

例えば、暗証番号を3回間違えるとキャッシュカードが使えなくなったりと、身近なところでもアカウントロックが実装されているシステムは多い。

今回はアカウントロックを実装するにあたっての、基本的な仕組みを紹介する。

基本的なアカウントロック

Webアプリケーションにおける基本的なアカウントロックは以下のように実装する。

  • アカウント毎にパスワード間違いの回数をカウントする
  • パスワード間違いが上限数を超えるとアカウントロックする
  • ロックされたアカウントはログインできなくする
  • ロックされたら利用者、管理者にメールで通知する
  • 正常にログインされたらパスワード間違いのカウンタをリセットする

別途定める必要があるパスワード間違いの上限数だが、10回程度に設定するのが妥当だろう。
少なすぎると正規ユーザーがロックされてしまう頻度が高まってしまう。

また、ロックされたアカウントの再有効化は次のルールでおこなうのが良いだろう。

  • ロックから30分経過後、自動的に再有効化される
  • 管理者が本人確認した場合、再有効化の操作をおこなう

※再有効化までの時間だが、クレジット業界におけるグローバルセキュリティ基準であるPCI DSS 3.2でも30分とされている。

一見、再有効化までの時間が30分と聞くと短く感じられるが、例えば「パスワード間違いの上限数が10回、再有効化まで30分」のルールの場合、100個のパスワードを試すのに最低でも4時間30分以上もの時間がかかる。

またその間、10回のアカウントロック通知がユーザーおよび管理者に通知されるため、管理者は詳しい状況を調べた上で、必要に応じて攻撃が来ているIPアドレスを遮断したりといった対処をおこなうことができる。

これではどんなに優秀なスパコンを使っても、ブルートフォースアタックでパスワード認証を突破できる可能性は限りなくゼロに近い。

これからアプリケーションの開発をおこなう開発者は、そこまで工数のかからない機能でもあるので、アカウントロック機能の実装を検討に入れてみても良いかもしれない。