パスワードリスト攻撃（クレデンシャルスタッフィング）への備え：ログインの運用者がやること

パスワードリスト攻撃 (クレデンシャルスタッフィング) は、他のサービスから漏れた ID とパスワードの組を、自分のサービスのログインにそのまま試す攻撃です。利用者が同じパスワードを使い回していると、自社から何も漏れていなくても入られます。備えは、多要素認証を中心に、漏えいしたパスワードの照合・レート制限・ボット対策・利用者への通知を重ねることです。根本的には、パスキーのように使い回せる秘密を持たない方式へ利用者を移し、パスワードの入口を狭めていきます。

パスワードリスト攻撃とは

OWASP は、クレデンシャルスタッフィングを「他のサイトの漏えいで得た利用者名とパスワードの組を、アカウントに対して試すこと」と説明しています。MITRE ATT&CK でも、関係の無いアカウントの漏えいデータから得た資格情報を、資格情報の重なり (使い回し) を利用して標的のアカウントに使う手口として整理されています。

よく似た攻撃と並べると、違いが分かります。

パスワードリスト攻撃は、1 つのアカウントを 1 回だけ試すことが多いのが特徴です。そのため、「同じアカウントで 5 回失敗したらロック」のようなアカウント単位の制限だけでは引っかかりにくく、別の見方が要ります。

兆候をつかむ

MITRE ATT&CK は、短い時間に 1 つの IP アドレスから、異なる利用者名とパスワードの組で失敗が続くことを、検知の手がかりに挙げています。自社のログで見ておくとよいのは次のような点です。

• ログインの試行数と失敗の割合が、普段の時間帯の傾向から外れていないか
• 存在しない利用者名への試行が増えていないか
• 同じ IP アドレスや同じネットワークから、多数の異なるアカウントへの試行が来ていないか
• 成功したログインの直後に、メールアドレスやパスワード、登録情報の変更が続いていないか

最後の点は特に重要です。攻撃者は入った後、利用者を締め出すために連絡先や認証の手段を書き換えようとします。

重ねる対策

1. 多要素認証

OWASP の Credential Stuffing Prevention Cheat Sheet は、多要素認証をパスワードに関する攻撃への最も有効な防御として最初に挙げています。パスワードが合っていても、もう 1 つの要素が無ければ入れません。

ただし、多要素認証にも強さの差があります。SMS やアプリのワンタイムパスワードは、偽サイトに入力させられれば中継されます。フィッシングまで考えるなら、フィッシング耐性のある方式 (パスキーなど) を選びます。詳しくは フィッシング耐性のある多要素認証とは で扱います。

2. 漏えいしたパスワードの照合

NIST SP 800-63B-4 は、パスワードを設定・変更するときに、よく使われるもの・推測されやすいもの・漏えいしたものを集めた一覧 (blocklist) と照合することを求めています。既に漏れているパスワードを新しく設定させないことで、リストに載る組を減らせます。同じ文書は、記号や大文字を混ぜるといった構成の規則や、定期的な変更の強制は求めないとしています。

3. レート制限

アカウント単位と、IP アドレスなど接続元の単位の両方で制限します。NIST SP 800-63B-4 は、1 つのアカウントに対する連続した認証の失敗を 100 回以下に制限することを求めています。OWASP の Authentication Cheat Sheet は、アカウントのロックが他人を締め出す嫌がらせ (サービス妨害) に使われないよう注意すること、ロック中でも復旧の手段を残すことを挙げています。

パスワードリスト攻撃は 1 アカウントあたりの試行が少ないため、接続元の単位の制限と、全体の失敗の割合の監視が効きます。

4. ボット対策

OWASP は、多要素認証を入れられない場合の補助として、CAPTCHA、IP アドレスの評価、端末や接続のフィンガープリント、JavaScript の実行を求めること、ログインを複数の段階に分けることなどを挙げ、どれも単独では多要素認証ほど有効ではないので重ねて使うよう書いています。

5. 利用者名を推測させない

ログインに失敗したときは、「利用者名かパスワードが違います」のように、どちらが違ったかを区別しない文言を返します。OWASP は、文言や応答時間の違いから、存在する利用者名を割り出されることに注意を促しています。

6. 利用者への通知

新しい端末からのログイン、パスワードやメールアドレスの変更、多要素認証の失敗が続いたときなどに、利用者へ知らせます。OWASP も、普段と違うセキュリティ上の出来事を利用者に通知することを挙げています。本人が気付いて連絡できれば、被害を早く止められます。

パスキーで攻撃の対象を減らす

ここまでの対策は、パスワードを受け付け続ける限り続く「守り」です。パスキーは、この攻撃が前提にしているものを持ちません。

• サービスごとに別の鍵が作られるため、利用者が使い回すことができない
• サーバーにあるのは公開鍵だけで、他のサービスから漏れても、自社のログインで使える文字列が無い

ただし、パスキーを登録した利用者でも、パスワードでのログインが残っていれば、攻撃者はそちらを試します。効果を出すには、次の 2 つを進めます。

1. パスキーを持つ利用者のパスワードの入口を閉じる。 期限を決めて、パスキーを登録した利用者にはパスワードの入力欄を出さない・受け付けない、と段階的に進めます。
2. パスキーの登録の入口を守る。 盗んだパスワードで入った攻撃者が自分のパスキーを登録できないよう、登録の前に既存の多要素認証や再認証を求めます。

攻撃を受けたときの初動

1. 接続元の単位で制限を強め、必要なら一時的にボット対策を厳しくする
2. 攻撃の時間帯に成功したログインを洗い出し、その利用者のセッションを無効にする
3. 該当する利用者のパスワードを再設定してもらい、連絡先の変更がされていないか確かめる
4. 利用者に、他のサービスでも同じパスワードを使っていれば変えるよう案内する

SealGate で実装する場合

SealGate はパスワードを持たず、パスワードでのログインの試行も受け取りません。パスワード側の対策 (照合・レート制限・ボット対策) は、これまでどおり開発者のログインで行います。SealGate で使えるのは、パスキーへ移す部分です。

• 管理画面の環境の設定で「パスワードでのログインの期限」を決めると、期限を過ぎた後、パスキーを登録した利用者のログインの応答 (POST /v1/login/verify) で password_allowed: false が返ります。パスワードの入力欄を隠すかどうかの判断に使えます。
• 既にパスキーを持つ利用者に鍵を足すには、/v1/register/options に signed_in: true か recovery_token が要ります。signed_in は、開発者のサーバーがログイン済みの本人であることを確かめてから付けます。
• 乗っ取りが疑われる利用者は、POST /v1/users/{external_id}/revoke でパスキーをすべて失効できます。
• パスキーの登録・ログインの成否は、監査ログ (IP・User-Agent 付き) と Webhook (login.failed など) で確かめられます。

詳しくは ドキュメント をご覧ください。

よくある質問

自社から漏えいしていなくても狙われますか？

狙われます。パスワードリスト攻撃に使われるのは他のサービスから漏れた組で、利用者が同じパスワードを使い回していれば、自社のログインでも通ってしまいます。

アカウントのロックだけで防げますか？

十分ではありません。この攻撃は 1 アカウントあたりの試行が少ないため、アカウント単位のロックにかかりにくく、接続元の単位の制限や多要素認証と組み合わせる必要があります。

パスキーを入れればパスワードの対策は要りませんか？

パスワードでのログインが残っている間は要ります。パスキーを持つ利用者のパスワードの入口を閉じた分だけ、対策が要る範囲が狭まります。

出典

• Credential Stuffing Prevention Cheat Sheet（OWASP）
• Authentication Cheat Sheet（OWASP）
• Brute Force: Credential Stuffing, T1110.004（MITRE ATT&CK）
• NIST SP 800-63B-4 Digital Identity Guidelines: Authentication and Authenticator Management（NIST, 2025-08）
• FIDO Passkeys: Passwordless Authentication（FIDO Alliance）