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

2020-10-15 01:42:42 4.4k 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

数据加密全链路实战：从TLS传输到AES存储的工程实践数据加密是现代信息安全的核心技术，它通过密码学算法将明文转换为密文，确保数据在传输和存储过程中的机密性、完整性与真实性。其原理主要基于对称加密（如AES）和非对称加密（如RSA/ECC）两大体系，结合散列函数（如SHA-256）构建完整的安全方案。在工程实践中，加密技术的价值体现在防止数据泄露、满足合规要求及构建用户信任上。典型应用场景涵盖网络通信（TLS/SSL）、数据库字段加密、密码存储以及云存储安全等领域。本文聚焦于**全链路加密**的实施，深入探讨在**数据传输**与**数据存储**环节如何选择适配阅读详情

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

...全文

SRP协议：无需传输密码的零信任认证实践本文深入解析了SRP协议（Secure Remote Password）如何实现无需传输密码的零信任认证。通过精妙的数学设计，SRP允许客户端与服务器在不交换密码或哈希值的前提下完成双向身份验证并协商会话密钥，即使服务器数据泄露，攻击者也无法直接冒充用户。文章结合Go语言实践，阐述了SRP在提升传统口令认证安全性方面的核心优势与应用场景。阅读详情

开拓者Amadues

Java EE 67,535 成员 225,843 内容

+ 关注 + 加入社区

切换为时间正序

曾经我是菜 2020-10-17

打赏
举报

引用 13 楼鸣鸣Amadues 的回复:

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

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

曾经我是菜 2020-10-17

打赏
举报

引用 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中实现的。

曾经我是菜 2020-10-16

打赏
举报

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

datafansbj 2020-10-16

打赏
举报

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

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

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

maradona1984 2020-10-16

打赏
举报

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

韩_师兄 2020-10-16

打赏
举报

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

北北啊我是 2020-10-16

打赏
举报

引用 5 楼鸣鸣Amadues 的回复:

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

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

小程小程，永不消沉 2020-10-16

打赏
举报

引用 6 楼 dkwuxiang 的回复:

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

这位老铁说得对

dkwuxiang 2020-10-16

打赏
举报

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

开拓者Amadues 2020-10-16

打赏
举报

引用 15 楼 datafansbj 的回复:

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

DXF2020 2020-10-16

打赏
举报

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

KeepSayingNo 2020-10-16

打赏
举报

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

datafansbj 2020-10-16

打赏
举报

引用 13 楼鸣鸣Amadues 的回复:

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

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

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

开拓者Amadues 2020-10-16