NutzCN Logo
问答 nutzwk企业级开发问题
发布于 2531天前 作者 1037424761 1752 次浏览 复制 上一个帖子 下一个帖子
标签: nutzwk

公司最近在开发微信公众号,我们选择了nutzwk做后台管理系统,在代码提交完成准备上线时,使用

该报告由 IBM Security AppScan Standard 创建 8.7.0.0, 规则: 1564

进行代码扫描,提示login.html中密码传递是明文的,容易被截获,扫描不通过,请问有什么好的结局方案吗?

9 回复

要是为了骗过去,改改input的name呗

?这个报告扫描不是根据type来的吗,我是第一次用这个工具。
@wendal

不晓得,没用过

<input id="passwordCopy" name="passwordCopy" type="password" class="form-control input-lg">

这个也不可以,应该是根据type来的

不带password关键字试试

我打算先在前台用base64加下密,后台再转下,其他逻辑暂时不变。

作者:eldereal
链接:https://www.zhihu.com/question/25539382/answer/31178019
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

有几个答案有很大的问题,为防止有人受到误导,我觉得有必要说一下:
密码在前端加密完全没有意义,对密码系统的安全性不会有任何提高,反而会引发不必要的麻烦。首先,做前端开发的人需要知道,前端系统的控制权是完全在用户手里的,也就是说,前端做什么事情,用户有完全的控制权。假设如同 @陈轩所说,前端做过了md5,后台就不用做了,这个做法会有什么后果?如果某一天,这个系统的数据库泄露了,黑客就直接拿到了每个用户的密码md5值,但此时,由于黑客知道密码是在前端进行哈希的,所以他不需要爆破出该md5对应的原文是什么,而是直接修改客户端向服务器发出的请求,把密码字段换成数据库中MD5就可以了,由于与数据库中记录一致,直接就会登录成功。这跟直接存储明文密码没有任何区别!!!所以不管前端是不是加密了密码,后台使用安全的哈希算法对内容再次转换是非常有必要的。(MD5可不行,要用bcrypt,我之前回答过一个类似的:随着显卡性能的高速发展,目前的快速Hash算法是否已经变得不够安全了?)这个回答还有一个人赞同,希望大家别被错误答案误导了。另外一个答案 @林鸿所说,在非安全HTTP连接上,可以防止原始密码被窃听。但问题在于由于你的登录系统接受的哈希过的密码,而不是原文,窃听者根本不需要原始密码,只要通过哈希结果就可以伪造请求登录系统。这样做只能防止被窃听到原文的密码被攻击者用在社会学攻击上,而不能改善该网站的安全性。所以不管前端是不是加密了密码,使用HTTPS安全连接进行登录都是非常有必要的。以上我说的两点,合起来看就是:不管前端是否加密了密码,都不能以此为假设,让后端设计的安全等级下降,否则就会有严重的安全问题。实际上,前端进行密码加密,可以看做帮助用户多进行了一次原文的转换,不管用了什么加密算法,算出来的结果都是密码原文,你该如何保护用户的原始密码,就该如何保护此处的加密结果,因为对你的登录系统来说,它们都是密码原文。以上这些,说明了密码加密是没有什么意义的,接下来,我要说明前端加密会带来什么问题。有些人会认为前端进行了加密,可以降低后台的安全性需求,这种错误的观念会造成系统的安全漏洞。实际上,你不能对前端做任何的假设,所有跟安全相关的技术,都必须应用在后台上。前端进行加密会造成页面需要js脚本才能运行,那么假设你的系统需要兼容不能运行js的客户端,就必须再设计一个使用原文的登录接口。由于前端是不是加密,所有安全机制都必须照常应用,所以为系统增加这样的复杂性是完全没必要的,即使传输明文密码,只要正确使用了HTTPS连接和服务器端安全的哈希算法,密码系统都可以是很安全的。
我看了下前端加密的文章,感觉这篇还不错,分享一下,大家也可以发表自己的意见。

添加回复
请先登陆
回到顶部