0


在日常开发中,敏感数据应该如何保存或传输

如何保存用户密码?

说到敏感信息,第一个想到的恐怕就是用户密码了吧。攻击者一旦获取到了用户密码,就会登录用户的账号进行一系列操作。甚至有些用户还习惯不管什么应用都用同一个密码,导致攻击者可以登录用户全网账号。

为了防止用户密码泄漏,首先就要做到不保存用户密码。那不保存密码在登录的时候如何验证?其实这里说的不保存密码说的是不保存用户的原始密码,这样即使被攻击者获取到了数据库所有内容,也不会泄漏用户密码。

大部分人保存密码都会使用MD5加密之后保存。这确实是一个正确的做法,但不完全正确。

首先,MD5算法是不可逆的,是单向的,也就是说只能加密不能解密。使用 MD5 运算后得到的都是固定长度的摘要信息,无法再解密为原始数据。最重要的是,仅使用MD5加密保存,并不安全。

如下图所示,使用MD5对字符串123456进行加密,得到一个加密后的字符串

我们百度随便搜一个MD5网站,对这个密文进行解密

不到一秒就可以得到原始数据

其实大家可以想一下,虽然 MD5 不能解密,但是我们可以构建一个超大的数据库,把所有 20 位以内的数字和字母组合的密码全部计算一遍 MD5 存进去,需要解密的时候搜索一下 MD5 就可以得到原始值了。

或许多次MD5会更安全?其实并不是,下图使用两次MD5加密

再使用网站解密,同样一秒出结果,甚至类型一栏还告诉你这是两次MD5加密的数据

** MD5加盐就安全了?**确实,但是如果加盐不当,还是很不安全。有两点比较重要:

第一,不能在代码中写死盐,且盐需要有一定的长度。最好是每一个密码都有独立的盐,并且盐要长一点,比如超过 20 位。

第二,虽然说每个人的盐最好不同,但是也不建议将一部分用户数据作为盐。比如,使用用户名作为盐。盐最好是随机的值,并且是全球唯一的,意味着全球不可能有现成的字典表给你用。

比如使用UUID作为盐,把盐也存到数据库中,并且每次用户修改密码的时候都重新计算盐,重新保存新的密码。

其实更好的做法是,不要使用像 MD5 这样快速的摘要算法,而是使用慢一点的算法。比如使用BCrypt来进行密码哈希。BCrypt 是为保存密码设计的算法,相比 MD5 要慢很多。

例如,制作 8 位密码长度的 MD5 彩虹表需要 5 个月,那么对于 BCrypt 来说,可能就需要几十年,大部分攻击者应该都没有这个耐心。

最后需要注意的是,虽然攻击者已经很难通过彩虹表来破解密码了,但仍然有可能使用暴力破解,也就是对于同一个用户名使用常见的密码逐一尝试登录。因此,除了做好密码哈希保存的工作外,还要建设一套完善的安全防御机制,在感知到暴力破解危害的时候,开启短信验证、图形验证码、账号暂时锁定等防御机制来抵御暴力破解。

如何保存姓名和身份证?

在实名认证中,姓名和身份证叫做二要素。

现在互联网很发达,很多服务都可以在网上办理,很多网站仅仅依靠二要素来确认你是谁。所以,二要素是比较敏感的数据,如果在数据库中明文保存,那么数据库被攻破后,攻击者就可能拿到大量的二要素信息。如果这些二要素被用来申请贷款等,后果不堪设想……

显然这种信息不能使用单向加密来存储了,因为无法得到原始数据。这个时候就需要使用对称加密或非对称加密了。

对称加密算法,是使用相同的密钥进行加密和解密。客户端和服务端使用同一个秘钥加密解密,这种加密方式的特点是,加密速度比较快,但是密钥传输分发有泄露风险。

非对称加密算法,加密使用公钥,解密使用私钥。公钥密码是由一对密钥对构成的,使用公钥来加密,使用私钥解密,公钥可以任意公开,私钥不能公开。这种加密方式的特点是,加密速度比较慢,但是解决了密钥的配送分发安全问题。

对于保存敏感信息的场景来说,加密和解密都是我们的服务端程序,不太需要考虑密钥的分发安全性,也就是说使用非对称加密算法没有太大的意义。在这里,就使用对称加密算法来加密数据。

推荐使用AES+合适的模式进行对称加密。

使用HTTPS更安全

HTTP 协议传输数据使用的是明文。那在传输敏感信息的场景下,如果客户端和服务端中间有一个攻击者作为中间人拦截请求,就可以窃听到这些数据,还可以修改客户端传过来的数据。

这就是很大的安全隐患。为解决这个安全隐患,有了 HTTPS 协议。HTTPS=SSL/TLS+HTTP,通过使用一系列加密算法来确保信息安全传输,以实现数据传输的机密性、完整性和权威性。

机密性:使用非对称加密来加密密钥,然后使用密钥来加密数据,既安全又解决了非对称加密大量数据慢的问题。你可以做一个实验来测试两者的差距。

完整性:使用散列算法对信息进行摘要,确保信息完整无法被中间人篡改。

权威性:使用数字证书,来确保我们是在和合法的服务端通信

理解 HTTPS 的流程,将有助于我们理解各种加密算法的区别,以及证书的意义。此外,SSL/TLS 还是混合加密系统的一个典范,如果你需要自己开发应用层数据加密系统,也可以参考它的流程。

标签: 安全

本文转载自: https://blog.csdn.net/qq_41890624/article/details/126749012
版权归原作者 阿演 所有, 如有侵权,请联系我们删除。

“在日常开发中,敏感数据应该如何保存或传输”的评论:

还没有评论