ハクソク

世界を動かす技術を、日本語で。

クレジットカードはブルートフォース攻撃に対して脆弱である

2026年5月2日原文(metin.nextc.org)

概要

  • PCI DSS は、クレジットカード情報の取り扱いにおける 業界標準。
  • 最小限のセキュリティ対策 しか実装されていない現状。
  • マスクされたカード情報でも 推測・悪用のリスク が存在。
  • 実際の 被害事例 を通じて、標準の限界と攻撃手法を解説。
  • 改善策や消費者が取るべき 注意点 についても言及。

PCI DSSとクレジットカード情報の現状

  • PCI DSS ：クレジットカード等の 機密データ保護 を規定する国際標準。
  • 表示可能な情報：
    • PAN（カード番号） の最初の6桁＋最後の4桁（マスク表示）
    • カード名義人
    • 有効期限
    • サービスコード
  • 表示禁止の情報：
    • フルPAN
    • カード認証コード（CVC2/CVV）
    • PINやトラックデータ
  • 企業は 認証取得のためのみ 基準を満たす傾向。
  • 実際には 最低限の対策 のみ実装、指摘されても改善しない企業が多い現状。

実際に起きた被害事例

  • 2FA（3D Secure）搭載のバーチャルカード を有名ECサイトでのみ利用。
  • SMSで不正利用の試み通知、即時パスワード変更・限度額減額など対応。
  • 6時間後、 3D Secure未対応の加盟店 で複数回にわたり全額引き出し被害。
  • eウォレット経由で現金化 され、高度な手口に驚愕。
  • チャージバック申請 により最終的に返金。

攻撃者の手口と技術的な詳細

  • 攻撃者は アカウント侵害 後、購入を試み カード情報の一部 を取得。
  • マスクされたPAN （最初の6桁＋最後の4桁）と 有効期限、銀行名を把握。
  • PANの構造 （ISO/IEC 7812）：
    • IIN（発行者識別番号） ：6〜8桁
    • 口座識別子 ：最大12桁
    • チェックディジット （Luhnアルゴリズム）
  • 16桁中 10桁が未知 だが、チェックディジットで候補は 約10万通り に絞れる。
  • 一部の銀行・ゲートウェイは カード番号だけで決済可能 な場合も存在。
  • 決済APIのレスポンス が詳細すぎる（例：「CVVが不正」「有効期限切れ」等）ため、 ブルートフォース が容易。
  • 攻撃者は複数のAPIを利用し、 6時間でカード情報を特定。
  • プロキシ利用でIP分散、リクエストレートも分散し検知困難。
  • 3D Secure非対応加盟店 の存在が被害拡大の要因。

PCI DSSの限界と現実

  • 最低限の基準 しか満たしていないと、 実質的な安全性は低い。
  • 物理レシート にも同様のリスク（マスク情報でも推測可能）。
  • 被害後の対応 ：チャージバックで返金は可能だが、根本的解決にはならない。
  • 加盟店やECサイトの対応 ：基準通りで問題なしと主張、実質的な改善意識なし。
  • 業界内でも問題の認識は広まっている が、抜本的対策は進んでいない。

消費者・開発者へのアドバイス

  • 強固なパスワード管理 ・使い回し禁止の徹底。
  • レシートやカード情報の廃棄時は裁断等で物理的破壊。
  • 3D Secure対応加盟店のみ利用 推奨。
  • カード利用明細の定期的な確認。
  • 開発者・運用者 は、PCI DSSの基準以上の対策（例：APIレスポンスの簡素化、CVCブルートフォース対策の強化）を検討。

まとめ

  • PCI DSSは最低限の基準 であり、 実際の攻撃手法には無力 な場面も多い。
  • マスク情報やAPIレスポンス の扱いが攻撃の突破口となる現実。
  • 消費者自身の自衛策 と、 業界全体の意識改革 が必要不可欠。

Hackerたちの意見

オンライン決済用に別のカードを持って、支払いに必要な分だけお金を入れておくべきだと思う。自分がちょっと naïve だって分かってるけどね :) 記事に戻るけど、弱点は3Dセキュアを使ってない別の業者に繋がるパスワードだったみたい。記事から見ると、悪い奴らは完全に自動化されたシステムを持ってるから、大手の業者は同じIPアドレスからの自動ログイン試行をちゃんと対処すべきだと思う。うちのWordfenceのログを見る限り、IPのローテーションはそんなに早くないから、いくつかの永久的なIPブロックで対処できるかも。

└

別カードには賛成だな。それが俺の別カードだったし、幸いにも金額はそんなに大きくなかったから。 >「弱点は3Dセキュアを使ってない別の業者に繋がるパスワードだった」 俺の意見だけど、パスワードが漏れたからって、クレジットカードのデータ全体が漏れるのはおかしいと思う。同じデータは市場で印刷される物理的なレシートにも載ってるし、時には4桁、時には10桁だってある。無人の物理的なレシートからブルートフォースで攻撃することも可能だしね。

└

関係ないけど、Capital OneのEnoバーチャルカードはこの目的にはうまく機能するよ。

└

正直、クレジットカードの詐欺は銀行がカバーしてくれるから、あんまり気にしてない。気になることがあったら、明細をチェックするだけ。

└

現在のシステムでのベストな解決策は、https://privacy.com だと思う。

└

Mercuryは今、個人用の銀行口座を提供してるよ。BrexやMercury、Rampみたいに、バーチャルデビットカードも作れるんだ。

└

前の銀行は、必要に応じてこのバーチャルカードサービスを提供してくれてた。特定の金額での単発購入用にカードを作るだけ。それだけなんだ。手頃な住宅ローンが受けられなくなったから、別の銀行に移ったよ。

└

なんで責任を負う必要があるの？現状で詐欺に対して責任がないなら。

以前、うちの会社に雇われた人が、ギフトカードにストアドバリューを追加する方法を見つけたって自慢してたことがあった。そしたら、その人がFBIに調査されてることが判明したんだ。しかも、その人は政府の契約者だったから、今まで見た中で一番大きなセキュリティガードが来て、彼を連れ出したよ。

└

「ギフトカードにストックされた価値を追加する」ってどういう意味？

決済処理業者は、カード番号をブルートフォースで試すこと、いわゆるカード列挙やカードテストを許可してないんだ [1][2]。カードスキームは、対策を講じない業者や決済処理業者に厳しいペナルティを課すからね [3]。 1) https://stripe.com/newsroom/news/card-testing-surge 2) https://stripe.com/blog/the-ml-flywheel-how-we-continually-i... 3) https://docs.stripe.com/disputes/monitoring-programs#enumera...

└

複数のカード検証APIを使うと、彼らが試みる率は非常に少なくなるよ。異なるPAN番号や異なるソースIPがあると、どう関連してるのか分からない。CVC2を単一のPANで列挙するのは別の話だね。

Hacker Newsで議論の続きを見る