密码在前端加密完全没有意义

作者：eldereal
链接：https://www.zhihu.com/question/25539382/answer/31178019
来源：知乎
著作权归作者所有，转载请联系作者获得授权。

密码在前端加密完全没有意义，对密码系统的安全性不会有任何提高，反而会引发不必要的麻烦。

首先，做前端开发的人需要知道，前端系统的控制权是完全在用户手里的，也就是说，前端做什么事情，用户有完全的控制权。

假设如同 @陈轩所说，前端做过了md5，后台就不用做了，这个做法会有什么后果？如果某一天，这个系统的数据库泄露了，黑客就直接拿到了每个用户的密码md5值，但此时，由于黑客知道密码是在前端进行哈希的，所以他不需要爆破出该md5对应的原文是什么，而是直接修改客户端向服务器发出的请求，把密码字段换成数据库中MD5就可以了，由于与数据库中记录一致，直接就会登录成功。这跟直接存储明文密码没有任何区别！！！所以不管前端是不是加密了密码，后台使用安全的哈希算法对内容再次转换是非常有必要的。（MD5可不行，要用bcrypt，我之前回答过一个类似的：随着显卡性能的高速发展，目前的快速Hash算法是否已经变得不够安全了？）
这个回答还有一个人赞同，希望大家别被错误答案误导了。

另外一个答案 @林鸿所说，在非安全HTTP连接上，可以防止原始密码被窃听。但问题在于由于你的登录系统接受的哈希过的密码，而不是原文，窃听者根本不需要原始密码，只要通过哈希结果就可以伪造请求登录系统。这样做只能防止被窃听到原文的密码被攻击者用在社会学攻击上，而不能改善该网站的安全性。所以不管前端是不是加密了密码，使用HTTPS安全连接进行登录都是非常有必要的。

以上我说的两点，合起来看就是：不管前端是否加密了密码，都不能以此为假设，让后端设计的安全等级下降，否则就会有严重的安全问题。实际上，前端进行密码加密，可以看做帮助用户多进行了一次原文的转换，不管用了什么加密算法，算出来的结果都是密码原文，你该如何保护用户的原始密码，就该如何保护此处的加密结果，因为对你的登录系统来说，它们都是密码原文。

以上这些，说明了密码加密是没有什么意义的，接下来，我要说明前端加密会带来什么问题。

有些人会认为前端进行了加密，可以降低后台的安全性需求，这种错误的观念会造成系统的安全漏洞。实际上，你不能对前端做任何的假设，所有跟安全相关的技术，都必须应用在后台上。
前端进行加密会造成页面需要js脚本才能运行，那么假设你的系统需要兼容不能运行js的客户端，就必须再设计一个使用原文的登录接口。
由于前端是不是加密，所有安全机制都必须照常应用，所以为系统增加这样的复杂性是完全没必要的，即使传输明文密码，只要正确使用了HTTPS连接和服务器端安全的哈希算法，密码系统都可以是很安全的。

编辑于 2014-09-29 17 条评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

玻璃茶叶只学了点皮毛……

1 人赞同

还是有点意义的。密码作为密文传播至少不会对用户造成二次损害……丢了我们站的密码，结果也能去其他站用同样密码登陆什么的。嘛……聊胜于无显示全部

还是有点意义的。密码作为密文传播至少不会对用户造成二次损害……丢了我们站的密码，结果也能去其他站用同样密码登陆什么的。
嘛……聊胜于无

发布于 2015-09-09 添加评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

Daniel Wei 没什么可说的。

1 人赞同

一切设计都要基于目的。比如对于前端加密的意义，应该先问加密的目的，然后再看是否有必要。在非HTTPS下，很难将可登录的密码保护好，这一点如 @eldereal所说的，不管前端是否进行摘要算法转化，对于后端的系统来说，可登录的都是你传输到后端的部分。所以… 显示全部

一切设计都要基于目的。比如对于前端加密的意义，应该先问加密的目的，然后再看是否有必要。在非HTTPS下，很难将可登录的密码保护好，这一点如 @eldereal所说的，不管前端是否进行摘要算法转化，对于后端的系统来说，可登录的都是你传输到后端的部分。

所以对于后台系统来说，安全性还是要基于后台系统总体进行设计，而无关你前台的部分。
至于前台要不要加密，可以单独从前台的角度考虑，因为后台其实并不太在乎你传过来的是明文还是密文，它只需要通过一些运算，然后和数据库对上就可以了。

总结下，前台加密的结果就是假设原来黑客需要知道你的明文才能进入系统，现在不止明文，知道密文也可以登录系统。

发布于 2014-10-13 添加评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

路名呵呵

4 人赞同

只要是明文传输，就没什么意义。 Over! 显示全部

只要是明文传输，就没什么意义。
Over!

编辑于 2014-09-30 添加评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

张扬旅行/抠钉/伪摄影

3 人赞同

肯定是有意义的，不懂安全和算法的人还出来乱讲一通没用，真是可笑。通常负责一点的非https登陆在你登陆的时候都会发过来一个字符串，当你登陆的时候，传输的是这个字符串+用户名+密码（具体看算法实现，是只用密码，还是只用用户名加密码）处理过后的一个… 显示全部

肯定是有意义的，不懂安全和算法的人还出来乱讲一通没用，真是可笑。
通常负责一点的非https登陆在你登陆的时候都会发过来一个字符串，当你登陆的时候，传输的是这个字符串+用户名+密码（具体看算法实现，是只用密码，还是只用用户名加密码）处理过后的一个加密字符串，所以中间人即便拦截到了这个字符串也无法重复登陆，从而实现一次一密和保护用户密码的作用。

发布于 2015-06-12 8 条评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

赵魏璇用代码写诗

不赞同楼主的话，前端加密有意义并且有必要，至于为什么很多人不做，其实是一种成本性能权衡。前端的加密手段非常多，楼下只是选了俩种最基础的加密来说明自己的观点，而这俩种加密恰好有作者说明的这些问题。需要说明的是前端加密需要后端的配合，任何一种… 显示全部

不赞同楼主的话，前端加密有意义并且有必要，至于为什么很多人不做，其实是一种成本性能权衡。前端的加密手段非常多，楼下只是选了俩种最基础的加密来说明自己的观点，而这俩种加密恰好有作者说明的这些问题。需要说明的是前端加密需要后端的配合，任何一种前端加密都需要后端配合。除了答主说的哈希算法和加盐之外，还有一些非对称的加密算法，使用公钥和私钥，动态口令计算，验证码混合校验等等，都能更好的保证用户的隐私和安全。

发布于 2016-09-05 添加评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

Shelter 一个贪图安逸的程序猿

2 人赞同

对抗拖库 — 看一下这篇文章吧！这篇给出了很好的办法。看完，或许你就不会对前端是否需要加密而感到迷惑了！显示全部

对抗拖库 —
看一下这篇文章吧！这篇给出了很好的办法。
看完，或许你就不会对前端是否需要加密而感到迷惑了！

编辑于 2015-12-28 添加评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

知乎用户 PHP开发工程师

2 人赞同

其实这个意义不在于本站的安全性有多少，而在于，就算你的密码被窃听了，也无法去尝试登录其他网站，前提是其他网站不用md5。显示全部

其实这个意义不在于本站的安全性有多少，而在于，就算你的密码被窃听了，也无法去尝试登录其他网站，前提是其他网站不用md5。

发布于 2014-09-30 添加评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

朱海洋带毛小动物控，金毛狗爹，IT攻城狮。

8 人赞同

反对最高票的答案 @eldereal 前端做加密是有意义的。就拿md5来讲。 1。传md5和传明文一样？绝对不一样啊。链路被监听的时候，攻击人直接就拿到明文密码了，有很多人都习惯用一个密码的。明文的话，相当于直接把用户n多个网站的密码爆了，拿到md5的话，只有… 显示全部

反对最高票的答案 @eldereal

前端做加密是有意义的。就拿md5来讲。
1。传md5和传明文一样？绝对不一样啊。链路被监听的时候，攻击人直接就拿到明文密码了，有很多人都习惯用一个密码的。明文的话，相当于直接把用户n多个网站的密码爆了，拿到md5的话，只有自己的网站密码被爆。对用户的危害范围明显缩小了好么。多少次用户icloud艳照泄露，最后都不是苹果的锅。。是别的网站被脱了好么。

2. 有一种有效实践是发送用户密码+时间戳的md5值。这样可以有效避免被监听。当然还要做一点客户端和服务器端时间差计算的工作量。哪怕被监听。攻击人拿到的加密后密码也很快失效。在做一点单帐号单登录的措施，用户密码安全性还是可以得到很大的保证的。

posted @ 2016-12-01 10:27 会奔跑的胖子阅读(1950) 评论(0) 编辑收藏举报

刷新页面返回顶部