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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2757 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

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

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

Hash

页面

小时

验证

28 条回复 • 2017-05-08 03:13:47 +08:00

geelaw

2017-05-06 13:55:28 +08:00

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

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

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

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

xialdj

2017-05-06 13:58:58 +08:00 via iPhone

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

fengyuhan

2017-05-06 14:00:40 +08:00

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

v1024

2017-05-06 14:09:52 +08:00 via iPhone

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

fangxing204

2017-05-06 14:20:35 +08:00 via Android

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

Quaintjade

2017-05-06 14:24:26 +08:00

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

billlee

2017-05-06 14:24:48 +08:00

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

fengyuhan

2017-05-06 14:45:44 +08:00

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

wy315700

2017-05-06 14:48:58 +08:00

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

dong3580

2017-05-06 15:21:22 +08:00

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

gamexg

2017-05-06 15:31:07 +08:00

不建议。

最好的方案是上 https。

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

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

yoa1q7y

2017-05-06 16:10:16 +08:00

楼上说的不就是 csrf 验证嘛

lsylsy2

2017-05-06 16:51:31 +08:00

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

lsylsy2

2017-05-06 16:52:06 +08:00

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

geelaw

2017-05-06 16:53:51 +08:00

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

Quaintjade

2017-05-06 17:34:48 +08:00

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

lslqtz

2017-05-06 17:47:42 +08:00

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

lslqtz

2017-05-06 17:49:12 +08:00

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

geelaw

2017-05-06 17:52:42 +08:00

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

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

billlee

2017-05-06 19:53:58 +08:00

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

lslqtz

2017-05-06 20:27:31 +08:00

@geelaw 重放攻击是指攻击者发送一个目的主机已接收过的包，md5 中加了时间并没有明文密码，重放攻击将在时间过后直接无效。

lslqtz

2017-05-06 20:28:43 +08:00

例如说：我这有个 123456 的密码，md5(123456+2017+05+06+20+28)，1 小时过期。
那么只有 1 小时内能进行重放攻击，所以我说基本就没可能了。
而密码已经经过 md5，不会进行明文传输。

cankoor

2017-05-06 20:32:38 +08:00 via iPhone

你可以看 https 的原理，可以实现一个。基于非对称加密。

Yinz

2017-05-07 13:04:46 +08:00

@fengyuhan 等一下，现在可以不到一分钟撞出指定的 md5 了吗？

wuhx

2017-05-07 17:39:57 +08:00

唯一的意义是可以避免用户密码暴露，无法防止重放攻击

@cankoor
HTTPS 的核心是浏览器内置了的 CA 证书验证链，否则非对称加密的公钥安全性无法保证。

fengyuhan

2017-05-08 02:19:17 +08:00

@Yinz 其實有更簡單的辦法，你直接複製 md5 去 google 搜索結果通常第一頁以內就有答案

Yinz

2017-05-08 02:24:14 +08:00

@fengyuhan 别转移话题啊。。。密码库彩虹表我才不感兴趣，一分钟撞出任意 md5 这个比较有意思

fengyuhan

2017-05-08 03:13:47 +08:00

@Yinz 是的，用 hashcat 輸入你期待的密碼位數，字母數字組合之類的，然後用 linkedin 的字典撞。