twitter 到底干了嘛？怎么会出现用户明文密码

[iConnect]

用户密码不是应该只保存 hash 过的吗？

[AlphaTr]

哈希之前的日志记录了密码，没脱敏

[opengps]

估计某个程序员测试时候记录了明文日志，然后忘了去掉日志就提交生产环境了

[LazyZhu]

Github 也出了这个问题, 内部调试日志出现了明文密码.
不过得给 Github/Twitter 这种高度的用户透明度点个赞, 国内哪家大厂商有这个觉悟?

[wvc]

@LazyZhu 国内啥都是毒瘤啊

[julyclyde]

@wvc 国内啊，携程把信用卡卡号和 CVV2 写到日志里去了

[xmdhs]

国内的估计没几个 hash 过

所以国内的网站 万一裤子被脱了就。。。

[iX]

@julyclyde 不是记录到数据库里了么？

[lany]

调试代码忘记注释了

[0915240]

日志记录了密码



emmmmm

[Va1n3R]

貌似这个日志也是用户接触不到的。。。只有工作人员可以看到，其实也就是日志把明文密码在 hash 前先记录下来了。

[Raymon111111]

是生产环境打了 log, 推特官方表示没有任何迹象表明这个有泄露, 但是改密码还是更保险一点.

HN 上这个讨论还挺热烈的, 都在说能用手段避免这种情况发生.

[swulling]

客户端预 hash 可以解决，两次 hash

客户端一次，服务端一次。

[PressOne]

@Raymon111111 黑客没那么傻，以往公开的库都是几年前拖的，利用的没有价值了再公布的

[cairnechen]

@xmdhs 国内没几个 hash 过？？？你可能有啥误解吧，以为国内人人都是 CSDN 呢

[geeklian]

其实银行的取款密码都没有 hash。

不过 6 位纯数字，hash 不 hash 没区别。

[rogwan]

@geeklian 银行是卡、密分离，这个还是有区别的。知道密码，没有实物卡偷不了钱。互联网账号则另说

[skyyp]

想起了几年前的 CSDN 脱裤子事件

[xy90321]

@swulling
不防本质
为了调试新加的本地 hash 代码所以又把明文密码打在了本地的 log 上 → 比打在服务器上性质还要恶劣 → 卒

[treo]

@swulling https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/

[lxc404]

twitter 发的邮件里面有解释

关于此问题

我们通过所谓的哈希转换流程，使用一个名为 bcrypt 的函数对密码进行掩码处理，即用随机的一系列数字和字母替代实际密码，存储在 Twitter 系统内。 这让我们的系统可以在不显示你的密码的前提下核实帐号身份。 这是行业标准做法。

有一个问题导致密码在完成哈希转换前被写入一个内部日志。 我们自己发现了这个错误，移除了密码信息，并且正在部署计划以防这个问题再度发生。

[xiaolanglang]

@swulling 二次 hash 会降低值域，安全性会下降

[xiaolanglang]

Bcrypt 是目前非常适合用来 hash 密码的算法……还是建议用这个……而不是自己造轮子…………

[swulling]

@gy911201 Twitter 就是用的 bcrypt，但是和这次是两回事。另外值域缩小对密码来说不是什么问题。


@treo 所以两次啊，javascipt 一次，服务端一次。

[swulling]

@xy90321 你还真别说，打到 console log 里没啥风险。。

[julyclyde]

@swulling 多次 hash 会缩小定义域，降低安全性

[Telegram]

前面几位感觉有点跪舔了，密码明文就是明文，一视同仁的喷就对了，别说什么比国内透明。
就算是日志里出明文，也不能让我理解。
为啥不能前端先 hash 一次，然后提交到服务器，后端你再要怎么加密都没问题。

[20015jjw]

@Telegram 国内这方面几乎为 0 的透明度还是得喷啊

[agagega]

还是 Dropbox 的会玩。第一步 SHA 把长度统一，第二步 Bcrypt，第三步用一个全局密钥 AES 加密以防泄漏。

[param]

所以前端應該在提交之前先哈希一遍

[param]

@geeklian 即使是 6 位數字，也可以加鹽解決問題