话说回来，如何做才能在明文存储密码的情况下保证安全？

[whileFalse]

不考虑“这样做有什么意义”，只是矫情地想知道答案。比如：


1.认证使用单独的服务和 DB，其他任何业务不连接该 DB
2.认证服务做好防注入
3.为防止密码被管理员看到用于尝试登录其他网站，密码不允许自己设定。在注册和更换密码时都自动生成随机密码

[IvanLi127]

明文保存就得保证你的数据库绝对安全且有权读取数据库的用户也得是绝对可靠的，比如认证程序读取时不把密码带出去。还是加密加盐成本低

[xomix]

使用 RFC 4226 - HOTP 标准不要继续使用用户名密码标准。或者利用 HOTP 两部验证，这时候密码就是防止 HTOP 设备遗失用的钥匙，没有泄露风险。

[mengzhuo]

@whileFalse #12 密码本被搞到的，然后战败的悲剧，在二战就已经上演了。

任何能还原的密码都可以视为明文，就是不安全，不管你用什么法子变着方存。

[draguo]

你和那个国家图书馆用明文存储密码的是什么关系？

[whileFalse]

@mengzhuo 楼里面有很多说用 AES 存的，我可没说……
我只是想搞清楚，在仅有“服务”和“ DB ”这个简化的系统里，DB 存明文，怎么保证安全。
也就是说，在仅有服务有可能被攻破的情况下保证安全。服务所在的宿主机被从服务之外攻破，不在考虑范围。

[whileFalse]

@draguo 看到那帖有感而发。

[dcll222]

密文都不能保证安全, 明文.....

[iceheart]

情况 1.假设你的登录服务是个私有服务，外部不可见，你对外的服务去访问登录服务。这种情况，如果你对外的服务被攻破，那么攻击者有可能修改你的对外服务，经过这个服务的账号密码全部泄露。
情况 2.如果你的登录服务是对外可见的，那么这个登录服务会成为首要攻击目标，一旦被攻破，数据库里的所有账号密码全完蛋。

[liprais]

很简单，不能

[whileFalse]

@iceheart 登录服务私有；登录时仅传输用户名和密码和盐的哈希。盐每次登陆从登录服务获取。

[kamen]

不妨参考一下 lastpass

[msg7086]

这问题可以转化成 黑箱+认证服务。
整个系统只有一个访问入口，入口只接受账号密码并返回 Yes 或 No。
前提条件，黑箱不会被人搬走，入口没有其他漏洞。

这种情况下密码明文存储在黑箱中是安全的。

这种做法和二次认证用的 USB Key 是一样的，USB Key 里存储私钥，但是对外只有一个访问入口，Key 只用来做不对称加密，没有办法直接从外部读取 Key 里写的私钥。只要访问入口安全，你的明文私钥存在 USB Key 里就是安全的。

[iceheart]

如果服务被攻破，上传什么就完全由攻击者决定了。他可以夹带一段 js 到浏览器，想怎么干就怎么干

[whileFalse]

@iceheart 这就和本题目无关了吧。DB 里密码加密不加密无所谓了。

[ilibilib]

又要当表子，又要立牌坊