这简直是反人类设计：为什么密码必须全局唯一？

前言：又见“天才”设计

在这个大家都喊口号要提升用户体验的时代，偶尔还是会蹦出一些让人摸不着头脑的“反人类”设计。这不，最近发现了一个让人血压升高的功能：强制要求用户的密码在系统内必须全局唯一。

当用户遇到“密码已被占用”提示时的真实写照

也就是说，如果你注册过一次账号用了密码 MyP@ssw0rd，当你注销或者想注册新账号时，系统会无情地提示你：“该密码已被使用，请换一个”。

这种设计到底想防什么？

乍一看，这似乎像是为了安全考虑？毕竟“撞库”和“密码复用”是目前网络安全的两大杀手。但仔细一想，这种逻辑根本站不住脚，甚至是一种偷懒的“伪安全”设计。

1. 密码管理的本质是私密，不是唯一性

密码的核心作用是验证“我是谁”。只要我的账密匹配正确，系统就应该放行。至于别人是不是也用了这个密码，理论上跟我没有任何关系。这就好比两家人都用一样的防盗锁，只要钥匙在自己手里，就不存在安全隐患。

使用密码管理器生成复杂且唯一的密码

2. 错误的隐私保护逻辑

有些产品经理可能觉得：“如果不强制唯一，新注册用户可能会猜到老用户的密码，或者通过批量注册得知某些密码已被占用从而推断出用户活跃度。”

这完全是多此一举。如果数据库泄露了，是不是唯一根本没区别（黑客直接看明文或哈希值）；如果没泄露，黑客根本猜不到你用了什么密码。通过注册尝试来反推用户是否存在？这反而是增加了被枚举攻击的风险。

3. 开发层面的极简主义懒政

从技术角度看，实现“密码唯一”非常简单——给密码字段加个唯一索引就行。但这通常意味着系统存储了密码的明文或者可逆加密，这本身就是巨大的安全红灯（正确的做法是存不可逆的 Hash 值）。为了省去那一丁点防止密码复用的校验逻辑（如果是为了同用户避免旧密码重用），直接把全站密码锁死，只能说是设计上的“摆烂”。

这种设计带来的灾难性后果

这种看似“严谨”的规则，对用户来说简直是灾难。我总结了以下几大“罪状”：

1. 密码管理难度指数级上升

现在的安全建议是“重要网站密码独享，杂乱网站分级管理”。如果每个网站都要求密码唯一（注意，这里是指你自己的密码不能跟别人重复，这简直是无法控制的随机事件），那人类的脑子根本记不住。用户只能被迫把密码写在纸上，或者存在不安全的浏览器笔记里，反而降低了安全性。

2. 扼杀多账号需求

很多用户有注册小号、马甲号的需求。如果大号用了习惯的强密码，小号却被迫要换一个新的，这会让人极度抓狂。

3. 令人困惑的错误提示

很多网站不会直接告诉你“密码已被占用”，为了安全可能会提示“密码强度不够”或“格式错误”。用户试了好几次都不行，最后才发现居然是因为这个密码“以前被人用过了”？这种挫败感足以让用户直接卸载流失。

遇到这种情况，我们该怎么办？

作为用户，如果我们不幸遇到了这种“天才设计”，怎么破局？

方案一：使用密码管理器的“变体”功能

这也是最推荐的方式。现代密码管理器（如 Bitwarden, 1Password 等）都有生成规则。你可以设定一个基础密码，然后加上网站特定字符。例如 MyP@ssw0rd!SiteA 和 MyP@ssw0rd!SiteB。对于这种强制全局唯一的系统，你可以在管理器里手动修改几个字符，比如把第一个字母变成大写，或者加个后缀 123，生成一个全新的唯一密码即可。

方案二：加盐 Hash 的逻辑反推

这种系统既然能判断密码重复，大概率存的是明文或简单的 MD5。如果你必须重用密码，可以在密码后面加一个空格，或者结尾加一个特殊符号。很多系统的输入框会 trim 掉首尾空格，但存储时可能没处理，或者处理不一致，123456 和 123456 有时能绕过检测。当然，这是利用 Bug，不保证一直有效。

方案三：用脚投票

如果一个产品在基础的用户体验和底层安全逻辑上都如此傲慢和愚蠢，很难相信它在数据保护和隐私合规上能做得有多好。如果这是非必须的服务，建议直接换一家。对于开发者来说，永远不要给密码字段加唯一索引，这是后端开发的基本常识。

结语

安全不该以牺牲便利性为代价，更不该建立在错误的逻辑之上。强制密码全局唯一，既不能真正提升安全性，又给用户制造了巨大的认知负担。希望各位产品经理和开发者在设计安全策略时，多动动脑子，多看看 OWASP 指南，别再让用户对着屏幕骂街了。

如果你也遇到过这种离谱的设计，欢迎在评论区吐槽交流！