求分析一下这个网站登录时的安全机制和实现方案

[luojingyaoex]

网址： http://www3.firstjob.com.cn

这个网站是上海市的就业事务网。

目前已知的是每次刷新一下页面，后台就传过来一个加密的密钥（每次都不同）
然后前端用密钥把明文的输入的密码进行加密，再进行判断

请问这是什么实现方法？
只是技术研究，不是违反道德的用途。

——————————————————————————————
第一次发帖，望轻拍~~

[fising]

加密后传输，防止被抓取到明文密码。即便攻击者拿到你的加密后的密文，也无法用做密码来登录系统。因为 token 仅一次有效，能有效避免重放。对于加强安全性有一定的作用。

实现原理类似于网站登录常常使用的图片验证码。

[RecursiveG]

感觉是个标准的HMAC认证吧？

[luojingyaoex]

@fising 感谢回复。请问类似技术是什么呢？如何实现的

[luojingyaoex]

@RecursiveG 密钥每次都不一样，这样是怎么实现的呀

[wy315700]

@luojingyaoex

本地对密码做MD5以后加上Key做hmac

服务器存储密码的MD5，加上key做hmac

然后比对。

[wy315700]

@luojingyaoex
这么做有个巨大的 问题。
用户密码等于是明文存储的。

[quix]

随机密钥, 同时起到加密和 csrf 保护作用

[RecursiveG]

@luojingyaoex 你看到的那一长串东西只是随机数，每次都不一样，防止重放攻击。
用户的密码才是“密钥”, 服务器和客户端同时计算HMAC(随机数，密码)
既然随机数是一样的，如果客户端传来的结果和服务端的结果也一样，那么说明密码也是一样的。
这样避免直接传输明文密码；或者如果用MD5传输密码，被截获后用彩虹表爆破的情况。

[rekey]

@wy315700 不会吧，服务端生成 加密key 和 解密key，把 加密key 下发加密密码，服务端再解出来，按照注册加密方式加密一次，和数据库里的比对。就完了。

[RIcter]

ls 没一个对的....

这就是为了防止中间人嗅探到密码..
discuz 也有类似功能..

[wy315700]

@rekey 仔细想想，密码是不是相当于明文存储的

[gamexg]

还是js公钥加密密码及随机数的好。

[gdtv]

@fising 这个和图片验证码完全不同。网站加了图片验证码，密码还是明文传输的，而这个网站里密码不是明文传输

[gdtv]

@rekey 看了这个网站的前端，前端每次加密后都是32位，显然是不可逆的加密，那么服务器端怎么解密？

[gdtv]

@RecursiveG 这样的话，服务器岂不是要存储密码明文？求指教。

[gdtv]

找到解决方法了：

http://jamesfancy.blog.51cto.com/2516291/1161210

[luojingyaoex]

@gdtv 棒！看来大家做前端开发并没有考虑过这样的问题啊

[9hills]

这种方法就是闲的蛋疼，直接上HTTPS就能搞定，非要用HMAC搞一套

[luojingyaoex]

@9hills 噗。。。说的很对啊。。我没做过很多前端 其实并不是很懂 来向大家学习学习

[OpooPages]

在很早很早以前，Yahoo邮箱还没有默认使用 HTTPS 登录时就采取的这样一种登录机制。

1. 后台生成一个随机字符串作为challenge，并保存在服务器的内存（比如session）中;

2. 前台提交登录信息时，对密码进行MD5计算，公式：前台提交的密码=MD5(MD5(用户输入的原文密码) + "|" + challenge)；

3a. 后台密码校验：如果后台密码是明文存储，则校验 前台提交密码 == MD5(MD5(后台存储密码) + "|" + challenge)

3b. 后台密码校验：如果后台密码是MD5存储，则校验 前台提交密码 == MD5(后台存储密码 + "|" + challenge)

可见这种方法肯定支持后台MD5存储密码。

在实际项目中，如果没有部署SSL，我们也常使用这中登录验证机制。

这个challenge字符串，一定程度也起到表单token的作用，防止用户伪造登录表单进行无限制的登录尝试。

@gdtv 这种方法基本上还算安全。