Credential Stuffing: 他サイトの漏洩があなたのサイトのログインに影響する仕組み

あなたのアプリケーションは堅牢なセキュリティアーキテクチャ、暗号化されたデータベース、定期的なペネトレーションテストを備えているかもしれません。それでも、攻撃者はコードの脆弱性を突かずにユーザーアカウントを侵害できることがあります。その原因は？Credential stuffing（クレデンシャルスタッフィング）—パスワードの使い回しというセキュリティの弱点を突く攻撃手法です。

Credential Stuffingの脅威を理解する

Credential stuffingは、悪意のある攻撃者が自動化ツールを使って、盗まれたユーザー名とパスワードのリストを大量にログインエンドポイントに対して試行するサイバー攻撃手法です。単一のアカウントに対して異なるパスワードを試すブルートフォース攻撃とは異なり、過去のデータ漏洩から盗まれた実際の認証情報を利用します。

この攻撃の数学的な背景は衝撃的です。最近のデータによると、攻撃者は月に約260億回のcredential stuffing試行を行っており、わずか18ヶ月で約50%増加しています。2025年のVerizon Data Breach Investigations Reportによると、2024年のハッキング侵害の88%は盗まれたまたはブルートフォースされた認証情報に起因しています。より具体的には、昨年の全データ漏洩の22%は盗まれた認証情報が原因です。

この攻撃ベクトルが依然として広く使われる理由は、経済的な側面にあります。漏洩した認証情報の組み合わせは非常に安価で、千件あたり数円程度で入手可能です。自動化ツールの普及により、スキルの壁も低くなっています。成功率は約0.1%程度でも、膨大な認証情報の量により、攻撃者にとっては経済的に成立します。

ユーザーのパスワード習慣が問題となる理由

credential stuffingの成功の根底には、人間の習慣—パスワードの使い回し—があります。セキュリティ意識向上のキャンペーンが長年行われているにもかかわらず、ユーザーは複数のサービスで同じ認証情報を使い続けています。あるサービスでデータ漏洩が起きると、そのユーザーが再利用した他のサービスも危険にさらされます。

例を挙げると、ユーザーがあなたのECサイトにメールアドレス user@example.com とパスワード “Summer2024!” でアカウントを作成したとします。彼らは気付かずに、その組み合わせをフォーラムに使っていて、そのフォーラムが後にデータ漏洩した場合、そのデータは闇市場や公開リークに流出します。攻撃者はこれらの認証情報を自動化ツールに入力し、あなたのサービスを含む何千ものサービスにログインを試みます。

あなたのアプリケーションのセキュリティは、ユーザーが持つ他のサービスのアカウントの安全性に依存しています。これがcredential stuffingの厳しい現実です。あなたは他所で起きた侵害に対して、防御策を講じているわけです—それはあなたのコントロール外のインフラに対して、ユーザーの決定によるリスクを守ることです。

Credential Stuffingの仕組み

現代のcredential stuffingは、高度なツールとインフラを駆使した巧妙な攻撃です。攻撃手法を理解することは、防御策の構築に役立ちます。

攻撃インフラ

攻撃者は通常、ボットネットやリモートプロキシサービスを使って、何千ものIPアドレスからログイン試行を分散させます。これにより、リクエストの発信元だけで攻撃を検知・遮断するのは困難になります。ある攻撃では、1つのキャンペーンで20万以上のIPアドレスを使用し、それぞれが少数の試行を行います。

自動化された認証ツール

OpenBullet、SNIPR、Sentry MBAなどの専用ツールが存在し、これらはユーザーフレンドリーなインターフェースで認証情報リストの読み込みやログインシーケンスの設定、プロキシの回転管理を行います。これらのツールには、次のようなセキュリティ対策を回避するための機能もあります：

• サードパーティのサービスを使った自動CAPTCHA解決
• ブラウザのフィンガープリントのランダム化
• リクエスト間の人間らしい遅延
• セッション管理による認証フローの制御
• 有効な認証情報を識別するパターン認識

攻撃の流れ

典型的なcredential stuffingの流れは以下の通りです：

1. 認証情報の入手：過去の漏洩やダークウェブマーケットから購入、公開リポジトリからダウンロード
2. ターゲット設定：あなたのログインエンドポイントURLと必要なパラメータ（ユーザ名、パスワード、CSRFトークンなど）を設定
3. プロキシ設定：リモートプロキシや感染したデバイスネットワークを使い、IPアドレスを分散
4. 自動テスト：ツールが認証情報を一つずつ試し、成功・失敗を解析
5. アカウントの獲得：成功したアカウントはリスト化され、直接の悪用や再販売に使われる

実世界への影響

credential stuffingの成功は、単なるアカウント乗っ取りにとどまりません。2024年には、Rokuが2回のcredential stuffing攻撃により、59万1千の顧客アカウントが侵害されました。これらは理論的な脆弱性や概念実証ではなく、実際にユーザーが他の漏洩サービスのパスワードを使い回した結果です。

credential stuffingはログインだけにとどまりません。攻撃者はアカウントにアクセスした後、次のような行動を取ります：

• 保存された支払い情報の窃盗と不正購入
• 個人情報を使った身分盗用
• ポイントやクレジットの不正利用
• 組織に関する情報収集
• 正規アカウントを使ったより高度な攻撃
• アカウント情報の改ざん
• ソーシャルエンジニアリング攻撃に利用できるデータの抽出

経済的な損失は甚大です。詐欺取引による直接的な損失、インシデント対応やフォレンジックのコスト、データ保護違反に伴う規制罰金、顧客への補償、そして長期的な評判ダメージがユーザートラストや新規獲得に影響します。

開発者側の防御策

他のサービスの漏洩やユーザーのパスワード使い回しをコントロールできなくても、複数の防御層を実装することでcredential stuffingのリスクを大きく低減できます。

多要素認証（MFA）

MFAはcredential stuffingに対する最も効果的な防御策の一つです。攻撃者が有効な認証情報を持っていても、適切に実装された二次認証を突破できません。特に、TOTP（Time-based One-Time Password）を使ったアプリの認証コードは強力です。SMS認証は中程度の保護を提供しますが、SIMスワッピング攻撃には脆弱です。プッシュ通知やハードウェアセキュリティキーは最も堅牢ですが、コストや導入のハードルがあります。

実装戦略も重要です。パスワード変更や支払い情報更新、機密データアクセス時にはMFAを必須にし、リスクベースのMFAを導入して、不審なアクセスには追加の認証を要求することも検討してください。

インテリジェントなレートリミティング

単純なIPアドレスベースのレートリミットは、攻撃者がプロキシを使って分散させると効果が薄れます。多次元のレートリミティングを導入しましょう：

• IPごとの制限：一定の試行回数を超えた場合に制限。ただし、共有ネットワークの正当なユーザーに影響しない範囲で設定
• アカウントごとの制限：IPに関係なく、特定アカウントの失敗回数を制限
• 速度監視：認証リクエストの全体的な速度を監視し、急激な増加を検知
• 失敗率分析：失敗と成功の比率を追跡し、異常を検知

これらの閾値超過時には、CAPTCHAを表示したり、一時的にアカウントをロックしたりします。正当なユーザーには通知を送ることも重要です。

パスワード漏洩チェックAPI

既知の漏洩パスワードと照合できるAPIを利用するのも効果的です。Have I Been Pwned（HIBP）のPwned Passwords APIは、パスワードのプライバシーを保護しつつ、漏洩済みかどうかを確認できます。仕組みは以下の通りです：

1. パスワードをSHA-1でハッシュ化
2. ハッシュの最初の5文字だけをAPIに送信
3. APIは、その先頭5文字に一致するハッシュ一覧を返す
4. アプリは完全なハッシュがリストにあるか確認

この方法により、実際のパスワードや完全なハッシュは送信されず、プライバシーを守りながら漏洩チェックが可能です。

登録時やパスワード変更時に漏洩チェックを行うことで、既知の漏洩パスワードの使用を未然に防げます。ログイン時に漏洩パスワードを使った場合は、強制的にパスワードリセットを促す仕組みも有効です。

高度なボット検出と行動分析

最新のcredential stuffingツールは人間の動作を模倣しようとしますが、微妙な指標で自動化を見抜くことも可能です。行動分析を導入しましょう：

• タイミングパターン：人間は自然な速度と間隔でタイピングしますが、ボットは一定の間隔や高速な入力を示すことがあります
• マウス動作と操作：正規ユーザーはページ内を動き回り、クリックや修正を行いますが、ボットは直線的にフォームに向かいます
• ブラウザフィンガープリント：ユーザーエージェントや解像度、フォント、Canvasフィンガープリント、WebGLパラメータの組み合わせで判別
• セッションの挙動：ボットはページ読み込み直後にログイン試行を行うことが多いが、人間はページを観察しながら操作します

リスクスコアに基づき、CAPTCHAを選択的に表示することで、正規ユーザーの体験を損なわずに自動化を阻止できます。

アカウントロックと通知

疑わしい認証活動を検知した場合は、アカウントを一時的にロックし、ユーザーに通知を送ることが重要です。例えば、複数のIPからの失敗や、正しいユーザ名でのパスワード間違いなどです。通知には、活動の詳細と、本人確認のための簡単な手順を含めると効果的です。

監視と検知システム

攻撃パターンを早期に察知するために、認証イベントのログと監視を徹底しましょう：

• ログにはタイムスタンプ、IP、ユーザーエージェント、アカウントID（失敗も含む）、成功・失敗のステータス、セキュリティ対策のトリガー情報を記録
• ダッシュボードやアラートを設定し、リアルタイムでcredential stuffingの兆候を監視
  • 突然のアクセス増加
  • 失敗率の上昇
  • 同一IPからの複数アカウントターゲット
  • 不自然な地理的分布
  • 高速な試行
  • 類似ユーザ名の連続試行

これらを検知したら、CAPTCHA強化やレートリミットの厳格化、緊急のMFA適用などの対策を迅速に行います。

セキュリティヘッダーとログインページの保護

認証エンドポイントには以下の対策を実施しましょう：

• HTTPSを徹底し、認証情報の盗聴を防止
• CSRFトークンを導入
• CORSポリシーを適切に設定
• Content-Security-Policyなどのセキュリティヘッダーを設定

また、エラーメッセージは「ユーザ名またはパスワードが違います」のみとし、アカウントの列挙を防止します。honeypotフィールドを設置し、ボットの自動送信を検知するのも有効です。

深層防御戦略の構築

単一の防御策だけではcredential stuffingに対抗できません。複数の防御層を重ねることが重要です。

まずは、レートリミット、パスワード漏洩チェック、監視を導入し、即効性のある防御を確立します。その後、行動分析や選択的CAPTCHAを導入し、正規ユーザーの負担を最小限にしつつ攻撃を阻止します。最後に、ユーザー教育やインセンティブを通じてMFAの普及を促進しましょう。

定期的に認証ログを分析し、攻撃手法のトレンドを把握し、自社インフラに対して模擬credential stuffingテストを行うことも有効です。

まとめ

credential stuffingは、あなたの管理外のシステムや、ユーザーが意図せず使い回すパスワードを前提とした根本的なセキュリティ課題です。その持続性は、ユーザーがパスワードを再利用し続ける限り続きます。セキュリティ意識向上だけでは防ぎきれません。開発者やセキュリティ担当者は、MFAやレートリミティング、漏洩パスワードAPI、行動分析、監視を組み合わせて、防御策を強化すべきです。

攻撃者はAIを使ったツールも試しており、リアルタイムで適応しながら進化しています。常に最新の情報を追い、セキュリティ対策を見直すことが求められます。あなたのアプリの安全性は、ユーザーの最も弱いパスワードに依存しています—それを断ち切る防御策を導入しましょう。ツールと技術は存在します。あとは、それを実装するかどうかの問題です。