传输密码（用户注册）是加密了传还是传到服务器再加密？

[开拓者Amadues]

如果是加密了再传（用MD5），服务器这边怎么判断当前密码是明文还是加过密的？

[tianfang]

注册时密码用明文传输是传统方案

[SpringBoot中文社区]

MD5这种东西，只能防止别人篡改数据。没法实现你的那种“客户端加密”，“服务器解密”模型。 其实你只要用上ssl就行，ssl链接下就是客户端加密数据，服务器解密数据。或者服务器加密，客户端解密。而且加密解密过程来说，对你来说是透明的，你不需要操心。

[北北啊我是]

引用 楼主 鸣鸣Amadues 的回复:

如果是加密了再传（用MD5），服务器这边怎么判断当前密码是明文还是加过密的？

不懂就问 直接存库查库就好了 为什么服务端要看 是明文还是密文呢?

[开拓者Amadues]

引用 2 楼 SpringBoot中文社区 的回复:

MD5这种东西，只能防止别人篡改数据。没法实现你的那种“客户端加密”，“服务器解密”模型。 其实你只要用上ssl就行，ssl链接下就是客户端加密数据，服务器解密数据。或者服务器加密，客户端解密。而且加密解密过程来说，对你来说是透明的，你不需要操心。

MD5是不可逆加密，适合密码这种不需要解密的场合，在客户端加密是为了防止在传输过程中泄露，当然了如果用SSL的话其实传输本身就是加密的，对密码再加密只是保险一点。

[开拓者Amadues]

引用 3 楼 北北啊我是 的回复:

[quote=引用 楼主 鸣鸣Amadues 的回复:]如果是加密了再传（用MD5），服务器这边怎么判断当前密码是明文还是加过密的？

不懂就问 直接存库查库就好了 为什么服务端要看 是明文还是密文呢? [/quote] 是注册的时候，数据库里还没有存密码的。 服务器这里要最后检查一下的，前端发来的数据是不可信的。

[开拓者Amadues]

引用 11 楼 datafansbj 的回复:

即任何能输入密码的地方，都应立即进行散列成 Hash 值，然后通过加密通道进行传输

按照你这个说法，前端是可以看到怎么Hash的。 如果传密码明文，用https本身的加密，到了后台再用MD5保存，可行么？

[开拓者Amadues]

引用 12 楼 曾经我是菜 的回复:

密码的明文本来就没必要传到服务器，服务器只需要知道密码的hash值就可以了

那你服务器总要检验一下，传过来的是hash值还是明文吧，不能完全信任前端的

[datafansbj]

引用 13 楼 鸣鸣Amadues 的回复:

[quote=引用 11 楼 datafansbj 的回复:]即任何能输入密码的地方，都应立即进行散列成 Hash 值，然后通过加密通道进行传输

按照你这个说法，前端是可以看到怎么Hash的。
如果传密码明文，用https本身的加密，到了后台再用MD5保存，可行么？[/quote]

hash 计算的方法、原理、甚至源代码都是公开的，但不代表可以逆向来获取原文。
使用 https 加密通道传输明文，只能解决我所说的问题2，问题 1 和问题 3 无法避免。

[KeepSayingNo]

传输是双方已经协商好的结果，你不用管是什么文，你就按一个流程走

[DXF2020]

原则上新增密码不应该再前端，不然你怎么验证加密的对不对，加密的方式是否符合要求。打个比方，我知道了你设置密码的地址，然后我用我自己的加密方式去修改了密码，那么这个密码下次在前端怎么也匹配不上

[开拓者Amadues]

引用 15 楼 datafansbj 的回复:

[quote=引用 13 楼 鸣鸣Amadues 的回复:][quote=引用 11 楼 datafansbj 的回复:]即任何能输入密码的地方，都应立即进行散列成 Hash 值，然后通过加密通道进行传输

按照你这个说法，前端是可以看到怎么Hash的。 如果传密码明文，用https本身的加密，到了后台再用MD5保存，可行么？[/quote] hash 计算的方法、原理、甚至源代码都是公开的，但不代表可以逆向来获取原文。 使用 https 加密通道传输明文，只能解决我所说的问题2，问题 1 和问题 3 无法避免。[/quote] 前端hash后传到后端，这里还有一个问题，后端怎么判断这个字符串是hash后的还是明文本身，假设前端是不可信任的？ 如果后端不做任何处理，直接把前端传来hash后的密码存入数据库，怎么保证这个密码是符合密码格式的？前端校验同样是不可信任的，另外如果是多个前端，那每个前端都要处理一次，也不太合理。

[dkwuxiang]

客户端公钥加密，服务端私钥解密，数据库存不可逆MD5

[小程小程，永不消沉]

引用 6 楼 dkwuxiang 的回复:

客户端公钥加密，服务端私钥解密，数据库存不可逆MD5

这位老铁说得对

[北北啊我是]

引用 5 楼 鸣鸣Amadues 的回复:

[quote=引用 3 楼 北北啊我是 的回复:][quote=引用 楼主 鸣鸣Amadues 的回复:]如果是加密了再传（用MD5），服务器这边怎么判断当前密码是明文还是加过密的？

不懂就问 直接存库查库就好了 为什么服务端要看 是明文还是密文呢? [/quote] 是注册的时候，数据库里还没有存密码的。 服务器这里要最后检查一下的，前端发来的数据是不可信的。[/quote] 懂了 我们就是前端做个校验 你说的那就前端公钥加密 后端解密 再入库吧 就像楼上说的

[韩_师兄]

使用POST方法,传明文,后端加密验证.

[maradona1984]

如果啥都不干,那就是明文,是否MD5,取决于你前端是否做了MD5. 其实https就差不多可用了,没有https,密码想加密也会采用对称加密,服务端存数据库做非对称性加密那只是防内部人而已,算法肯定不太适合暴露给客户端,特别是要加盐之类的.

[datafansbj]

关于密码的处理，应按安全等级来设计。密码是用户私有敏感信息，从安全角度考虑，任何系统都不应该保存、传输密码的明文或可解密的密文形式（客户端、服务端），而只能保存其可进行校验的散列 hash 信息（不可解密）。即任何能输入密码的地方，都应立即进行散列成 Hash 值，然后通过加密通道进行传输。这样处理解决了3个问题：
1、密码只在人机界面程序中是明文的，其他地方都是密文（Hash），防止恶意程序劫持窃取
2、网络传输通道是加密的，防止黑客网络监听窃取
3、任何人都无法从系统中的静态数据中获取或逆向得到密码明文

至于密码忘记了，只能“重置密码“，并没有“获取密码”这一说。
如果客户端或服务端真的记录了密码的明文或可解密的密文，那么这种设计不符合高等级的安全系统（如银行），内部人即可以窃取用户信息。

记住：任何可自动登录的系统都是不安全的。

[曾经我是菜]

密码的明文本来就没必要传到服务器，服务器只需要知道密码的hash值就可以了

[曾经我是菜]

引用 18 楼 鸣鸣Amadues 的回复:

[quote=引用 15 楼 datafansbj 的回复:][quote=引用 13 楼 鸣鸣Amadues 的回复:][quote=引用 11 楼 datafansbj 的回复:]即任何能输入密码的地方，都应立即进行散列成 Hash 值，然后通过加密通道进行传输

按照你这个说法，前端是可以看到怎么Hash的。 如果传密码明文，用https本身的加密，到了后台再用MD5保存，可行么？[/quote] hash 计算的方法、原理、甚至源代码都是公开的，但不代表可以逆向来获取原文。 使用 https 加密通道传输明文，只能解决我所说的问题2，问题 1 和问题 3 无法避免。[/quote] 前端hash后传到后端，这里还有一个问题，后端怎么判断这个字符串是hash后的还是明文本身，假设前端是不可信任的？ 如果后端不做任何处理，直接把前端传来hash后的密码存入数据库，怎么保证这个密码是符合密码格式的？前端校验同样是不可信任的，另外如果是多个前端，那每个前端都要处理一次，也不太合理。[/quote] 从职能上讲，密码是否符合格式应该由浏览器完成，前端开发者造成的任何故障也应该由前端开发者解决。如果所有问题都要后端校验，将会使后端程序变得臃肿，影响用户体验。而且不论如何加密，密码原文始终是有可能被获取的。事实上，当数据库要求要传hash时，密码的原文有很大概率无法写入数据库，前端人员在测试的时候自然会发现的。如果前端人员觉得密码应该是按A格式，你觉得应该按B格式，仍然要按前端人员的习惯去做，也就是用A格式。更进一步地，当前端人员觉得不需要hash时，你也没有权力去管，但你可以把数据库设计成最适合hash的格式，这样前端人员测试的时候就会发现有些密码存不进去，就会自己去改正了。 事实上你想做的事情是用后端去代替javascript，而密码原文的分析还是更适合放在javascript中实现的。

[曾经我是菜]

引用 13 楼 鸣鸣Amadues 的回复:

[quote=引用 11 楼 datafansbj 的回复:]即任何能输入密码的地方，都应立即进行散列成 Hash 值，然后通过加密通道进行传输

按照你这个说法，前端是可以看到怎么Hash的。 如果传密码明文，用https本身的加密，到了后台再用MD5保存，可行么？[/quote] 用javascript进行hash要比用https加密原文更安全。 因为即使全世界都知道你的hash算法，也没办法简单地从hash码中还原出密码原文。 而使用加密的方法则有可能被破解。 另外，既然你说这个前端不可信，那么作为一个不可信的前端，我把表单先以原文发给我自己的一个后端服务器，再用https转发给你的服务器不是比破解你的算法更简单吗？一个不可信的前端你想在后端去防范根本是防不住的。 另外，不管是hash还是https都无法防止黑客用旧报文去登陆你的网站。但hash报文只能攻破你的网站，https报文则意味着黑客可以得到密码的原文。 如果你的重点在于确定前端是否可信，则需要给前端一个程序身份验证，但你仍然无法防止已有验证的前端人员泄漏验证信息。另外你无法防止钓鱼网站，因为他们可能根本就不需要连接你的服务器。