如何保存用户密码？
说到敏感信息，第一个想到的恐怕就是用户密码了吧。攻击者一旦获取到了用户密码，就会登录用户的账号进行一系列操作。甚至有些用户还习惯不管什么应用都用同一个密码，导致攻击者可以登录用户全网账号。
为了防止用户密码泄漏，首先就要做到不保存用户密码。那不保存密码在登录的时候如何验证？其实这里说的不保存密码说的是不保存用户的原始密码，这样即使被攻击者获取到了数据库所有内容，也不会泄漏用户密码。
大部分人保存密码都会使用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 还是混合加密系统的一个典范，如果你需要自己开发应用层数据加密系统，也可以参考它的流程。
