27 | 保密：系统如何保证敏感数据无法被内外部人员窃取滥用？
保密的强度
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
客户端加密在信息系统中备受争议，对于保护密码不被服务端滥用仍具有意义。然而，网络通讯的不安全性使得客户端加密最终成为“马其诺防线”，容易受到中间人攻击的威胁。客户端加密并不能完全防御泄密。在服务端处理信息的保密问题上，动态加盐传输通常得不偿失，无论是否动态加盐，都无法替代HTTPS的安全性。真正的密码加密存储应该在服务端进行，以防止服务端被攻破而批量泄露密码的风险。权衡安全强度与成本，确定适合特定系统的保密措施至关重要。 文章以Fenix's Bookstore中的密码存储和验证代码为例，介绍了在信息系统中密码从客户端传输到服务端，然后存储进数据库的过程。针对普通安全强度的信息系统，密码需要在具有一定保密安全性的同时，避免消耗过多运算资源，以便验证相对便捷。客户端对用户密码进行哈希摘要和加盐处理，以防御彩虹表攻击。建议采用慢哈希函数来解决暴力破解，如BCrypt算法。在服务端存储密码时，为每一个密码产生一个随机的盐值，采用CSPRNG生成随机字符串。最终的密文和随机生成的盐值一起写入到数据库记录中。文章强调了安全不是二元选项，而是连续值，需要权衡取舍。客户端加密、服务端解密的操作意义需要明确，架构设计时必须权衡取舍。 总的来说，文章通过具体代码示例和技术讨论，深入探讨了密码存储和验证的安全性问题，强调了在信息系统中权衡安全强度与成本的重要性。
请先领取课程
全部留言(15)
- 最新
- 精选
刘峰P(62,10)/(360024365)/0.1=1,237,204,169 ，没有看明白。 1. P(62,10)是62取10的排列，这么多种密码。 2. 360024365，是什么意思呢，为什么要除以？ 3. 除以0.1，每个hash计算0.1秒，如果前面算出来的是需要hash数量，应该乘以吧？作者回复: 62=26*2的大小写字母+10个数字 360024365是3600*24*365，即3600秒*24小时*365天。这个bug估计是markdown格式吃掉*号导致的。
2021-01-285
马成Spring Security 5 中的 BcryptPasswordEncoder。但是请注意，它默认构造函数中的 Cost 参数值为 -1，实际只进行了 2 的 -1 次方 =1 次计算，所以不会对服务端造成额外的压力。 我看了BCryptPasswordEncoder里面的源码，cost（即strength）确实默认-1，但是构造函数里面有个转换，如果传入值是-1，则把它转换成10作者回复: 是的，这里有问题，勘误在：https://icyfenix.cn/architect-perspective/general-architecture/system-security/confidentiality.html
2021-04-09- 马成慢哈希BCrypt每次运行的结果都不一样，注册和登录产生的client_hash都不一致，服务端的密码校验怎么能通过呢？
作者回复: 哈希函数的基本特征是只要输入参数一致，输出结果必定一致。 每次运行结果都不一样的话，检查以下参数哪里发生变动了。
2021-03-312 
Vincet要如何防范客户端加密算法被窃取呢，比如web端中要处理加密过程，代码必然写在js中，如果通过浏览器下载到这些js文件，不就能推断出加密过程了吗作者回复: 现代的加密算法都是公开的，不依靠保护加密过程来保证安全。 而且，文中的观点是客户端无论如何加密，对传输的安全性提升都几乎没有帮助。
2021-01-205
zhanyd密码加密是为了防止服务器被黑后密码泄露的问题，并不是为了增强传输过程的安全性。 如果服务端被拖库，慢哈希，随机的盐值，都是为了增加破解密码的难度。2021-01-19117
lupguo我以前做账号登录也是直接使用应用salt，没有针对单个用户配置salt，即判断service_hash == Sha256(client_hash + 应用salt) 一般做法： 1. 密码要求组合强密码 2. 注册、登录过程，密码通过hash函数在客户端计算client_hash=Sha256(password)，随表达传递给到服务端 3. 传输过程使用HTTPS协议 4. 服务端生成username的service_hash，即service_hash == Sha256(client_hash + 应用salt)，应用salt是存储在配置中心或配置文件 5. 针对登录增加防水墙，避免恶意登录攻击 6. 登录监控阈值告警（人工介入），另外提做好FMEA预期，比如黑名单、恶意IP屏蔽之类的 7. 针对密码修改、账号绑定等功能，增加2FMA双因子认证，Web开启Waf防护，避免业务BUG导致账户安全问题 按上面做下来，恶意攻击、脱库、彩虹表、中间人也都能防住，也不担心用户的明文密码泄露到服务端（烫手山芋提前打包了），加上监控遇到异常情况下，也能第一时间人为介入，算上给账号系统加固了2023-12-29归属地：广东2
LYF为了保证密码不在服务端被滥用，而在客户端就开始加密的做法，还是很有意义的。 周老师好，这里说的被服务端滥用的情况都具体都有哪些呢？2022-09-16归属地：北京11
文进传输过程加密：传输过程中，只能通过https进行防护，而且https只保证传输过程中安全，只保证用户在不知情的情况下被抓包监听。如果用户手工安装启用抓包工具，其实是将抓包工具的证书安装到客户端，由抓包工具作为中间人代理，与服务端和客户端进行交互，这个不属于https防护的范围。 客户端加密：客户端自身的安全不属于https范围，客户端如果被破解，密码还是能被获取到，所以就认为这个客户端是一定会被取到的。客户端加密，作用是避免密码明文传输到后端后被服务端滥用。 服务端加密：服务端产生随机动态盐，参与加密，并将动态盐放到加密后的前32位。后面校验时，客户端传来字符串，与加密后的密码的前32位盐进行加密运算，比较最终得到的加密结果是否和数据库中的一致。服务端再次随机盐加密，可以防止拖库后，彩虹表破解密码，因为每个密码的盐都不一样，彩虹表如果想进行破解，耗费成本过于高。2022-06-151
stg609既然 "保证信息不被黑客窃取而去做客户端加密" 是没有意义的，那为什么在 "密码存储和验证" 的环节多次提到了 "攻击者截获了客户端发出的信息" 类似的描述，这个应该是传输层安全要考虑的，和密码存储有什么关系吗？2023-08-02归属地：浙江
锐服务端盐值也是存储在数据库，那么被拖库了，是不是盐值也没意义了2022-09-02归属地：广东