Webサービスやシステムを作っていると、ログイン失敗が続いたらアカウントをロックするかどうかを決める場面が出てきます。何回でロックするのが正しいのか、公的なガイドラインをひととおり読んでみました。回数を書いている資料と書いていない資料に分かれていて、書いてある数字も3回から100回までばらついています。
NISTは上限を100回
回数が書いてある資料の1つが、NIST SP 800-63B の 5.2.2 Rate Limiting (Throttling) です。以下、英語の資料からの引用はすべて筆者による訳です。
認証子の種類ごとの記述で求められる場合、検証者はオンライン推測攻撃から保護する制御を実装しなければならない（SHALL）。個々の認証子の記述で別途定められていない限り、検証者は、単一のアカウントに対する連続した認証失敗を100回以下に制限しなければならない（SHALL）。
100回です。しかもこれは「これ以下にしろ」という上限であって、推奨値ではありません。
続く段落は、正当な利用者を締め出す確率を下げる技法をMAYで並べています。認証前にCAPTCHAを解かせる、上限に近づくほど失敗後の待ち時間を伸ばす、過去に認証に成功したIPアドレスからの要求だけを受け付ける、リスクベースや適応型の認証。待ち時間には30秒から1時間まで、という例が付いています。認証に成功したら、同じIPアドレスからの過去の失敗は無視してよい（SHOULD）ともあります。
ロックを解除するまでどれくらい待たせるかは書いてありません。NISTのFAQも開きましたが、ロックアウトを扱った項目はなく、レート制限は他の項目から5.2.2への参照として出てくるだけでした。
読んだのは rev.3 で、2017年6月版に2020年3月までの正誤表が入ったものです。改訂が進んでいるので、100という数字が残るかどうかは最終版で読み直すことになります。読み直した結果は末尾に追記しました。
OWASPの認証チートシートは回数を書いていない
Authentication Cheat Sheet は、アカウントロックアウトを「これらの攻撃に対する最も一般的な防御」と呼びます。ところが回数はどこにも書いてありません。書いてあるのは、決めるべき値が3つあるということです。
セキュリティと使い勝手の釣り合いを取るために、アカウントロックアウトのポリシーを実装するときに考慮すべき要素がいくつかある。
- アカウントがロックアウトされるまでの失敗回数（ロックアウトのしきい値）
- それらの失敗を数える期間（観測ウィンドウ）
- アカウントをロックアウトしておく時間の長さ（ロックアウト時間）
数字の代わりに書いてあるのは、決め方です。ロック時間を固定にせず、1秒のような非常に短い時間から始めて失敗のたびに倍にしていく指数的なロックアウトを使うアプリケーションもある、とあります。固定にする場合の例として挙がっているのは10分です。
失敗回数のカウンターは、送信元IPアドレスではなくアカウントそのものに紐付けろ、とも書いてあります。多数のIPアドレスから試されると、IPアドレスごとに数えたカウンターは意味を失うからです。
そのうえで、ロックアウト自体が攻撃に使えることにも触れています。
アカウントロックアウトの仕組みを設計するときは、他の利用者のアカウントをロックアウトしてサービス妨害を引き起こす手段として使われないよう、注意を払わなければならない。
対処の例として挙がっているのは、アカウントがロックアウトされていても、パスワード再設定の機能からはログインできるようにしておくことです。
ASVSは5.0で数値が消えた
同じOWASPの ASVS 4.0.3 には数字がありました。要件 2.2.1 は L1 から L3 まで共通で、こう終わります。
単一のアカウントに対して、1時間あたり100回を超える失敗ができないことを検証する。
2025年5月30日にリリースされた 5.0 では、この数字がありません。認証の章でパスワードの総当たりとクレデンシャルスタッフィングを名指しした要件は2つで、どちらにも回数はありません。
6.1.1 レート制限、自動化対策、適応的な応答といった制御が、クレデンシャルスタッフィングやパスワードの総当たりのような攻撃を防ぐためにどう使われるかを、アプリケーションのドキュメントが定義していることを検証する。ドキュメントは、これらの制御がどう設定されているか、そして悪意あるアカウントロックアウトをどう防ぐかを明確にしなければならない。
6.3.1 クレデンシャルスタッフィングやパスワードの総当たりのような攻撃を防ぐ制御が、アプリケーションのセキュリティドキュメントに従って実装されていることを検証する。
同じ団体の同じ標準で、しきい値が「1時間あたり100回」から「自分のドキュメントに書いたとおり」へ変わりました。しかも 6.1.1 は、そのドキュメントに悪意あるアカウントロックアウトの防ぎ方まで書けと要求しています。ロックアウトは守る手段であると同時に、防ぐ対象でもあります。
クレデンシャルスタッフィングでは失敗回数を数えない
OWASPには Credential Stuffing Prevention Cheat Sheet が別にあります。認証チートシートは、クレデンシャルスタッフィングとパスワードスプレーへの対処はそちらを見ろと案内しています。
対策を並べた節の見出しはこうです。多要素認証、代替の防御、多層防御とメトリクス、二次パスワードとPINと秘密の質問、CAPTCHA、IPによる緩和とインテリジェンス、デバイスのフィンガープリント、接続のフィンガープリント、推測しにくいユーザー名の要求、多段階のログイン処理、JavaScriptの要求とヘッドレスブラウザーの遮断、機能の段階的な縮退、漏えいしたパスワードの特定、異常なセキュリティイベントの利用者への通知。
失敗回数でロックする対策が入っていません。アカウントをロックするという話は全文で1箇所だけ出てきますが、きっかけが違います。
ネットワーク接続を遮断することとは別に、アカウントごとにIPアドレスの認証履歴を保存することを検討するとよい。直近のIPアドレスが遮断や緩和の対象リストに載った場合には、アカウントをロックして利用者に通知するのが適切なこともある。
数えているのは失敗回数ではなく、そのアカウントが最近使ったIPアドレスの評価です。認証チートシートが「最も一般的な防御」と呼んだ数え方は、クレデンシャルスタッフィングを扱うこの文書では対策として出てきません。
Microsoftは製品ごとに既定値が違う
Entra ID の smart lockout には、はっきりした既定値があります。
既定では、smart lockout は次の回数の失敗でアカウントをロックし、サインインできないようにする。
- Azure Public および 21Vianet が運営する Microsoft Azure のテナントでは10回の失敗
- Azure US Government のテナントでは3回の失敗
ロック時間は最初が1分で、以後は伸びます。伸び方は公開されていません。
攻撃者がこの挙動を回避する手段を最小限にするため、サインインの失敗が続いたときにロックアウトの期間がどの割合で伸びるかは開示しない。
直近3つの誤ったパスワードのハッシュを覚えていて、同じパスワードを何度入れてもカウンターは進みません。見慣れた場所と見慣れない場所で別々のカウンターを持ちます。
同じMicrosoftでも、Windowsのローカルポリシーは違います。Account lockout threshold の既定値は0で、これはロックしないという意味です。Windows security baselines の推奨値が10です。そしてドキュメントには、0のままにすることが2つの対策案のうちの1つとして正面から書いてあります。
この値が設定されている場合にも設定されていない場合にも脆弱性が存在しうるため、2つの異なる対策を定義する。組織は、特定した脅威と緩和したいリスクに基づいて、この2つのどちらを取るかを判断すべきである。
0を選んでよい条件も書かれています。全利用者に8文字以上の複雑なパスワードを要求していること、失敗の連続が起きたときに管理者へ知らせる堅牢な監査の仕組みがあること。この2つが明示的に満たされる場合に限る、とあります。
10を選ぶほうの説明には、うっかりロックされることが減ってヘルプデスクへの問い合わせが減る一方、サービス妨害は防げないと並べて書かれています。
日本の資料はロックアウトで止まらない攻撃を先に書く
IPAの安全なウェブサイトの作り方 改訂第7版をみたところ、ロックアウトへの言及は1箇所だけでした。その1箇所は「2.7 携帯ウェブ向けのサイトにおける注意点」の中にあり、4桁の暗証番号のように組み合わせの数が少ない認証情報を扱う流れの途中に出てきます。しかも否定の文脈です。
以下、日本語の資料からの引用は原文の表記のまま載せます。
ウェブでは多くの場合、試行回数を確実に制限することは困難です。たとえば、
試行回数を制限する単純な方法として、あるユーザ ID に対するパスワードの
間違いが一定回数を超えた場合には、アカウントをロックするといった対策が
考えられますが、このような単純な対策では、パスワードを固定してユーザ ID
を変更する方式の試行（リバースブルートフォース）に効果がありません。この記述があるのは携帯電話向けの節ですが、書き出しはウェブ一般を指していて、携帯に限定していません。それでも、一般のウェブアプリケーションを扱う章にロックアウトの記述はなく、第7版の全体でここ1箇所です。
総務省のリスト型アカウントハッキングによる不正ログインへの対応方策については、サイト管理者向けにロックアウトを対策として挙げています。ただし、回数は書いてありませんでした。
認証エラーのログを監視し、同一のＩＤに対して一定の閾値以上の認証エラーが
発生した場合に、そのアカウントを一時停止する措置を講じることも有効です。「一定の閾値」です。そのしきい値の限界は、次の節にあります。
攻撃の中には、１つのＩＤに対するパスワードの試行回数が１、２回にとどまる
ものもあり、必ずしも一つのＩＤにおける認証エラーの閾値を超えない攻撃も
存在します攻撃の総量が増えても、1つのIDあたりの回数はしきい値を下回ったままです。数えているのがアカウントごとの失敗回数だからです。
同じ文書のメリット・デメリット表で、ロックアウトのデメリットに挙がっているのはシステム改修と、もう1つです。
アカウントロックアウトに関するシステム改修や利用者の同意取得などのコスト
が生じる。システム改修は分かります。もう1つの利用者の同意取得は、他の資料に出てきませんでした。本文を読むと、アカウントが止まって一時的にサービスを使えなくなることを、あらかじめ利用者に了解してもらっておくとよい、とあります。ロックアウトを利用規約の問題として書いた資料は、読んだ中でここだけです。
IPAが10回と書いていたのは2007年
IPAの資料でも回数が書いてあるものがありましたが、2007年6月28日に公開されたアーカイブです。認証を自分で実装する場合を扱ったそのページに「アカウントのロックアウト」という見出しがあり、そこに数字が出てきます。先頭には「本ページの情報は2007年6月時点のものです」と注記があります。
例えば、あるアカウントに対するログインが10回連続して失敗した場合に、その
アカウントのログインを数時間禁止する。同じ見出しの下には「ログイン失敗回数やロックアウト期間は、利用上の利便性との兼ね合いにより設定する。」ともあります。現行の「安全なウェブサイトの作り方」に、この記述はありません。
NISCは措置を求めるが、回数は書かない
政府機関等の対策基準策定のためのガイドライン（令和5年度版）の遵守事項 7.1.1(1)(c) は、措置そのものを求めます。
情報システムセキュリティ責任者は、主体認証を行う情報システムにおいて、
主体認証情報の漏えい等による不正行為を防止するための措置及び不正な主体
認証の試行に対抗するための措置を講ずること。「講ずること」なので、これは義務です。ではどう講じるかというと、解説には機能が4つ例として並びます。前回のログインに関する情報の通知、不正なログインの検知または防止、リスクベース認証、ログイン時のメッセージ表示。ロックアウトに当たるのは2つ目です。
特定の識別コードによるログインにおいて、指定回数以上の主体認証情報の誤入力
が検知された場合に、その旨を正当な主体や情報システムの運用担当者等に通知し、
一定期間当該端末（又は識別コード）からのログイン操作受付を停止する機能を指す。「指定回数」で、回数も期間も書かれていません。4つのうちの1つなので、ロックアウトを選ばなくても遵守事項は満たせます。
脆弱性診断の資料には数字がある
ここまでは要件を定める資料でした。診断の手順書になると、数字が出てきます。
OWASPの Web Security Testing Guide には、弱いロックアウトの仕組みを検査する項目があります。その冒頭に数字が出てきます。
アカウントは、通常3回から5回の失敗でロックされ、あらかじめ決められた時間の経過後、セルフサービスのロック解除の仕組み、または管理者の介入によってのみ解除できる。
検査手順にも、テスターが打つ回数と待つ時間が並んでいます。実装する人への助言としては、別の数字が出てきます。
アプリケーションの目的にもよるが、5回から10回の失敗が典型的なロックアウトのしきい値である。
例えば5分から30分のロックアウト時間なら、総当たり攻撃を抑えることと正当な利用者に不便を強いることの折り合いとして、ちょうどよい場合がある。
同じページの中で、実態の記述が3回から5回、しきい値の目安が5回から10回と、範囲がずれています。どちらにも出典が付いていません。ページの参考文献はOWASPの総当たり攻撃の解説と Forgot Password Cheat Sheet の2つで、この数字の根拠にはなっていません。
日本にも診断の資料があります。IPAのウェブ健康診断仕様は「安全なウェブサイトの作り方」の別冊で、認証の診断項目に検出パターンと判定基準を並べています。ロックアウトはその6番目です。
意図的に 10 回パスワードを間違える アカウントロックされない場合左が検査で打つ回数、右が脆弱性ありと判定する条件です。10回間違えてもロックされなければ、指摘が付きます。
一方、脆弱性を分類する資料に数字はありません。CWE-307 は「製品が、短い時間のうちに認証の失敗が何度も起きることを防ぐ十分な手立てを実装していない」と定義し、よくある保護の仕組みとして「数回失敗した時点で利用者の接続を切る」「タイムアウトを実装する」「狙われたアカウントをロックアウトする」「利用者に計算処理をさせる」を挙げますが、回数は書きません。
CAPEC-49 も同じです。緩和策は3つ挙がっていて、この記事の主題に近いのは「IPアドレスとログイン名の両方を考慮したパスワードのスロットリングの仕組みを実装する」ですが、何回で絞るかは書かれていません。残りは強固なパスワードポリシーを定めることと、パスワードを定期的に変更させることです。
細かい数字が出てくるのは、検査の手順を書いた資料と、既定値を持つ製品のドキュメントでした。要件そのものを定める資料は、100と書くか、何も書かないかのどちらかです。
どの資料が何を書いていたか
ここまでに開いた資料を、回数とロック時間、そしてロックアウトの扱いで一覧にします。
| 資料 | 回数 | ロック時間 | 扱い |
|---|---|---|---|
| NIST SP 800-63B rev.3 | 連続100回以下 | 記載なし | SHALL |
| OWASP Authentication Cheat Sheet | 記載なし | 記載なし | 最も一般的な防御 |
| OWASP ASVS 4.0.3 | 1時間あたり100回以下 | 記載なし | L1からL3まで共通 |
| OWASP ASVS 5.0 | 記載なし | 記載なし | 自分のドキュメントどおりに |
| OWASP Credential Stuffing Prevention Cheat Sheet | 失敗回数では数えない | 記載なし | 失敗回数でのロックを挙げていない |
| Microsoft Entra ID smart lockout | 既定10回、US Governmentは3回 | 最初は1分、以後は伸びるが伸び方は非公開 | 常時有効 |
| Windows の Account lockout threshold | 既定0、ベースライン推奨10 | 別のポリシー | 0も対策案の1つ |
| IPA 安全なウェブサイトの作り方 改訂第7版 | 記載なし | 記載なし | 携帯ウェブの節に否定的な言及が1箇所 |
| IPA アーカイブ 2007年 | 10回連続 | 数時間 | 例示 |
| 総務省 リスト型攻撃の対応方策 | 一定の閾値 | 記載なし | 有効 |
| NISC 対策基準ガイドライン 令和5年度版 | 指定回数 | 一定期間 | 措置は遵守事項 |
| OWASP Web Security Testing Guide | 実態は3〜5回、目安は5〜10回 | 5〜30分 | 出典なしの目安 |
| IPA ウェブ健康診断仕様 | 10回 | 記載なし | ロックしなければ指摘 |
| CWE-307 | 記載なし | 記載なし | 保護の仕組みを列挙 |
| CAPEC-49 | 記載なし | 記載なし | スロットリングを推奨 |
食い違いはどこから来ているか
資料を性格ごとに分けて、書いてある回数を目盛りの上に置き直します。
要件を定める資料は11件のうち8件が、回数そのものを書いていません。数字が3回から10回に集まっているのは診断の手順書と製品のドキュメントで、要件を定める資料から出てきた数字は100回が2件、それと2007年のアーカイブの10回だけです。
10回と100回のあいだを選んだ資料は、どの性格の資料にもありませんでした。
割れ方をたどると、資料ごとに見ている相手が違います。
NISTの100は、検証者に課す上限です。無制限に試させるなという線を引いているのであって、100回まで試させろでも、100回で止めろでもありません。
MicrosoftのEntra IDとWindowsの数字は、組織のディレクトリのものです。Entra ID のドキュメントが既定値について書いているのは、セキュリティと使い勝手の釣り合いが取れている、ということだけです。Windowsのほうは、しきい値を設けるとヘルプデスクへの問い合わせが増えることを繰り返し書いています。だから推奨は10で、既定に至ってはロックしません。
IPAと総務省が見ているのは、リスト型攻撃と逆総当たりです。どちらも、アカウントごとの失敗回数を数えている限りロックアウトは作動しません。回数を書かないのではなく、回数を決めても届かない攻撃の話をしています。
診断と製品のドキュメントに細かい数字があるのは、そこで数字が要るからです。IPAの健康診断仕様は「意図的に10回パスワードを間違える」と書かなければ検査になりませんし、Entra ID は既定値を持たなければ動きません。要件を定める資料は、判定できる条件さえ書ければよく、数字を1つ選ばずに済みます。
ASVS 5.0 が数値をやめて「自分のドキュメントどおりに」へ変えたのも、この事情に沿った変更です。数字を1つ決めて示すことを、標準そのものがやめました。
数字以外は食い違っていない
読んだ範囲で、回数を1つに決められる根拠は出てきませんでした。一方で、資料をまたいで同じことを言っている点はいくつかありました。
- 失敗回数のカウンターはIPアドレスではなくアカウントに紐付ける（OWASP Authentication Cheat Sheet）
- ロックアウト自体がサービス妨害の手段になる（OWASP Authentication Cheat Sheet、ASVS 5.0 の 6.1.1、Windows）
- ロックされた利用者が復帰する手段を用意する。OWASPはパスワード再設定の機能からのログイン、Entra ID はセルフサービスのパスワードリセット、総務省は正規の利用者の求めによる解除、NISCの例は一定期間が過ぎたら受付を再開すること
- 認証に成功したら失敗のカウンターをリセットする（NIST）
回数は割れましたが、この4つは割れていません。
数える対象を変えても、回数は書かれていない
回数を書いていた資料は、どれも1つのアカウントに対する連続した失敗を数えていました。しきい値をいくつにするかという議論は、その数え方を前提にしています。
数える対象を移す案も読めました。総務省の対策集が挙げているのは、1つのIPアドレスからしきい値以上の数のアカウントへログイン要求が来たら、そのIPアドレスからのアクセスを遮断する方法です。これを「リスト型攻撃に対する対応策としては非常に有効な対策と言えます」と評価しています。
OWASPのクレデンシャルスタッフィングのチートシートにも、IPアドレスの分類や地理情報でしきい値を上下させるという節があります。
移した先でも、回数は書かれません。OWASPは書かない理由まで書いています。
IPアドレスから来るクレデンシャルスタッフィングの通信を緩和する（遮断とCAPTCHAを含む）処理や判断は、多数の悪用のシナリオを考慮すべきであって、値が読めてしまうような単一の通信量のしきい値だけに頼ってはならない。
同じ節には、クレデンシャルスタッフィングのツールキットがプロキシーのネットワークで要求を大量のIPアドレスへ分散させるため、IPのブロックリストもレート制限も破られうる、とあります。総務省も同じ限界を書いています。
なお、ＩＰアドレスは、個々のネットワーク接続に対して異なるものが割り当てられる
ので、攻撃を行ってきた特定のＩＰアドレスのみを遮断するだけでは、攻撃者がネット
ワーク接続を切り替えて別のＩＰアドレスから攻撃を再開することも考えられます。総務省が挙げる対処は、発信元のIPアドレスを事業者間で共有してリアルタイムに対策を講じることです。1社で完結する話ではなくなります。
回数を1つに決められなかったのは、読んだ資料が足りなかったからではありませんでした。数える対象をアカウントに置いてもIPアドレスに置いても、要件を定める資料は数字を書きません。
追記（2025年8月4日）rev.4 でも100回のまま
2025年7月31日に NIST SP 800-63B-4 の最終版が公開されました。本文で「読み直す」と書いた箇所を確かめたので、結果を追記します。
レート制限の節は、rev.3 の 5.2.2 から 3.2.2 へ移りました。回数は変わっていません。
検証者は、オンライン推測攻撃から保護する制御を実装しなければならない（SHALL）。個々の認証子の記述で別途定められていない限り、検証者は、特定の認証子を使った単一の加入者アカウントに対する連続した認証失敗を、その認証子を無効にすることによって100回以下に制限しなければならない（SHALL）。
数える単位のほうは変わりました。rev.3 は「単一のアカウントに対する連続した認証失敗」を数えていましたが、rev.4 は特定の認証子を使った失敗に限定し、上限に達したときに止めるのはアカウントではなくその認証子です。無効にされた認証子をまた使えるようにするには、改めてアカウントへ結び付け直せと求めています。過剰な試行に認証子が2つ以上関わっていた場合は、いずれも無効にしろとあります。
生体認証の数字は rev.3 にもありました。連続5回、提示攻撃検知を実装している場合は10回を超えたら30秒以上の遅延、というところまでは同じです。
rev.4 の 3.2.3 で加わったのは、その先の上限です。遅延を挟んでもなお失敗が続いて50回、提示攻撃検知ありなら100回に達したら、生体認証を無効にして、代わりの認証要素が既にあるならそちらを使えるようにしろ、となっています。rev.4 には「全体の上限」とありますが、数えているのはここでも連続した失敗です。
rev.3 はこの上限を置かず、遅延を指数的に伸ばすか、生体認証を無効にするかの二択でした。
本文に並べた食い違いは、この改版でも解消していません。100という数字はそのままで、OWASPの認証チートシートもASVS 5.0も、回数を書かないままです。
同じ資料を、パスワードの文字種と最小長という切り口で読んだ記事もあります。
ブログパスワードに大文字と記号、まだ必要？パスワードに大文字・小文字・数字・記号を混ぜろという要件について、公的なガイドラインの原文を読みました。文字種を混ぜさせるかどうかは、その文書が誰に向けて書かれているかで分かれます。最低文字数は、資料によって8から15まで開きがあります。定期変更を求めるなという点だけは、読んだ資料が一致していました。