杭州图书馆读者证密码明文保存？

就是显示出来你才不会用支付密码。(专业洗地)

这种用 123456 弱密码的更多吧

@chocolatesir 实际上一个密码走天下的群体并不少，甚至看到明文显示密码反而觉得方便自己忘了也不怕的用户肯定也有的.....

去 CNVD 提交一波？

不一定是明文存，只能证明不是摘要算法存的
比如 chrome 和 last pass 都能做明文填充，也不影响它在服务端加密存储啊

@yukiww233 也对哦，具体怎样那就抓包来看了

@lshero 涨知识了，还有这种平台，等下回家抓包看下是不是真有问题，再去试试提交

chrome 保存网站密码，也是明文，我都不敢随便点保存密码了，涉及网站更多，太不安全了。

这个和 Chrome 不一样吧，Chrome 是本地明文 + 服务器可选加密（主密钥可选是自己的同步密码还是由 Google 管理），这个图书馆是服务器直接明文

@xingyue #7 传回客户端肯定是（即使是客户端解密也算明文）明文的 你抓包也没用-。-

你都说了是 6 位数字密码，就算是存 hash，碰撞也太简单

凡是规定了密码最大长度的肯定都是明文保存密码的， 比如网易邮箱什么的

Chrome 那也不叫明文，也是密文。
正常保存密码其实严格来说叫保存 hash 摘要，不叫加密保存。加密的数据一般总是有解密需求的。
浏览器保存密码肯定要解密为原文再发给网站，不可能发摘要给网站的，只要密码策略 OK，一般是没问题的。
至于网站自身肯定是首选保存密码摘要，除非有非常特殊的需求……

Chrome 密码从功能上来说只能加密存储，不能使用摘要，而这个完全是毫无道理的，无法洗地

@niubee1 好像不对

@3dwelcome #8 老哥轻怼，，，一般登陆系统确实没理由对用户密码做可逆加密处理，如 #14 所说~，密码管理工具迫于功能性。不过我标题确实欠考虑了，毕竟不能据此推断出数据库的就是简单的原文保存，抱歉。。。。。

@sobigfish #10 emmmm，我想的是如果是客户端解密的话，因为登陆是低频操作，只要登陆时没有发生劫持那么相对也是安全的。然后抓包的结果是：请求后的 json 里直接明文密码，不过请求套了 https，然后 app 做了防止抓包处理，检测到会自动注销，所以总体来讲还是很安全滴(*°°*)。

@hourann #11 碰撞的话，做次数限制冻结账号应该就可以防止了吧

@greatdancing #15 好奇 ing，求详解~

@greatdancing 对就对不对就不对， 好像不对是个神毛鬼？

@3dwelcome chrome 看密码是要输入你电脑密码的

用可逆加密存储，要么就是懒，低价外包。要么就是别有所图（撞库，字典，彩虹表）

@niubee1 #17 哈哈哈，我上条还艾特错人了，等层主来解惑 @greatdancing

@niubee1 #21 并不全是这样吧，有些人脑洞比较大，比如说，存了 16 字节的摘要，那么密码明文也不允许超过 16 字节。

@niubee1 我觉得提交时候允许最长 64 位密码就行了，不存密码，但提交时候应该设计有长度限制吧？允许最长 1024 位密码？

@yukiww233 #5 这个应用理论上没有需要源密码的需求，所以如果显示了原密码，90%以上的可能性是明文存的……

@JamesR 你可以查查 HTTP POST 允许提交长度


@billlee 这种人属于脑洞大得脑子进水了

@niubee1 不限制密码文本输入大小，不考虑哈希相关函数处理多个并发请求的大文本占用的服务器资源？