資安事件與漏洞
7pay 盜刷事件（2019）— 沒有 2FA 的支付 App 為何一天就被接管
2019 年 7 月，Seven & i 的支付 App『7pay』在上線隔天就遭遇帳號被接管：約 808 名使用者被盜刷約 3,862 萬日圓（約 36 萬美元），該 App 在約 3 個月後就被收掉。核心失誤是沒有雙因素驗證，以及密碼重設可把新密碼寄到未登記的電子郵件地址。防禦之道是對敏感操作要求 2FA、把密碼重設限制在已登記的管道、抵禦帳密填充攻擊，並在上線前檢視驗證流程。
我們把真實、已公開的事故，不當成新聞重播，而是以 「你要如何防禦這種情況？」 的角度來解讀。本文以 公開記錄（公司聲明、主管機關、可信報導） 為基礎。出處列在文末，且不含任何攻擊教學。
- 目標
- 「7pay」支付 App 中的使用者帳號（營運方：株式會社 7pay／Seven & i Holdings 旗下）
- 察覺
- 2019 年 7 月 2–3 日（上線後隨即注意到未授權存取）
- 規模
- 約 808 名使用者、約 3,862 萬日圓的盜刷（件數後來經調查再修正）
- 根本原因
- 沒有 2FA（只有 ID ＋密碼）＋ 密碼重設可寄到未登記的電子郵件 ＋ 對帳密填充攻擊抵抗力弱 ＋ 外部 ID（7iD）整合薄弱 ＋ 上線前對驗證流程的檢視不足
- 真正的修法
- 對敏感操作要求 2FA、把密碼重設限制在已登記的管道、偵測／鎖定帳密填充攻擊、上線前檢視驗證流程
發生了什麼（用白話說）
一個行動支付 App 握有 動用你金錢的權限。這使得「只有真正的擁有者能登入、別人不行」——也就是 身分驗證 設計——成為關鍵所在。7pay 在這裡很弱：它的防禦實際上就是 一把密碼。
有兩個問題疊加在一起。第一，沒有 雙因素驗證（2FA）：只要 ID 和密碼對得上，你就進去了——所以這個 App 對 帳密填充攻擊 很脆弱，攻擊者會拿從其他服務外洩的 ID／密碼來嘗試。第二，是 密碼重設 的設計：新密碼可以被寄到 與已登記地址不同的電子郵件，因此任何握有片段個人資料（出生日期、電話、電子郵件）的人，即使不是真正的擁有者，也能替換掉密碼。這兩者加起來的意思是：單一密碼的防禦，可以透過脆弱的重設被正面偷走。
用單一的脆弱因素去把關一個『能動錢的入口』是最糟的情況
攻擊者最看重的是 一道直接對應到金錢或個人資料的單一關卡。用一把密碼加上脆弱的重設，去把關一個高價值的入口——支付、轉帳、管理員登入——正是這種情況。除了支付之外，任何一次登入就能觸及餘額或每一位使用者資料的管理後台，都帶著同樣的危險。
攻擊鏈也是一張防禦地圖
這是一條 在每一步都有地方可以攔下它 的鏈。請把它讀成 它本可在哪裡被打斷，而不是攻擊教學。
1. 入口：登入只靠 ID ＋密碼
在別處外洩、被重複使用的帳密可能直接就能用。
攔截點：2FA／通行金鑰；偵測並鎖定帳密填充攻擊
2. 透過密碼重設冒充本人
新密碼可以被寄到未登記的目標地址。
攔截點：重設只寄到已登記的管道；加強身分核對；重設時通知本人
3. 帳號被接管、餘額被盜用
被劫持的帳號被拿去付款和儲值。
攔截點：敏感操作前重新驗證；偵測並暫停異常付款；通知
4. 損害擴大、服務被收掉
在所有儲值都被暫停後，整個服務在約 3 個月內被廢止。
攔截點：上線前檢視驗證流程；別在設計上就打造出單一故障點
已公開的時間軸
2019-07-01
7pay 上線（在 7-Eleven App 內、與 7iD 整合）。2019-07-02
開始出現盜用的初步通報（包含來自海外 IP 的存取）。2019-07-03
確認盜用；封鎖海外存取，並暫停信用卡／簽帳卡的儲值（入金）。2019-07-04
召開記者會公開說明；暫時停止所有儲值。沒有雙因素驗證一事被廣泛指出。2019-07-05
日本 METI 要求提出因應；展開根本原因調查與組織強化。2019-08-01
宣布廢止服務（安全地重啟需要相當長的時間）。2019-09-30
7pay 服務終止。
根本原因是多層一起失守，不是單一失誤
把這件事草草歸結為「密碼被破解了」，只會招致重蹈覆轍。實際上是 好幾層驗證同時都很薄。
失守的那套設計
- 一個支付 App 卻 沒有雙因素驗證（只有 ID ＋密碼）
- 密碼重設可以寄到 未登記的電子郵件地址
- 對用外洩帳密發動的 帳密填充攻擊 毫無抵抗力
- 上線前對驗證流程的 檢視不足
守得住的那套設計
- 對敏感操作要求 2FA／通行金鑰
- 重設密碼 只寄到已登記的管道
- 偵測、限速並鎖定 帳密填充攻擊
- 上線前 檢視驗證流程（在設計上就消滅單一故障點）
設計優先於速度：事後的帳單遠遠超過事前的投入
7pay 在上線後隨即遭到盜刷，暫停了所有儲值，並在約 3 個月內 把整個服務整個收掉。為了搶市場競爭而略過驗證流程的檢視，意味著 失去信任、退場與重建的成本，遠遠超過事前的設計投入。要讓驗證設計與你所保護的價值相稱——在上線 之前，而不是之後。
你要如何防禦這種情況
即使你不做支付，只要有某個單一地方是 一次登入就能動用大量價值，這件事就是你的事。依優先順序：
對敏感操作提供雙因素驗證（2FA）
在登入以及動用金錢／資料的操作上加上 2FA，並在可行處優先採用像 通行金鑰 這類抗釣魚的方式。即使是 一次性密碼（OTP），也遠比單一密碼堅固得多。
把密碼重設限制在『只寄到已登記的管道』
新密碼或重設連結 只寄到已登記的電子郵件／電話——絕不寄到任意的目標地址。別只憑片段資料就通過身分核對（出生日期、電話）。重設一發生就 立即通知擁有者。
預設會有帳密填充攻擊；偵測並加以限制
用外洩帳密重放的攻擊是必然會發生的。加上 限速、異常登入偵測，以及嘗試 N 次後鎖定，並拒絕已知外洩的密碼。引導使用者遠離重複使用密碼。
上線前檢視驗證流程
讓登入、重設與重新驗證 在設計階段和上線前都經過第二雙眼睛檢視。「能動」不等於「安全」。別為了求快而略過驗證的檢視。
這與本站的建置方式在哪裡重疊
這起事件的核心，在於用 單一的脆弱因素 去把關一個有價值的操作，然後又讓脆弱的重設偷走那個因素。 這正是本站自身原則的鏡像——別打造單一故障點、以多層防守敏感操作、縮小爆炸半徑。 除了支付之外，任何一次登入就能觸及餘額或每一位使用者資料的管理後台，都帶著同樣的危險。「加上 2FA、重設只寄到已登記的管道、敏感操作前重新驗證」是任何人在任何規模都能落實的防禦。
出處（公開記錄）
以下事實以這些公開資訊為基礎。不含任何攻擊教學——只有 防禦上的教訓。
- Seven & i Holdings，「關於停止『7pay』服務的公告」(2019) — 7andi.com
- Seven-Eleven Japan，「部分『7pay』帳號遭未授權存取一事」(2019) — sej.co.jp
- 日本 METI，關於無現金支付盜刷因應的相關揭露 (2019) — meti.go.jp
延伸閱讀
- 術語：雙因素驗證（2FA） / 一次性密碼（OTP）
- 術語：passkey（通行金鑰）（不依賴密碼的驗證方式）
- 實務：身分驗證與授權的差別 / 安全底線清單
FAQ
Q7pay 事件的根本原因是什麼？
驗證設計。一個支付 App 在沒有雙因素驗證（2FA）的情況下就上線，所以登入只需要 ID ＋密碼。更糟的是，密碼重設流程可以把新密碼寄到與已登記地址不同的電子郵件，因此只要片段的個人資料（出生日期、電話號碼、電子郵件）就足以接管一個帳號。這套設計對帳密填充攻擊（重複使用從其他服務外洩的 ID／密碼）也很脆弱。
Q我又不做支付服務——這跟我有關係嗎？
有。真正的問題是用單一密碼去保護一個有價值的操作（金錢、個人資料），然後又讓脆弱的重設流程把那唯一的密碼偷走。請在登入時提供 2FA、把密碼重設只寄到已登記的管道，並在敏感操作前重新驗證。這套原則適用於任何 App 或管理後台。
Q身為個人使用者，我能做什麼？
能：(1) 絕不在不同服務間重複使用密碼（這能讓帳密填充攻擊失效）；(2) 只要有提供，就開啟 2FA 或通行金鑰；(3) 為支付開啟交易通知，以便快速察覺異常。即使營運方的設計很弱，不重複使用密碼就能封住主要的接管路徑。