高客单店铺最怕的事：Passkey密钥捏在别人手里

一、先讲一个被公开报道过的现场

2025 年 1 月 16 日，新加坡母婴品牌 KeaBabies 的卖家账号被接管。

公开报道还原的过程：一封可疑邮件 → 触发手机一次性验证码请求 → 攻击者绕过这道验证码 → 改掉管理员邮箱和手机号 → 卖家本人被锁在门外 → 接着改银行收款信息，试图把一笔约 5 万澳元的款项转走。

这家店日均销售约 23 万美元、年销售约 7800 万美元。被锁的七天里，Listing 下架、发货停摆、80 多名员工的工作悬在半空。

请注意这个细节：卖家自己并没有做错任何事，也没有"泄露密码"这个动作。 攻击者拿走的不是密码，是控制权——改掉验证通道之后，这个人就是你，系统看不出来。

（案例来源：多家跨境行业媒体与卖家律所对该事件的公开复盘，见文末来源清单）

二、通行密钥比密码更难办：它没有"重置"按钮

大多数人还在用密码时代的直觉想问题：账号出问题，改个密码、踢掉设备、完事。通行密钥不是这套逻辑。

密码是"你知道什么"，服务器存的是摘要，所以服务器能重置它。 密钥是"你手里有什么"，服务器只存一把公钥，私钥从来没离开过那台设备。

W3C WebAuthn Level 3 规范把这件事写得很明白：服务端保存的是公钥，私钥材料始终留在认证器的安全区域里。

密码

通行密钥

服务器存了什么

密码哈希

只有公钥

能不能"改密码"

能

没有这个动作

让一把钥匙失效

改密码即可

必须删服务端凭据

私钥在哪里

不存在

在某台设备上

业内有句话：passkey 的"找回"其实是伪命题——你不是把钥匙找回来，你是 证明你是本人之后，重新登记一把新钥匙 。

推论很直接：钥匙一旦被登记在别人的设备上，"改密码"这条路走不通。

三、那把钥匙，现在躺在谁的口袋里

请现在就在脑子里过一遍你的店铺：

1）代运营 / 服务商的手机上。 当初为了方便，让对方"顺手把密钥建一下"。建在哪？建在他手机里。

2）已离职员工的个人云账号里。 同步型密钥会跟着平台账号走——存在 iCloud 钥匙串、谷歌密码管理器、第三方密码库里的密钥，会同步到这个人的 所有 设备。人走了，钥匙没走。

3）合伙人的密码管理器里。 共用一个管理器库，等于共用一把钥匙串。关系好的时候是效率，关系不好的时候是把柄。

4）你自己都不记得的某台旧设备。 最常见的不是被偷，是被遗忘。

WebAuthn 在注册时会返回两个标志位： BE（可备份） 与 BS（已备份） 。BE=1 且 BS=1，基本意味着这把钥匙可以在设备之间流动。它好不好用？好用。但"好用"的另一面是： 它的物理位置不由你决定。

四、撤销权悖论：想删掉它，你得先能进去

好，我现在去把那条凭据删掉，总行了吧？可以。但有个先决条件： 你得先登得进去，先过得了验证。

• 服务端凭据管理的入口，在账号的登录与安全设置里；
• 进这个入口，通常要再验一次身份；
• 而验证用的那把钥匙，可能就在对方手里。

拥有控制权的人，才有撤销权。

而且删除动作本身还有一半在客户端——ZDNet 的评测结论是：要彻底清除一把密钥，必须 分别在服务端和认证器两边各删一次 （那篇文章的标题就叫"想改或删掉你的通行密钥？这事挺复杂"）。只删一边，另一端还留着一条记录，下次同步又冒出来。

再叠加一条被反复验证的现实： 大部分账号入侵都有"人"的参与。 Verizon 年度数据泄露调查报告长期把"人为因素"列在首位（2024 年版为 68%），而账号恢复、权限交接正是人为失误最集中的环节。

五、高客单店铺，为什么这件事会被放大十倍

低客单店铺被接管，损失是一个月的流水。高客单店铺被接管，损失是 三条线同时断 ：

1）在途资金：一个结算周期的钱。 亚马逊对多数专业卖家采用 14 天结算周期，且订单款项在送达后还要再预留 7 天才进入可用余额，到账另需 1–5 个工作日。粗略算： FBA 卖家从成交到落袋通常是 14–21 天。 也就是说任何时刻都有一整个周期的货款在路上——改一次收款账户，动的就是整期的钱。

2）在仓库存：动不了也卖不掉。 账号被锁 → Listing 下架 → FBA 库存继续产生仓储费 → 补货计划全断。KeaBabies 停摆七天，这个量级的店铺直接损失就是百万美元级。

3）账号资产本身：估值归零。 一个稳定出单、评分良好的高客单店铺，是可以被估值的资产。被接管一次，轻则申诉数周，重则直接归零。

客单价越高，单位时间损失越大；账号越值钱，越值得被盯上。 这不是危言耸听，是攻击者的成本收益账。

六、还有一条更隐蔽的线：一把钥匙开过好几个店

同一台设备、同一个认证器、同一个云账号下的密钥，如果在 多个店铺账号 上注册过，那么在平台的视角里，这些账号之间就存在一条 共用凭证 的痕迹。

平台判定关联从来不看你"是不是本人操作"，它看的是 客观重叠 ：设备、网络出口、浏览器环境、认证凭据。你自己的钥匙在多个店之间流转，和你把钥匙借给别人，在日志层面是同一类信号。

所以"密钥捏在别人手里"的真正杀伤力，不止于 他能动你的钱 ，还在于 他把你和其他账号连在了一起 。而他那边是什么环境、还给谁用过，你完全不知道。

七、今天就能做的三件事

第一步：盘一次"钥匙归属"

打开每个店铺的登录与安全设置 → 通行密钥 / 两步验证，对列表里每一条问三个问题：登记在哪台设备？设备现在在谁手里？这个人还是我们的人吗？ 答不上来的，按"不在自己手里"处理。

第二步：清服务端凭据，再补自己的

顺序不能反：先用 自己的设备 新增一条凭据（本地硬件优先）→ 验证能正常登录 → 再 删除归属未知的旧凭据 → 到认证器那一端也删一次，别只删一半。 先加后删，否则中间那几秒你可能就进不去了。

第三步：把"人"和"店"隔开

一店一机一环境；认证器本地化（浏览器和密钥在同一台设备）；收款信息等财务权限只留给自己，运营只给 Listing 与广告；开变更告警（收款账户、大额提现实时推送）； 离职当天清凭据，写进出职流程 。

八、一个判断标准

如果今天和代运营 / 合伙人闹翻， 我能不能在两个小时内， 把他手里的钥匙全部作废？

答得上来，你的店是你的。 答不上来，你的店只是暂时放在你名下的。

高客单店铺最贵的不是库存，是不确定性。 钥匙在自己手里，才叫自己的店。

数据来源与说明

• KeaBabies 账号接管事件（2025-01-16） ：多家跨境行业媒体与卖家律所公开复盘。日期、金额、停摆天数为报道口径，不同来源数字略有出入（转移金额有 3.1 万美元 / 5 万澳元两种表述），本文取较一致部分。
• W3C WebAuthn Level 3 ：服务端仅保存公钥凭证，私钥材料不离开认证器；注册响应中的 BE / BS 标志位用于区分可同步与设备绑定凭据。
• ZDNet （评测文章 Want to change or delete your passkey? It's complicated ）：彻底清除一条通行密钥需在依赖方（服务端）与认证器两端分别操作。
• Verizon Data Breach Investigations Report（2024） ：人为因素涉及约 68% 的数据泄露事件。
• 亚马逊结算周期 ：Amazon Seller Central 官方论坛说明——多数专业卖家为 14 天结算周期，订单款项送达后预留 7 天进入可用余额，到账另需 1–5 个工作日。具体以卖家后台 Payments 为准。