篇幅较长，请耐心读完，博主将用简明扼要的语言进行通俗讲解

1.密码学基础

1.1 为何需要加密

  不想自己的账号密码裸奔在网络上吧？不想自己的密码在数据库泄露时被黑客直接盗用吧？因此太多地方需要加密，加密后的数据还需要使用时就得进行解密。
  常见概念有：
  明文：你懂我懂大家懂，没有进行加密的数据。
  密文：明文经过加密就是密文（有可能被破解，为什么请看1.2）。
  加密算法：对明文进行加密的算法。
  解密算法：对密文进行解密的算法。
  密钥：分为公钥和私钥。密钥就是在加密和解密算法中使用的参数。对称加密中只使用私钥（为什么请看1.3），非对称加密中使用一对密钥（即公钥和私钥）。
  公钥：非对称加密中，任何方（一般来说就是客户端）都知道的密钥。
  私钥：非对称加密中，只有拥有方（一般来说就是服务器）知道的密钥
常见加密方法下方阐述。

1.2 单向散列加密的问题

  单向散列加密：加密后不需要解密。常用于数据库中存储加密后的用户密码。
  常用算法：使用MD5、SHA-512、SHA-256、bcrypt算法进行hash加密（hash算法）。
  问题：因为单向散列加密是一个明文对应一个密文，比如123456几个数字排列的密码对应了各自的密文。黑客只需建立一张表，就可以根据密文反查出用户明文密码即可。这样的表一般叫做彩虹表。当表越来越大，破解的速度就会越快。
  如何解决：一般使用的方法是加盐，具体请看2.3。

1.3 对称加密的问题

  对称加密：加密方、解密方共用一个私钥。具体流程：明文-私钥+加密算法—密文—私钥+解密算法-明文。
  常用算法：DES、3DES、TDEA、Blowfish、RC2、RC4、RC5、IDEA、SKIPJACK、AES。
  问题：因为对称加密算法是公开的，加密方、解密方共用一个私钥，如果私钥泄露，则通信双方将变得不再安全，私钥管理也变得困难。
  如何解决：使用更加安全的非对称加密。

1.4 非对称加密的问题

  对称加密：加密方用公钥加密，解密方用私钥解密，公钥加密的密文只有私钥能解，私钥加密的密文只有公钥能解。具体流程：明文-公钥+加密算法—密文—私钥+解密算法-明文。
  常用算法：RSA、ECC（椭圆曲线加密算法）、Diffie-Hellman、El Gamal、DSA（数字签名用）。
  问题：在实际使用中，一般是服务端将公钥给客户端使用，服务端自己保留私钥，这样就可以实现服务端、客户端的相对安全通信。网络攻击中有一种攻击叫中间人攻击，如果非对称加密时，黑客冒充了服务器，给了客户端黑客自己的公钥，那么黑客就可以得到客户端发送的密码等信息。这里就出现了两个问题，一是：客户端如何知道黑客没有修改服务端发给自己的信息，造成安全性问题。二是：客户端如何识别公钥的正确性问题，也可以说是服务端的有效性（正确的服务端）的问题。
  如何解决：请看1.5。

1.5 数字签名的问题

  数字签名：签名签名，顾名思义，就是服务端传给客户端数据时，给自己的数据带上一份签名，就像合同签名一样。这里的签名，需要使用服务端的私钥对数据生成一份摘要，传输时，带上这份摘要。首先，客户端收到数据后，因为只有公钥能解开私钥生成的摘要，所以可以判断数据来自服务端，1.4的问题2基本解决了，但是并没有完全解决。其次，用公钥解开摘要后的数据，和数据本身一致，则可以判断数据没有被修改，1.4的问题1也解决了。
  问题：为什么叫基本解决了1.4的问题2？因为实际上你还是没法判断服务端到底是不是黑客，它有可能只是一个中转站，数据也能传到真正的服务端，但是经过中转站时，所有数据已经泄露。
  如何解决：为了解决服务端的正确性的问题，引入了数字证书，请看1.6。

1.6 什么是数字证书

  数字证书：因为无法验证服务端的有效性问题。所以客户端要求服务端去公信机构（CA）做认证。CA有自己的私钥，也有自己的公钥。服务端做认证时，CA会使用自己的私钥将服务端的一些信息+服务端的公钥生成一个数字证书。客户端保留了很多公信机构的公钥，这时服务端再把公钥拿给客户端时会带上CA的数字证书，客户端用CA的公钥打开数字证书，也就可以拿到服务端的公钥以及域名等信息。这样就可以判断服务端的有效性，以及可以判断域名和正在访问的域名是否一致了。
  在什么地方使用：Https协议就使用了数字证书。而且在浏览器客户端中也保留了许多的CA机构的公钥。我们在开发Android应用是，也需要设置访问域名认证的CA机构的公钥。我们开发服务端时，想要使用Https协议安全传输数据，就得花钱申请一个数字证书，然后提供给浏览器或者App使用Https协议啦！
  延伸：请看本文第3点Https基本原理。

2.Https基本原理

2.1 什么是Https

  Https协议 = Http协议 + SSL/TLS协议。Http协议又叫超文本传输协议，是一种运行在应用层的网络协议，是基于传输层TCP/IP协议的协议。Https是在Http基础上加上了SSL或TLS加密协议的安全协议，确保了通信双方的安全。Http协议采用的是明文传输，但是Https则是使用了数字证书的形式去传输加密信息。所以，大多数需要信息加密的网站，都是采用的https协议。而一般的政府公开网站，则是采用http协议即可。

2.2 Https的性能问题

  由于Https协议采用了数字证书，但是由于非对称加密过程复杂，可会造成性能问题，所以Https是由对称加密和非对称加密联合使用的。其过程是：先使用非对称加密去协商一个仅双方知道的私钥，然后再根据协商私钥去进行对称加密通信。

2.3 Https具体的流程

协商私钥流程：

1. 服务器端的公钥和私钥，用来进行非对称加密
2. 客户端生成的随机密钥，用来进行对称加密

具体流程：

1. 客户端向服务器发起HTTPS请求，连接到服务器的443端口。
2. 服务端有一对密钥，即公钥和私钥，一般是用钱注册得来。
3. 服务端将自己的公钥发送给客户端。
4. 客户端根据数字证书验证服务端合法性，并生成一个随机密钥。至此，HTTPS中的第一次HTTP请求结束。
5. 客户端会发起HTTPS中的第二个HTTP请求，用服务端公钥对随机密钥进行加密后发送给服务端。
6. 服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后的明文就是客户端密钥，然后用客户端随机密钥对数据进行对称加密，这样数据就变成了密文。
7. 然后服务器将加密后的密文发送给客户端。
8. 客户端收到服务器发送来的密文，用客户端随机密钥对其进行对称解密，得到服务器发送的数据。这样HTTPS中的第二个HTTP请求结束，整个HTTPS传输完成。

2.4 Https在浏览器和Android客户端中的使用

推荐参考文章

3.web安全基础

3.1 web安全导致的事故

  2011年12月，国内最大的程序员社区遭拖库，600万个账户信息泄露。
  2014年3月，携程旅行网的系统存技术漏洞，漏洞可能导致用户的姓名、身份证号码、银行卡类别、银行卡卡号、银行卡CVV码以及银行卡6位Bin泄露。
  2014年5月，小米论坛涉及800万用户信息遭泄露，信息包括用户名、密码、注册IP、邮箱等。
  2014年12月，12306遭撞库攻击，13万用户信息泄露，包括用户账号、明文密码、身份证、邮箱等敏感信息。
  2015年10月，网易邮箱遭攻击，近5亿条用户信息被泄露，包括用户名、密码、密码保护信息、登陆IP以及用户生日等多个原始信息。
  不可思议吧？这么多大公司大网站的系统都遭到攻击，泄露用户信息，更别说其他小网站了。这些攻击都可以从技术上来进行防范的，但是我们看到即使是大公司，安全方面也是那么的薄弱。

3.2 web安全存在的问题

  从用户敲出的第一个字符开始，我们就需要对数据使用正确的姿势去操作。
  正确的姿势有：
  1. 用正确的姿势保存密码。
  2. 用正确的姿势传输数据。
  3. 用正确的姿势加密敏感信息。
  4. 用正确的姿势对数据进行备份和监控。

3.3 保存密码

  保存密码原理：使用单向散列加密，但是光是单向散列加密是不行的，我们得加点盐（salt）。加盐的好处是可以让密码长度更长，加密后强度更强。黑客进行逆推或者撞库（猜）的难度更大。一般来说进行两次加盐MD5就行了，如：md5(md5(pwd) + salt)。
  问题：我们在单向散列加密中说到了彩虹表的问题。直接使用MD5的hash算法加密，可能会被暴力破解。
  解决：所以我们需要使用加盐的方法使我们数据库中加密后的密码更加难以被破解。最关键的是 salt 从哪里来？ salt 该怎么设置才能安全。

1. 不要使用固定不变的 salt。
2. 每个用户的 salt 都需要不同。
3. salt 要保持一定的长度。
4. salt 必须由服务端使用安全的随机函数生成。
5. 客户端运算需要的 salt 需要从服务端动态获取。
6. 客户端加盐 hash 的结果并不是最终服务端存盘的结果

3.4 传输数据

  传输数据我们在数字证书那里已经讲到了，并且Https也是一种可靠的传输数据的手段，你也可以使用其他方式替代Https，但是中间人攻击就没多大办法，当然，这里的中间人攻击得到的也是不能够破解的数据。

3.5 加密敏感信息

  用户的密码不能明文保存，而且要使用不可逆的加密算法，只保存最终的 hash 结果用来验证是否正确。那用户其他的敏感信息呢？比如身份证、银行卡、信用卡等信息，该如何加密保存而不被泄露呢？
  对于身份证信息，可以像密码一样只保存 hash 的结果，可以用于用户输入身份证号后进行验证。假如需要给用户显示身份证信息，只需要保存抹掉了几位数字的身份证号。
  假如你的系统涉及到支付，需要用户的银行卡，信用卡（卡号，CVV码）等信息时，必须遵循 PCI DSS （第三方支付行业数据安全标准）标准。
  如果只是银行卡，还需要遵循 ADSS （银联卡收单机构账户信息安全管理标准） 标准。

3.6 对数据进行备份和监控

  主要措施有：磁盘 raid，物理备份（磁带库），异地的逻辑备份。同时做好权限控制，并对访问记录做好监控，及时发现问题，保留现场证据。

参考文章：
https://www.wosign.com/News/news_2018101101.htm
https://blog.csdn.net/iispring/article/details/51615631
https://www.easemob.com/news/3706
https://blog.coderzh.com/2016/01/03/security-design/
https://blog.coderzh.com/2016/01/10/a-password-security-design-example/
https://blog.coderzh.com/2016/01/13/password-security-additional/