这种前端加密有什么槽点吗？

[nikoo]

用户登录页面，用 md5(用户输入的密码+用户名+日期戳年+月+日+小时) 得到 hash，传输该 hash 给后台验证

这里的日期戳是由后台页面生成（而不是 js 生成，所以不存在客户端系统时间与服务器时间不一致的问题）
另外为防止用户在一小时结束前打开登录页面，输入密码后登录正好过了一小时，服务器会验证前一小时与当前小时的两个 hash 与传递过来的 hash 进行验证

非 https 页面的情况下，这种加密传输是否能起到安全作用？是否有意义？
或者，有什么更完善的改进方案吗？

[geelaw]

不能，看到之后可以直接重放。

一个简单的改进方法是每次登录前从服务器拿一个 GUID 作为 token，然后传回这个 GUID + hash(密码 + GUID)，服务器看到之后无论通过与否，都不再允许使用那个 GUID。为了保证安全，hash 要难一些，且服务器不能校准时间（否则会有时间倒流的问题），且必须使用能生成惟一 GUID 的生成算法。

这样中间人并不能窃取密码，但仍然可以做很多其他的事情。

不过你能这样验证，说明密码是可逆存储在数据库里面，这也是比较危险的。

[xialdj]

我觉得挺好的 改进的地方 可以用楼上说的一次性 token 比时间好一些

[fengyuhan]

至少 sha-512
學校有一臺機器人稱 beast，五個 1080 顯卡。用 hashcat 不到一分鐘可以撞完 md5

[v1024]

没有绝对的安全，条件有限的情况下，能做一些是一些，我觉得挺好的

[fangxing204]

好像网易企业邮箱就是类似做法？，输入密码后点击登录发现密码变长了，。而且这种方式最烦的就是用 lastpass 填密码，总是提示密码错误，但是手动复制进去又可以登录。

[Quaintjade]

hash 算法不行，因为不可逆，所以下次用户必然得发给你相同的 hash 值。这样的话就能重放攻击了。
如 1 楼所说，你要用的是可逆的加密算法。

[billlee]

这说明你在后台保存了明文密码。。
应该是 hash(hash(用户输入的密码)+用户名+日期戳年+月+日+小时) 才对
这不能防窃听重放，要防窃听要上 CHAP.
然而还是不能防 MITM.

[fengyuhan]

其實你怎麼做都差不多，你不洩漏別公司會洩漏。大多數用戶會同一個密碼的。

[wy315700]

典型的 chap 协议，缺点就是，密码需要明文存储

[dong3580]

不能。
1.全球化会很坑爹；
2.改进一下，加上登录验证码的 hash，然后一起 hash，不要加时间。

[gamexg]

不建议。

最好的方案是上 https。

如果实在不能上 https，那么次选是直接用服务器公钥加密用户明文密码及一个随机数，记得后台会话里面保存并验证这个随机数，仅限使用一次。这样可以允许后台不保存用户明文密码，也可以防止窃听及重放攻击，但是无法防止中间人攻击。

公钥加密和 hash 用户名密码都是可以防止窃听及重放攻击，但是考虑下服务器被入侵后的后果：
非明文储存，无法获得用户密码，挂马也只能获得挂马时登陆用户的明文密码。
明文储存，直接获得所有的用户明文密码。

[yoa1q7y]

楼上说的不就是 csrf 验证嘛

[lsylsy2]

不懂前端，但是想问一个问题：
没有 HTTPS，那么怎么处理劫持？中间人直接修改了网页 JS，让用户 post 明文密码，中间人保存以后再按照你的加密传过去。

[lsylsy2]

@billlee 同问，不上 HTTPS 解决不了 MITM。

[geelaw]

@Quaintjade 你没看懂我 1 楼写的是什么

[Quaintjade]

@geelaw
你说的是像 CHAP 那样双方都知道明文密码？那样的话 LZ 方法确实是 1 小时内都可以重放，改用唯一的 GUID 能避免这点。

[lslqtz]

不能起到安全作用，前端页面没加密均可通过修改 JS 得到内容。
但不太可能重放攻击。

[lslqtz]

@geelaw 密码不通过明文传输，重放攻击基本就没可能了。
原文已经描述了是经过 md5 的，并且会验证时间。
但是可以通过修改 JS 来进行攻击（这个应该是不属于重放攻击的）。

[geelaw]

@Quaintjade 这跟可不可逆没太大关系。在服务器存储明文增加危险（不用 https 本来已经很危险了）。

@lslqtz 密码是否通过明文传输和重放没关系谢谢。

[billlee]

@lsylsy2 #13 网页不用 TLS 没可能防 MITM 的。防 MITM 需要双方有预先共享的信息，在 TLS 里面就是 CA. 如果是 app 什么的还有办法处理