アカウントロックの設計

このレッスンで学ぶこと

アカウントロックは、失敗が続いた利用者を一時的に締め出す仕組みで、レートリミットの延長にあります。この回は、ロックを何で判定するかで何が変わるかと、実務での落としどころを扱います。

読み終えると、ロックを入れたときに機密性と可用性のどちらをいくら払っているかを、自分の言葉で言えるようになります。

素直な実装が招くもの

「5回失敗したら30分ロック」を利用者名だけで判定するとします。攻撃者は、パスワードを当てにいく代わりに、狙った相手の利用者名にでたらめを5回送るだけで済みます。

POST /login  name=tanaka  password=x  ×5
  → tanaka は30分ログインできない

本人のパスワードが正しくても入れません。前回の列挙で利用者名の一覧を作ってあれば、全員分を順に締め出すこともできます。守りの仕組みが、そのまま可用性への攻撃になりました。

機密性・完全性・可用性の3つのうち、ロックは機密性を上げる代わりに可用性を下げます。どちらも守るべきものなので、片方を落とし切る設計にはできません。

落としどころ

実務でよく取られる形は次のとおりです。

• ロックの前に、遅らせる段を長く取る。失敗のたびに待ち時間を倍にしていくと、機械の試行速度だけが落ちます。人が5回打ち間違えても、体感の被害は小さいままです
• 同じ端末・同じIPからの連続失敗だけをロックの対象にする。狙った他人を締め出すには、その人の端末から送る必要が出て、費用が上がります
• ロック時間を短く、解除の手段を用意する。30分の固定ではなく、数分で自動解除し、本人がメールの確認で即時に解ける道を残します
• 通知する。ロックが掛かったことを本人に伝えます。攻撃されている事実そのものが、本人にとって必要な情報です

漏れた組み合わせを試す形には、遅延だけでは足りないことがあります。1つのIDに1回しか送らないので、遅延の対象にならないためです。全体の失敗率が跳ねたときにサービス全体で追加の確認を出す、といった上位の段を併せて持ちます。

まとめ