我们把真实发生的公开安全事故，不当作新闻的重播，而是从 「你要如何防住它？」 的视角来解读。本文基于 公开记录（企业公告、监管机构、可信报道）。出处列于文末，且不包含任何攻击手法。
- 目标
- 「7pay」支付应用中的用户账户（运营方：7pay 株式会社／Seven & i 控股旗下）
- 发现
- 2019 年 7 月 2—3 日（上线后不久即察觉未授权访问）
- 影响规模
- 约 808 名用户、约 3,862 万日元盗刷（件数后经调查精确）
- 根本原因
- 无 2FA（仅 ID＋密码）＋ 密码重置可发往未登记邮箱 ＋ 对撞库抵抗力薄弱 ＋ 外部 ID（7iD）对接的设计不足 ＋ 上线前对认证流程的评审不充分
- 真正的对策
- 对重要操作强制 2FA、把密码重置限定为已登记的渠道、检测/锁定撞库、上线前评审认证流程
发生了什么（用平实的话说）
一款手机支付应用握有 动你钱的权限。这就使得「只有真正的所有者能登录，别人都不能」——也就是认证设计——成为关键所在。7pay 在这里很薄弱：它的防守实际上只是 一枚密码。
有两个问题叠加在一起。第一，没有 双因素认证（2FA）：只要 ID 和密码对上就能进去——所以这款应用对 撞库 很脆弱，攻击者会拿从其他服务泄露的 ID／密码来逐一尝试。第二，是 密码重置 的设计：新密码可被发送到 登记邮箱以外的地址，因此只要持有零散的个人信息（出生日期、电话、邮箱），即便不是真正的所有者也能替换掉密码。两者合在一起，意味着 一枚密码的防守，可以被一个薄弱的重置正面偷走。
用单一薄弱因素把守一个「能动钱的入口」，是最坏的情形
攻击者看重的，是一枚破了就直通金钱或个人信息的单一关口。用一枚密码加上薄弱重置去把守一个高价值入口——支付、转账、管理员登录——恰恰就是这种情形。不止支付，任何一个登录就能触及余额或全体用户数据的管理后台，都带着同样的危险。
攻击链也是一张防御地图
这是一条 每一步都有可以拦住它的位置 的链条。请把它当作 它本可以在哪里被打断 来读，而不是当作操作手法。
1. 入口：仅凭 ID＋密码登录
在别处泄露、被复用的凭据可以直接生效。
止损点：2FA／通行密钥；检测并锁定撞库
2. 通过密码重置冒充本人
新密码可被发送到未登记的收件地址。
止损点：重置只发往已登记渠道；加强身份核验；重置时通知本人
3. 账户被接管，余额被盗用
被劫持的账户被用来支付和充值。
止损点：重要操作前二次认证；检测并暂停异常支付；发送通知
4. 损失扩大，服务被关停
在全部充值被暂停后，整个服务在约 3 个月内被废止。
止损点：上线前评审认证流程；从设计上就不造出单点故障
公开的时间线
2019-07-01
7pay 上线（嵌于 7-Eleven 应用内，与 7iD 对接）。2019-07-02
开始出现关于盗用的首批报告（包括来自海外 IP 的访问）。2019-07-03
确认存在盗用；封锁海外访问，并暂停信用卡/借记卡充值（入金）。2019-07-04
召开记者会公开说明；暂时停止全部充值。缺少双因素认证一事被广泛指出。2019-07-05
日本 METI 要求应对；根因调查与组织加固工作启动。2019-08-01
宣布废止该服务（安全重启需要相当长的时间）。2019-09-30
7pay 关停。
根本原因是层层失守，而非单一失误
把这件事简单归结为「密码被破解了」，只会招致重演。实际上是 多个认证层同时都很单薄。
失守的那套配置
- 一款支付应用却 没有双因素认证（仅 ID＋密码）
- 密码重置可发往 未登记的邮箱地址
- 对使用泄露凭据的 撞库 毫无抵抗力
- 上线前对认证流程 评审不充分
守得住的那套配置
- 对重要操作强制 2FA／通行密钥
- 重置密码 只发往已登记的渠道
- 检测、限速并锁定 撞库
- 上线前 评审认证流程（从设计上消除单点故障）
设计优先于速度：事后账单远远大于事前投入
7pay 在上线后立刻遭遇盗刷，暂停了全部充值，并在约三个月内 彻底废止了该服务。为抢占竞争而省掉认证流程评审，意味着 信任崩塌、退出与重建的代价，远远超过事前的设计投入。 要让认证设计与你所保护的价值相匹配——在上线 之前，而不是之后。
你该如何防住它
即便你不做支付，只要存在一个 一次登录就能撬动大量价值 的地方，这就与你相关。按优先级排列：
在重要操作上提供双因素认证（2FA）
在登录以及动钱/动数据的操作上加装 2FA，并尽可能优先选择像 通行密钥 这类抗钓鱼的方式。即便只是 一次性密码（OTP），也远比一枚密码坚固得多。
把密码重置限定为「只发往已登记渠道」
新密码或重置链接 只发往已登记的邮箱/电话——绝不发往任意地址。不要仅凭零散信息（出生日期、电话）就通过身份核验。重置发生时要 立即通知所有者。
假定撞库会发生；对其进行检测与限制
重放泄露凭据的攻击是常态。加装 限速、异常登录检测、以及尝试 N 次后锁定，并拒绝已知被泄露的密码。引导用户远离密码复用。
上线前评审认证流程
在设计阶段和上线前，让登录、重置与二次认证 经由第二双眼睛评审。「能跑」不等于「安全」。不要为了速度而省掉认证评审。
这与本站的构建方式在哪里相通
这起事故的核心，是用 一个单一的薄弱因素 把守一个有价值的操作，而后又让一个薄弱的重置把那个因素偷走。 这恰是本站自身原则的镜像——不造出单点故障、对重要操作分层防御、并缩小爆炸半径。 不止支付，任何一个登录就能触及余额或全体用户数据的管理后台，都带着同样的危险。「加上 2FA、重置只发往已登记渠道、重要操作前二次认证」是任何规模下人人都能落地的防守。
出处（公开记录）
本文事实基于以下公开信息。不包含任何攻击手法——只讲 防御教训。
- Seven & i 控股「关于『7pay』服务废止的通知」（2019）— 7andi.com
- 7-Eleven Japan「部分『7pay』账户遭未授权访问一事」（2019）— sej.co.jp
- 日本 METI 关于无现金支付盗刷应对的公开信息（2019）— meti.go.jp
延伸阅读
- 术语：双因素认证（2FA） / 一次性密码（OTP）
- 术语：passkey（通行密钥）（不依赖密码的认证方式）
- 实务：认证与授权的区别 / 安全底线清单
FAQ
Q7pay 事件的根本原因是什么？
认证设计的缺陷。作为一款支付应用却没有双因素认证（2FA），登录只需 ID＋密码。更糟的是，密码重置流程可把新密码发送到「登记邮箱以外」的地址，因此仅凭零散的个人信息（出生日期、电话号码、邮箱）就能接管一个账户。这套设计对撞库（复用从其他服务泄露的 ID／密码）也几乎没有抵抗力。
Q我并不做支付服务，这和我有关系吗？
有。真正的问题在于：用「一枚密码」守住一个有价值的操作（金钱、个人信息），却又让一个薄弱的重置流程能把这枚密码偷走。在登录处提供 2FA、把密码重置只发往已登记的渠道、在重要操作前做二次认证——这套思路适用于任何应用或管理后台。
Q作为个人用户，我能做些什么自我防护？
能：①绝不在多个服务间复用密码（这能让撞库失效）；②只要提供了 2FA 或通行密钥就务必开启；③为支付开启交易通知，以便尽快发现异常。即便运营方的设计薄弱，只要不复用密码，就能堵住主要的接管路径。