我们阅读真实、公开的安全事故，不是把新闻重播一遍，而是以 「你要如何防住它」 的视角来解读。本文基于 公开记录（企业官方声明、可信报道）。出处列于文末，且不含任何攻击手法。
- 目标
- 文件传输服务「宅ふぁいる便」的用户（运营方：Ogis-Research Institute）
- 发现
- 2019 年 1 月 22–25 日（发现可疑文件 → 停止服务 → 公开披露）
- 手法分类
- 通过服务器漏洞的未授权访问 → 窃取客户数据（登录密码以明文保存）
- 影响规模
- 约 481 万条（姓名、邮箱、登录密码、出生日期、性别；含已退会客户）
- 根本原因
- 密码以明文（可还原形态）保存 ＋ 服务器漏洞 ＋ 保留含已退会用户在内的多余数据
- 真正的对策
- 单向哈希 ＋ 盐（bcrypt/Argon2id）／不持有多余数据、最小化保留期／漏洞管理／为重用做准备（2FA）
到底发生了什么（用大白话说）
服务受托保管用户的密码。问题在于 它如何保管。把密码以 明文（原样可读）保存，或只做可还原的 加密，那么数据泄露的那一刻，其 内容就能被直接使用。
在宅ふぁいる便，服务器漏洞被利用导致未授权访问，客户数据外泄。随后的续报披露：泄露的登录密码并未加密——它们是明文。因为许多人在多个服务间 重用 同一个密码，明文泄露就让攻击者可以拿去别处尝试，实施 账户接管。比起入侵本身，是明文保存把损害扩大了。
“加密”和“哈希化”不是一回事
密码保管中一个常见的误解，是以为 加密就安全。加密 用密钥可以还原，因此一旦密钥也一并泄露，就与明文无异。正确的做法是使用 无法还原的单向哈希，再为每个用户加 盐，并采用 刻意做得很慢 的算法（bcrypt / Argon2id）。登录时以相同方式对输入做哈希再比对——因此 根本不需要保存明文。
攻击的连锁，也是一张防御地图
这是一条 每一步都有可停下之处 的连锁。请把它读作 在哪里可以被斩断，而非攻击手法。
1. 通过服务器漏洞的未授权访问
被放任的已知弱点，成了入口。
止点：漏洞管理；补丁纪律；最小化攻击面
2. 客户数据与登录密码被取走
持有了含已退会客户在内的大量数据。
止点：不持有多余数据；最小化保留期
3. 密码是明文 = 立刻可用
未加密，所以泄露的那一刻就能用。
止点：单向哈希 ＋ 盐（bcrypt/Argon2id）＝ 泄露也无法直接使用
4. 通过重用引发二次损害（账户接管）
共用同一密码的其他服务被瞄准。
止点：停止重用密码；2FA；泄露时及时强制重置
已公开的时间线
2019-01-22
在服务器上发现一个公司无法识别的文件（未授权访问的迹象）。2019-01-23
出于谨慎，停止服务。2019-01-25
公开披露未授权访问与数据泄露（约 481 万条，含已退会用户）。2019-01-30
续报披露：泄露的登录密码并未加密（明文）。2019-03
报告外部安全公司的详细调查结果；服务持续停摆。2020-01-14
宣布停止服务（考虑到安全重建的成本与时间）；服务于当年结束。
根本原因不只是「被入侵了」
把这件事写成「他们被黑了」就错失了要点。入侵可能发生；关键在于保存方式能否 在数据泄露时把损害降到最小。
失败的配置
- 登录密码以 明文 保存（泄露即可用）
- 保留了 含已退会用户 在内的大量数据
- 服务器 漏洞 成了入口
- 泄露后难以阻止重用网站上的 账户接管
站得住的配置
- 密码以 单向哈希 ＋ 盐 保存（bcrypt/Argon2id）
- 不持有多余数据；最小化保留期（退会后删除）
- 漏洞管理／补丁纪律 堵住入口
- 2FA 与泄露时及时强制重置，限制二次损害
事后的账单，远远盖过事前的设计投入
宅ふぁいる便持续停摆，最终 被彻底关停（考虑到安全重建的成本与时间）。正确地对密码做哈希成本很低，而 明文保存所招致的信任崩塌、退会与二次损害的代价要大得多。 密码的保存方式，要在 动手构建时 就设计对，而非事后补救。
你要如何防住它
只要你受托保管哪怕一位用户的密码，这就是你的事。按优先级排列：
不持有多余数据
只收集最少的字段，并 在用户退会或数据不再需要时删除它。你不持有的数据不会泄露。别囤积已退会用户的记录。
堵住入口——管理漏洞
修补服务器与库的漏洞，最小化暴露的攻击面。把入侵当作可能发生的前提，减少入口。
即便泄露也不让损害扩大（2FA、重用防御）
提供 双因素认证，并在泄露时及时强制重置。引导用户远离重用。与哈希化配合，力争达到 即便泄露也无法直接使用 的状态。
这与本站自身的建设之道相通之处
究其根本，这起事件把最重要的秘密——密码——以泄露即可原样使用的形态（明文）持有。 这恰是本站自身原则的镜像——以不可逆的形态处理秘密、不持有多余之物、缩小爆炸半径。 「我们加密了，所以安全」是个危险的假设；密码应当归入单向 哈希 ＋ 盐。「不留明文、不持多余数据、让泄露也无法使用」是任何人、在任何规模都能落地的防御。
出处（公开记录）
本文事实基于以下公开信息。不含任何攻击手法——只讲 防御的教训。
- Ogis-Research Institute 官方声明（「关于宅ふぁいる便服务遭受未授权访问」／致歉与报告，2019–2020）— ogis-ri.co.jp
- 当时的相关报道（服务停摆、详细调查结果、停止服务，2019–2020），基于一手披露
延伸阅读
- 实务：如何安全存储密码（哈希与加盐）
- 术语：密码哈希是什么 / salt（盐）是什么
- 术语：什么是双因素认证（2FA）（让泄露也无法直接使用的准备）· 实务：安全底线清单
FAQ
Q宅ふぁいる便事件中最严重的问题是什么？
泄露的登录密码未加密、以明文保存。触发点是通过服务器漏洞的未授权访问，但正因为密码是明文，泄露的那一刻就能直接使用。如果密码以单向哈希（并加盐）保存，即便泄露也不会暴露可用的密码，损害会小得多。
Q把密码『加密』就足够安全了吗？
『加密』和『哈希化』是两回事。加密可以用密钥还原，因此一旦密钥也一并泄露，就与明文无异。正确的做法是使用无法还原的单向<strong>哈希</strong>，再为每个用户加<strong>盐</strong>，并采用 bcrypt 或 Argon2id 这类刻意做得很慢的算法。登录时以相同方式对输入做哈希再比对——因此根本不需要保存明文。
Q作为个人用户，我能做些什么？
能：（1）绝不在多个服务间重用同一密码（这样即便明文泄露，也无法在其他网站引发账户接管）；（2）用密码管理器生成又长又随机的值；（3）只要有提供，就开启双因素认证或通行密钥。即使运营方保存密码的方式很糟糕，只要不重用，就能斩断二次损害的连锁。