7pay 不正利用問題 – 認証設計の基礎を軽く見た決済サービスの失敗

7pay の不正利用問題は、単なるキャッシュレス決済サービスのトラブルではなく、認証設計の基礎を軽く見た時に何が起きるのかを示した事例だと思います。当時の記事では、2 段階認証がないことと、別のメールアドレスにパスワードリセット用のメールを送れる仕様に強い違和感を持っていました。

今見ても、この違和感はかなり本質的だったと思います。決済サービスは、便利である前に、本人以外が使えないことを保証しなければなりません。そこが曖昧なままリリースされると、後から WAF や監視を足しても根本的には救いにくいです。

問題は 2 段階認証の有無だけではない

7pay 問題では、2 段階認証がなかったことが大きく取り上げられました。確かに、スマホ決済や決済アプリで追加認証がないのはかなり厳しいです。パスワードや個人情報が外部から推測・流用された場合、アカウント乗っ取りにつながりやすくなります。

ただ、本当に怖いのは「2 段階認証を付け忘れた」という単発のミスだけではありません。本人確認、端末紐付け、パスワードリセット、メールアドレス変更、チャージ、決済という一連の流れの中で、どこを信頼境界にするのかが曖昧だったことの方が大きいと思います。

個人的に特に気持ち悪かったのは、別のメールアドレスにパスワードリセット用のメールを送れるという仕様です。これは、利便性のための仕様だったのかもしれません。しかし、認証の世界では、パスワードリセットは実質的にログインと同じくらい重要です。

ログイン時の認証をどれだけ強くしても、パスワードリセット経路が弱ければ、そこが裏口になります。本人確認の強度が一番弱い場所に、攻撃者は流れます。だからこそ、リセット処理、メールアドレス変更、端末変更のような操作は、通常のログイン以上に慎重に設計する必要があります。

この件で重要なのは、脆弱な挙動が「攻撃者に突かれたバグ」というより、サービスの正式な仕様として存在していたように見える点です。仕様として許可されている動きであれば、前段に WAF や監視を置いても、正常な操作と攻撃的な操作を簡単には分離できません。

セキュリティ対策は、後付けの壁だけでは成立しません。アプリケーションの業務フロー、本人確認、権限、状態遷移、異常検知、問い合わせ対応まで含めて、最初から設計されている必要があります。認証設計が甘いままサービスを公開すると、守る側はかなり苦しくなります。

7pay の件で印象的だったのは、セブン & アイのような大企業のサービスであっても、認証の基本設計が甘ければ普通に壊れるということです。ブランド、資本力、店舗網、宣伝力があっても、システムの安全性は別問題です。

むしろ、大企業のサービスほど、利用者数が多く、決済金額も大きく、攻撃された時の影響が広がります。だからこそ、リリース速度やキャンペーンよりも、アカウント保護、被害時の停止判断、利用者への説明責任を優先すべきだったと思います。

決済サービスでは、利用者にとっての使いやすさは重要です。ただし、利便性を理由に本人確認を弱くするなら、そのリスクを誰が負うのかを明確にしなければなりません。利用者の資産に関わるサービスであれば、多少面倒でも守るべき線があります。

セキュリティは、最後にチェックリストで確認するものではなく、設計そのものです。どの操作に強い認証を要求するのか。どの状態遷移を危険とみなすのか。異常時にどこで止めるのか。そこを決めることが、サービス設計の一部であるべきです。

7pay の不正利用問題は、技術的には認証とアカウント管理の問題ですが、より広く見れば、サービス設計と責任分界の問題でもあります。誰が本人確認の強度を決めたのか。誰がリスクを評価したのか。誰がリリース可否を判断したのか。そこが曖昧な組織では、同じような失敗が起きやすいと思います。

つくづく、システムのセキュリティはひとつひとつの考慮の積み重ねです。ログイン、リセット、端末変更、決済、チャージ、停止判断。それぞれは小さな仕様に見えても、つながった瞬間に大きなリスクになります。

7pay は、キャッシュレス決済の失敗例というより、認証設計を軽く見たサービスがどう壊れるかを示した教材として記録しておきたいです。

7pay 不正利用問題 – 認証設計の基礎を軽く見た決済サービスの失敗