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

你的第三条已经和用哈希去 mask 没有本质差别了吧

随机密码不就和 hash 一样了，那明文密文还有什么区别？

明文==不安全

以前做过 SQL Server 数据库加密，应该是比较好的方法了。

之前我们也有类似的需求，某个核心功能必须要有明文密码，当前的解决方案是直接在 C 代码里硬编码了一个 AES 钥匙，对称加密存起来你懂的

其实有更好的做法，我们是有 web 的，可以在登录 web 时把密码写一份到 cookie 里，再把 cookie 处理一下就可以了

接上，后边业务服务器还是存 hash，这样可以确保自身清白

服务器只要联网就一定能被攻破

@580a388da131 也不能单说一定会被攻破，要看攻破的代价

把明文藏起来

参看之前 Adode 密码泄漏事件。所有密码用 AES 加密，加密密钥放到其他地方。

有没有考虑过存双份, 明文和 hash 都存一份, 明文表线上只允许写权限.其他机制都是使用 hash.如果非要保留明文密码的话我觉得这样应该可以做到比较好的权限.但是限制也比较明显,就是存储系统必须支持,以及对存储系统的权限管理要做好避免存储系统方面出问题.

@snail1988 @kanex 有区别啊。看下密码表就可以登录。这么做的目的是防社工。防管理员拿着你的密码去别处碰。

@whileFalse 你非明文密码我拿到也可以登录啊，密码不明文储存本质目的就是避免撞库，拿着明文密码登录其他网站，你自己网站都被攻破了，你的密码已经没什么意义了

可以根据用户名生成 aeskey 加密。做模拟登录确实需要存储用户密码

@snail1988 在不修改程序的情况下，拿到不能反解的非明文密码，怎么登录呢？

我们在讨论的不就是怎么不被攻破么。管理员查表看密码不视为网站被攻破。

离线生成公钥钥对，私钥离线保存。
明文密码公钥加密后保存。

数据库加密之类的也是间接加密。

明文要保证安全唯一办法就是，----物理隔离----，
也就是说放了密码的主机不能连网，同时禁用任何外接存储，禁止任何非授权的人进入机房。
要查询要在主机本地终端操作。不然谈安全都是扯淡。

用可逆的加密算法即可，前提是你的算法不会泄漏。

让密码仅短时间、一次性生效，对，说的就是短信验证码

@otakustay #19 短信验证码是基于手机的登录，不是基于密码体系的登录。

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

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

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

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

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

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

@draguo 看到那帖有感而发。

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

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

很简单，不能

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

不妨参考一下 lastpass

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

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

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

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

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

又要当表子，又要立牌坊