67,543
社区成员
发帖
与我相关
我的任务
分享
...全文
请发表友善的回复…
发表回复
曾经我是菜 2020-10-17
- 打赏
- 举报
按照你这个说法，前端是可以看到怎么Hash的。
如果传密码明文，用https本身的加密，到了后台再用MD5保存，可行么？[/quote]
用javascript进行hash要比用https加密原文更安全。
因为即使全世界都知道你的hash算法，也没办法简单地从hash码中还原出密码原文。
而使用加密的方法则有可能被破解。
另外，既然你说这个前端不可信，那么作为一个不可信的前端，我把表单先以原文发给我自己的一个后端服务器，再用https转发给你的服务器不是比破解你的算法更简单吗？一个不可信的前端你想在后端去防范根本是防不住的。
另外，不管是hash还是https都无法防止黑客用旧报文去登陆你的网站。但hash报文只能攻破你的网站，https报文则意味着黑客可以得到密码的原文。
如果你的重点在于确定前端是否可信，则需要给前端一个程序身份验证，但你仍然无法防止已有验证的前端人员泄漏验证信息。另外你无法防止钓鱼网站，因为他们可能根本就不需要连接你的服务器。
曾经我是菜 2020-10-17
- 打赏
- 举报
按照你这个说法，前端是可以看到怎么Hash的。
如果传密码明文，用https本身的加密，到了后台再用MD5保存，可行么？[/quote]
hash 计算的方法、原理、甚至源代码都是公开的，但不代表可以逆向来获取原文。
使用 https 加密通道传输明文，只能解决我所说的问题2，问题 1 和问题 3 无法避免。[/quote]
前端hash后传到后端，这里还有一个问题，后端怎么判断这个字符串是hash后的还是明文本身，假设前端是不可信任的？
如果后端不做任何处理，直接把前端传来hash后的密码存入数据库，怎么保证这个密码是符合密码格式的？前端校验同样是不可信任的，另外如果是多个前端，那每个前端都要处理一次，也不太合理。[/quote]
从职能上讲，密码是否符合格式应该由浏览器完成，前端开发者造成的任何故障也应该由前端开发者解决。如果所有问题都要后端校验，将会使后端程序变得臃肿，影响用户体验。而且不论如何加密，密码原文始终是有可能被获取的。事实上，当数据库要求要传hash时，密码的原文有很大概率无法写入数据库，前端人员在测试的时候自然会发现的。如果前端人员觉得密码应该是按A格式，你觉得应该按B格式，仍然要按前端人员的习惯去做，也就是用A格式。更进一步地，当前端人员觉得不需要hash时，你也没有权力去管，但你可以把数据库设计成最适合hash的格式，这样前端人员测试的时候就会发现有些密码存不进去，就会自己去改正了。
事实上你想做的事情是用后端去代替javascript，而密码原文的分析还是更适合放在javascript中实现的。
曾经我是菜 2020-10-16
- 打赏
- 举报
密码的明文本来就没必要传到服务器，服务器只需要知道密码的hash值就可以了
datafansbj 2020-10-16
- 打赏
- 举报
关于密码的处理，应按安全等级来设计。密码是用户私有敏感信息，从安全角度考虑，任何系统都不应该保存、传输密码的明文或可解密的密文形式（客户端、服务端），而只能保存其可进行校验的散列 hash 信息（不可解密）。即任何能输入密码的地方，都应立即进行散列成 Hash 值，然后通过加密通道进行传输。这样处理解决了3个问题：
1、密码只在人机界面程序中是明文的，其他地方都是密文（Hash），防止恶意程序劫持窃取
2、网络传输通道是加密的，防止黑客网络监听窃取
3、任何人都无法从系统中的静态数据中获取或逆向得到密码明文
至于密码忘记了，只能“重置密码“，并没有“获取密码”这一说。
如果客户端或服务端真的记录了密码的明文或可解密的密文，那么这种设计不符合高等级的安全系统（如银行），内部人即可以窃取用户信息。
记住：任何可自动登录的系统都是不安全的。
1、密码只在人机界面程序中是明文的，其他地方都是密文（Hash），防止恶意程序劫持窃取
2、网络传输通道是加密的，防止黑客网络监听窃取
3、任何人都无法从系统中的静态数据中获取或逆向得到密码明文
至于密码忘记了，只能“重置密码“，并没有“获取密码”这一说。
如果客户端或服务端真的记录了密码的明文或可解密的密文，那么这种设计不符合高等级的安全系统（如银行），内部人即可以窃取用户信息。
记住：任何可自动登录的系统都是不安全的。
maradona1984 2020-10-16
- 打赏
- 举报
如果啥都不干,那就是明文,是否MD5,取决于你前端是否做了MD5.
其实https就差不多可用了,没有https,密码想加密也会采用对称加密,服务端存数据库做非对称性加密那只是防内部人而已,算法肯定不太适合暴露给客户端,特别是要加盐之类的.
韩_师兄 2020-10-16
- 打赏
- 举报
使用POST方法,传明文,后端加密验证.
北北啊我是 2020-10-16
- 打赏
- 举报
不懂就问 直接存库查库就好了 为什么服务端要看 是明文还是密文呢?
[/quote]
是注册的时候，数据库里还没有存密码的。
服务器这里要最后检查一下的，前端发来的数据是不可信的。[/quote]
懂了 我们就是前端做个校验
你说的那就前端公钥加密 后端解密 再入库吧 就像楼上说的
小程小程，永不消沉 2020-10-16
- 打赏
- 举报
这位老铁说得对
dkwuxiang 2020-10-16
- 打赏
- 举报
客户端公钥加密，服务端私钥解密，数据库存不可逆MD5
开拓者Amadues 2020-10-16
- 打赏
- 举报
按照你这个说法，前端是可以看到怎么Hash的。
如果传密码明文，用https本身的加密，到了后台再用MD5保存，可行么？[/quote]
hash 计算的方法、原理、甚至源代码都是公开的，但不代表可以逆向来获取原文。
使用 https 加密通道传输明文，只能解决我所说的问题2，问题 1 和问题 3 无法避免。[/quote]
前端hash后传到后端，这里还有一个问题，后端怎么判断这个字符串是hash后的还是明文本身，假设前端是不可信任的？
如果后端不做任何处理，直接把前端传来hash后的密码存入数据库，怎么保证这个密码是符合密码格式的？前端校验同样是不可信任的，另外如果是多个前端，那每个前端都要处理一次，也不太合理。
DXF2020 2020-10-16
- 打赏
- 举报
原则上新增密码不应该再前端，不然你怎么验证加密的对不对，加密的方式是否符合要求。打个比方，我知道了你设置密码的地址，然后我用我自己的加密方式去修改了密码，那么这个密码下次在前端怎么也匹配不上
KeepSayingNo 2020-10-16
- 打赏
- 举报
传输是双方已经协商好的结果，你不用管是什么文，你就按一个流程走
datafansbj 2020-10-16
- 打赏
- 举报
按照你这个说法，前端是可以看到怎么Hash的。
如果传密码明文，用https本身的加密，到了后台再用MD5保存，可行么？[/quote]
hash 计算的方法、原理、甚至源代码都是公开的，但不代表可以逆向来获取原文。
使用 https 加密通道传输明文，只能解决我所说的问题2，问题 1 和问题 3 无法避免。
开拓者Amadues 2020-10-16
- 打赏
- 举报
那你服务器总要检验一下，传过来的是hash值还是明文吧，不能完全信任前端的
开拓者Amadues 2020-10-16
- 打赏
- 举报
按照你这个说法，前端是可以看到怎么Hash的。
如果传密码明文，用https本身的加密，到了后台再用MD5保存，可行么？
开拓者Amadues 2020-10-15
- 打赏
- 举报
不懂就问 直接存库查库就好了 为什么服务端要看 是明文还是密文呢?
[/quote]
是注册的时候，数据库里还没有存密码的。
服务器这里要最后检查一下的，前端发来的数据是不可信的。
开拓者Amadues 2020-10-15
- 打赏
- 举报
MD5是不可逆加密，适合密码这种不需要解密的场合，在客户端加密是为了防止在传输过程中泄露，当然了如果用SSL的话其实传输本身就是加密的，对密码再加密只是保险一点。
北北啊我是 2020-10-15
- 打赏
- 举报
不懂就问 直接存库查库就好了 为什么服务端要看 是明文还是密文呢?
SpringBoot中文社区 2020-10-15
- 打赏
- 举报
MD5这种东西，只能防止别人篡改数据。没法实现你的那种“客户端加密”，“服务器解密”模型。
其实你只要用上ssl就行，ssl链接下就是客户端加密数据，服务器解密数据。或者服务器加密，客户端解密。而且加密解密过程来说，对你来说是透明的，你不需要操心。
tianfang 2020-10-15
- 打赏
- 举报
注册时密码用明文传输是传统方案
