你的密码去哪了？——Priestess 怎样保管密码，为什么连 Rakko 也看不到

写于 2026 年 9 月。本文面向没有技术背景的读者，文末附有给技术读者的细节，可以跳过。

答案是：不能。 不是 Rakko 承诺「不去看」，而是 Priestess 从一开始就没有把你的密码存下来。这篇文章想讲清楚四件事：

Priestess 到底存了什么；
为什么这样存了之后，连 Rakko 也没法知道你的密码；
谷歌、学习通这些平台是怎么做的，又出过什么事；
欧盟是怎样用法律要求网站这样做的。

一、保险箱和榨汁机：两种「保管」方式

想象你把一样重要的东西交给别人保管，大致有两种办法。

第一种是保险箱。 东西锁进去，需要的时候用钥匙打开，原样取出来。这叫「加密」。它的问题是：谁有钥匙，谁就能看到原件。 如果网站把你的密码锁进保险箱，那么掌握钥匙的管理员，或者偷到钥匙的小偷，都能把密码拿出来。

第二种是榨汁机。 把一个苹果放进去，出来一杯苹果汁。果汁没法再变回苹果；但同一个苹果每次都会榨出同样的果汁。这在技术上叫「哈希」。

Priestess 对你的密码用的是榨汁机。

为什么可以这样做？因为 Priestess 根本不需要知道你的密码是什么，只需要判断你这次输入的对不对。注册时，它把你的密码「榨」成果汁存起来；以后每次登录，它把你这次输入的密码再榨一遍，两杯果汁一样，就说明密码是对的。整个过程不需要保留苹果本身。

有些东西确实只能放保险箱

榨汁机不是万能的。有些信息系统必须拿到原件才能工作，这时只能锁进保险箱：

信息	系统需要原件吗	怎么保管
你的登录密码	不需要，只要能核对	榨汁机（变不回去）
登录状态凭证、找回密码邮件里的链接	不需要，只要能核对	榨汁机
两步验证用的密钥	需要，系统每 30 秒要用它算出新的 6 位验证码	保险箱（加密保存）
发短信所用的服务商账号密码	需要，系统要拿着它去调用短信服务	保险箱（加密保存）

规律很简单：只需要核对的，就榨掉；非用原件不可的，才上锁。 你的登录密码属于第一种。

二、你的密码在 Priestess 里经历了什么

光用一台普通榨汁机还不够安全。小偷如果偷走了整仓库的果汁，可以自己拿常见的苹果一个个去榨，看哪杯对得上。所以 Priestess 给这台榨汁机加了三道保险。

第一道：一味锁在别处的秘方

在榨汁之前，Priestess 会先给你的密码加上一味秘方。这味秘方不放在存果汁的仓库（数据库）里，而是单独锁在服务器的另一个保险柜中。

好处是：就算有人把整个数据库偷走，手里没有秘方，他连「拿苹果去试」都无从下手，因为他根本不知道该怎么复现同样的榨法。

加秘方这一步还有个附带的好处：不管你的密码有多长，都会先变成固定的长度，后面的榨汁机就不会漏掉其中任何一个字。

第二道：每个人独一无二的调料

每个账号在榨汁时还会额外加一撮随机调料，每个人都不一样。

于是，就算你和另一个人碰巧用了同一个密码，存下来的果汁也完全不同。小偷没法提前做一张「常见密码对照表」一次查出成千上万个账号，只能一个账号一个账号地慢慢试。

第三道：一台故意很慢的榨汁机

Priestess 用的是一台故意设计得很慢的榨汁机。

在一台普通电脑上实测，它榨一次大约要 0.07 秒。你登录时根本察觉不到这点等待。可对小偷来说就完全不同了：普通的快速算法，一台电脑一秒能算几十万次甚至更多；换成这台慢机器，一秒只能算十几次。想把几十亿个可能的密码挨个试一遍，时间会被拉长几万倍。

最后：贴一张写明「第几代」的标签

每一杯果汁上都贴着标签，写明是用哪一代榨汁机榨的。将来有了更好的机器，你下次登录、密码核对成功的那一刻，系统会自动用新机器重新榨一杯，把旧的换掉，你不需要做任何事。这个机制现在就在工作：早期没有加「秘方」的旧记录，会在用户下次登录时自动换成新做法。

顺带一提：连「这个账号存不存在」也不泄露

如果有人输入一个根本不存在的用户名，Priestess 仍然会假装认真榨一遍汁再回答「登录失败」。这样，别人就没法通过「回答快慢」来判断某个用户名是否注册过。

三、为什么 Rakko 看不到你的密码

把上面的内容串起来，「看不到」体现在四个地方：

仓库里没有。 数据库里只有果汁，没有苹果。Rakko 打开数据库，看到的是一串毫无意义的字符，和小偷看到的一样。
管理面板上没有。 管理员查看用户信息时，只能看到「已设置密码：是 / 否」。
日志里没有。 系统在运行时会记录一些日志，比如「某时某刻有人登录失败」，但从不记录你输入的密码内容。
能换锁，不能看钥匙。 如果你忘了密码，可以通过邮件自助重置；Rakko 也可以直接给账号设一个新密码。管理员这样做之前要再输一次自己的管理员密码，而且会留下操作记录。无论哪种方式，都是用新密码覆盖旧密码，旧密码不会被任何人看到。

说句实在话

「看不到」有一个边界，我们不想夸大。

你登录时，密码需要通过加密的网络连接交给服务器核对。就像你把钥匙递给门卫验一下，门卫接过去的那一瞬间是拿得到的。Priestess 的规矩是：验完立刻忘掉，不抄在本子上、不拍照、不告诉任何人。这份保证来自程序的写法和运营的纪律，而不是物理上不可能。

真正连这一瞬间都省掉的办法，是 Passkey（通行密钥）：用手机或电脑的指纹、面容解锁来登录，密码压根不需要发给服务器，服务器那边只保存一份「只能用来验证、不能用来冒充你」的信息。这也是 Priestess 推荐的主要登录方式，密码更多是作为备用。

你自己能做的

不要在多个网站用同一个密码。 Priestess 保管得再好，如果你在另一个网站用了同一个密码，而那个网站泄露了，坏人就可能拿它来试你的其它账号。
密码长一点比花哨更重要。 Priestess 要求至少 12 个字符，不强制你加大小写或符号。一句只有你知道的长句子，往往比短而复杂的密码更好记，也更安全。
用密码管理器，开启两步验证或 Passkey。

四、别人家是怎么做的

大公司通常不会把「用哪台榨汁机、放几味调料」全部公开，法律也没有要求它们公开。下面看两个例子：一个是做得不错、但也犯过错的谷歌；一个是强调密码没有泄露、却被卷进大规模个人信息泄露风波的学习通。

谷歌：没公开配方，但公开过自己的失误

谷歌没有公开账号密码具体用的是哪一种算法。它在 2019 年的一篇官方博客里讲过总原则：密码先经过单向的「榨汁」处理，然后把榨出来的结果连同用户名一起再锁进保险箱（加密），才写进硬盘。等于榨汁机和保险箱两道都用上了。

有意思的是，这篇博客本身是一份认错声明。谷歌发现，面向企业客户的 G Suite（现在叫 Google Workspace）从 2005 年起有一个漏洞：管理员在后台替员工设置或找回密码时，系统会多存一份没榨过的原始密码。2019 年 1 月又出了一次类似问题，一小部分新注册企业客户的密码被原样存放了最多 14 天。谷歌表示，这些数据一直放在自家加密的内部系统里，没有发现被滥用，普通个人账号也不受影响；它通知了受影响企业的管理员，并要求他们重置密码。

连谷歌都会在「管理员代设密码」这种不起眼的角落出错。所以 Priestess 在这条路径上同样只保存榨过的果汁：管理员替你设新密码时，系统拿到密码就立刻榨掉，不留原件。

谷歌还有一个给其它开发者用的登录服务 Firebase，这一边的做法倒是公开的：它用的是一种改良版的 scrypt 慢速算法。scrypt 不光费时间，还特别费内存，小偷很难靠专门定制的硬件批量加速。每个项目都有自己独立的一套参数和密钥；从别处搬进来的旧密码记录，会在用户第一次成功登录时自动换成新做法，和前面讲的 Priestess「贴标签、自动换代」是同一个思路。

谷歌也有必须用保险箱的场景：谷歌密码管理器。它替你记住的是你在其它网站的密码，将来要原样填回去，所以不能榨，只能加密保存。默认情况下，这个保险箱的钥匙由你的谷歌账号保管；如果你手动开启「设备端加密」，钥匙就只存在你自己的设备上，连谷歌也打不开。

此外，从 2023 年 10 月起，谷歌把 Passkey 设成了个人账号的默认登录选项，希望大家尽量不再用密码。

另一种教训：2022 年的学习通

2022 年 6 月，有人在网上兜售号称来自「超星学习通」的 1.7 亿多条学生信息，包括姓名、手机号、学校、学号等，话题一度冲上微博热搜第一。

学习通很快回应：已经报警；技术排查了十几个小时，还没有发现明确的泄露证据。它同时强调自己不保存明文密码，采用的是「单向加密」，也就是本文说的榨汁机，连公司内部员工都拿不到密码原文，网传「密码泄露」不属实。

但媒体随后发现，有社工库机器人（黑产用来倒卖、查询个人信息的工具）已经能查到与本人学习通资料一致的学号、姓名、手机号，不少网友也说自己接到了骚扰或诈骗电话，怀疑与此有关。在我们能查到的公开资料里，还没有看到这件事的最终调查结论。

这个案子的教训有两层：

榨汁机只保护密码。 就算密码榨得好好的，姓名、手机号、学校这些信息一旦流出，照样能被拿去骗人。一个网站要保护的，远不止密码。这也是后面要讲的欧盟法律管的是「所有个人数据」，而不只是密码的原因。
榨汁机也分好坏。 当时有专家提醒：「单向加密」如果用的方法不够强，只要有足够的时间和算力，照样可以被解开。所以光说「我们加密了」还不够，还要看用的是哪台榨汁机、有没有秘方和调料。

放在一起看

做得好的公司，思路其实非常一致：只存果汁，用慢机器，秘方分开放，并且努力让大家不用密码。 但就算做到了这些，还有两件事要时刻记着：一是谷歌那样藏在角落里的疏忽，二是学习通风波提醒我们的：密码之外的个人信息同样要守住。

五、欧盟是怎样定这些规矩的

在欧洲，网站该怎样保护用户数据，主要由一部法律决定：《通用数据保护条例》（GDPR）。它常被当作全球个人信息保护的标杆。

欧盟的法律是怎么「写」出来的

欧盟立法有点像一份合同的诞生：

起草人是欧盟委员会，只有它可以正式提出法律草案。
签字人有两位：一位是欧洲议会，由欧洲选民直接选出的议员组成；另一位是欧盟理事会，由各成员国政府的部长组成。两边都同意，法律才能通过。
两边意见不一时，三方会坐下来反复协商，逐条讨价还价，直到拿出一份双方都能接受的文本。

欧盟的法律分几种。其中「条例」一旦通过，所有成员国直接照办，不需要各国再自己改写成本国法律。GDPR 就是一部条例。它取代的是 1995 年的一份旧「指令」：指令只规定目标，由各国自行立法落实，结果各国宽严不一。

GDPR 从提出到落地花了六年多：

2012 年 1 月，欧盟委员会提出草案；
之后经过四年多谈判，2016 年 4 月正式通过；
法律给企业留了两年准备期，2018 年 5 月 25 日起正式实施。

它并没有规定「用哪台榨汁机」

你可能以为，这样一部法律会写明「密码必须用某某方法保存」。其实没有。GDPR 的写法是：

企业要考虑当下的技术水平、实施成本和数据面临的风险，采取与风险相称的技术和管理措施，例如加密，并且要能持续保证数据的保密性。（第 32 条大意）

此外，它还要求个人数据必须以确保安全的方式处理（第 5 条），并要求企业从设计之初、默认状态下就只处理必要的数据（第 25 条）。

为什么不直接写死方法？因为一部法律要用很多年，而技术几年就会变。二十年前被认为足够安全的算法，今天已经可以被轻易破解。如果法律写死某种方法，它很快就会过时，甚至会保护那些照着旧标准做、实际已经不安全的企业。

所以 GDPR 选择只规定「要做到什么程度」，不规定「具体用什么工具」。这就好比交通法规不规定你必须开哪个牌子的车，只要求刹车必须合格；而且「合格」的标准会随着时代自动提高。

胡萝卜和大棒

胡萝卜：如果企业发生了数据泄露，原则上要尽快报告监管机构，情况严重时还要逐一通知受影响的用户。但法律也规定：如果泄露出去的数据被处理得让外人看不懂，比如经过了加密，就可以不必逐一通知用户（第 34 条）。也就是说，平时防护做得好，出事时的麻烦就小得多。

大棒：没做好安全措施，最高可以罚 1000 万欧元，或者全球年营业额的 2%，按两者中较高的算；违反更基本的数据处理原则，上限翻倍，达到 2000 万欧元或 4%（第 83 条）。

谁来说明「怎样才算做好」

既然法律只写原则，就需要有人把原则翻译成具体做法。这份工作由各国的数据保护机构和它们共同组成的欧洲数据保护委员会（EDPB）承担。它们会发布指南，举大量例子。

其中一个例子几乎就是在讲本文的主题：

一个菜谱网站被黑客入侵，1200 个用户的密码被偷走。但这些密码都用当下可靠的方法「榨」过，还各自加了随机调料，而调料没有一起泄露。EDPB 认为，这种情况对用户权益没有风险，网站甚至不必向监管机构报告，只需要内部登记；不过仍然建议网站提醒用户换密码。

EDPB 还在同一处指出：更理想的做法是采用根本不需要服务器处理密码的登录方式，也就是前面说的 Passkey 这一类。

两张真实的罚单

德国，Knuddels（2018 年）。 这是一个德国聊天网站，把用户密码原样存放，没有做任何「榨汁」处理。2018 年它被黑客入侵，约 33 万组账号和密码被公开到网上。当地数据保护机构认定它违反了 GDPR 关于安全措施的规定，开出 2 万欧元罚单，这也是 GDPR 实施后德国的第一张罚单。金额不算高，是因为该公司事后非常配合，也很快完成了整改。

爱尔兰，Meta（2024 年）。 Meta（Facebook 的母公司）在 2019 年主动向爱尔兰数据保护机构报告：公司发现，部分用户的密码以明文形式存放在内部系统里。这些密码并没有泄露给外人，但监管机构依然认定它没有采取适当的安全措施、没有按规定报告和记录，于 2024 年 9 月处以 9100 万欧元罚款并给予训诫。

两个案子放在一起看，道理很清楚：把密码原样存着，这件事本身就是违规，不需要等到真的被偷。

这些规矩和 Priestess 有什么关系

先说清楚：GDPR 约束的是在欧盟境内经营、或者面向欧盟境内的人提供服务的机构，就算机构本身不在欧盟也一样。Priestess 是一个个人运营的服务，并不以欧盟用户为对象，严格来说是否适用要看具体情况，本文也不构成法律意见。我们把 GDPR 当作一把标尺，用来检验自己做得够不够好。中国的《个人信息保护法》第五十一条同样要求处理个人信息时采取加密、去标识化等安全技术措施，方向是一致的。

拿这把标尺量一量：

规矩的要求	Priestess 的做法
采取与风险相称、符合当下技术水平的措施	密码经过「秘方 + 随机调料 + 慢速榨汁机」处理，并留有将来升级的机制
持续保证数据保密	管理面板不显示密码，日志不记录密码
只处理必要的数据	管理员只能看到「有没有设置密码」这一项
泄露的数据应让外人看不懂	数据库即使被整个偷走，也无法从中还原出任何人的密码
更推荐不需要服务器处理密码的方式	主推 Passkey 登录，密码作为备用

结语

保护密码最好的办法，是从一开始就不保存它。

Priestess 不保存你的密码，只保存一杯变不回苹果的果汁；Rakko 看不到你的密码，不是因为自觉不去看，而是没有东西可看。欧盟的法律没有告诉大家该用哪台榨汁机，但它把道理讲得很明白：你替别人保管的东西，要用这个时代最靠谱的办法去保管。

附：给懂技术的朋友

看不懂这一节完全没关系，跳过即可。

密码哈希：先用服务端密钥（pepper）对密码做 HMAC-SHA-256，结果 base64url 编码后再做 bcrypt（cost 10，16 字节随机盐，盐来自 CSPRNG），最后加上版本前缀 v2.bcrypt-pepper. 存入数据库。pepper 以 Worker secret 注入，不进入数据库和代码仓库。这与 OWASP Password Storage Cheat Sheet 推荐的 bcrypt 加 pepper 的预哈希做法一致。
HMAC 预处理的副作用：bcrypt 只取输入的前 72 字节，而 HMAC 输出编码后固定为 43 个字符，所以 Priestess 允许的最长 4096 字符的密码，每一个字符都会参与计算；同时 pepper 让「password shucking」式的攻击无法进行。
参数升级：没有版本前缀的旧式纯 bcrypt 记录，在登录校验成功后会自动重算为 v2 格式，并写入审计日志。
防用户名枚举：用户名不存在时也会对一个固定的假哈希执行一次 bcrypt 比对，让两种情况的响应耗时接近。
高熵凭证只做 SHA-256：会话 token、密码重置 token、OIDC client secret 都是系统随机生成的高熵字符串，不怕字典攻击，存 SHA-256 摘要即可；慢哈希是专门针对人类挑选的低熵密码的。
必须可逆的秘密：TOTP 密钥、短信服务商凭证等使用 AES-GCM 加密保存，密钥与数据库分离。
坦白说：OWASP 目前把 Argon2id 列为首选，并把 bcrypt 归为遗留系统的选项；cost 10 是它给出的 bcrypt 最低推荐值。版本前缀机制就是为将来平滑迁移准备的。

参考资料