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

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

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

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

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

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

@luojingyaoex

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

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

然后比对。

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

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

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

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

ls 没一个对的....

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

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

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

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

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

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

找到解决方法了：

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

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

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

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

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

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

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

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

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

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

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

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

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

@OpooPages
@luojingyaoex
@rekey

没什么用，因为前台是用密码的MD5进行运算的。
所以，我只需要知道密码的MD5就可以了，不需要知道密码。

@wy315700

没错，知道MD5值跟知道原文密码其实也差不多。

但是这个机制和HTTPS一样，应对的是传输过程中被拦截被窃取的问题，不是密码是否明文和MD5存储的问题。

@OpooPages 不不不，我说的是服务器被扒裤的问题，明文密码的问题在于服务器被扒裤以后可以直接用来登录。

@wy315700 被扒裤的话，https怕是也解决不了问题 ：）

不过我们关注的点可能不同，我就看他那个题目“网站登录时的安全机制”了，没有仔细想过密码安全存储的问题。

为了避免表单提交的时候被直接嗅探出明文密码。实现方法很多，有HMAC-MD5/SHA、3DES、RSA等，可以使用一种算法也可以使用多种算法。

@OpooPages 楼主这种方法也是解决不了中间人的。。。

@gdtv 呃...实际上它用的是密码的md5做HAMC的, 所以后台数据库应该存的是密码的md5...
不过一旦被扒库和存明文密码没什么区别...一样可以直接登录.

前端加密都是纸老虎

@gdtv 你很可笑 : )

@wy315700 为什么解决不了？求解释。