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

V2EX = way to explore

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

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

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

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

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

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

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

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

加密

前端

明文

30 条回复 • 2015-06-30 10:10:27 +08:00

fising

2015-06-29 10:18:39 +08:00

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

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

RecursiveG

2015-06-29 12:36:05 +08:00

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

luojingyaoex

2015-06-29 12:55:53 +08:00

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

luojingyaoex

2015-06-29 12:56:22 +08:00

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

wy315700

2015-06-29 12:59:59 +08:00

@luojingyaoex

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

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

然后比对。

wy315700

2015-06-29 13:00:46 +08:00

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

quix

2015-06-29 13:07:28 +08:00

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

RecursiveG

2015-06-29 13:11:20 +08:00

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

rekey

2015-06-29 13:28:33 +08:00

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

RIcter

2015-06-29 13:34:51 +08:00

ls 没一个对的....

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

wy315700

2015-06-29 14:14:44 +08:00

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

gamexg

2015-06-29 14:22:48 +08:00 via Android

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

gdtv

2015-06-29 14:28:40 +08:00

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

gdtv

2015-06-29 14:31:09 +08:00

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

gdtv

2015-06-29 14:36:11 +08:00

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

gdtv

2015-06-29 14:42:22 +08:00

找到解决方法了：

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

luojingyaoex

2015-06-29 15:17:50 +08:00 via Android

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

9hills

2015-06-29 15:23:16 +08:00

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

luojingyaoex

2015-06-29 15:25:59 +08:00 via Android

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

OpooPages

2015-06-29 15:50:18 +08:00

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

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

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

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

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

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

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

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

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

wy315700

2015-06-29 15:59:16 +08:00

@OpooPages
@luojingyaoex
@rekey

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

OpooPages

2015-06-29 16:06:30 +08:00

@wy315700

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

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

wy315700

2015-06-29 16:07:08 +08:00

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

OpooPages

2015-06-29 16:20:05 +08:00

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

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

wdlth

2015-06-29 16:22:33 +08:00

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

wy315700

2015-06-29 16:24:30 +08:00

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

RecursiveG

2015-06-29 16:56:28 +08:00

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

iyangyuan

2015-06-30 08:09:26 +08:00 via iPhone

前端加密都是纸老虎

fising

2015-06-30 10:10:00 +08:00

@gdtv 你很可笑 : )

fising

2015-06-30 10:10:27 +08:00

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