密码加密

加密与解密

加密

数据加密 的基本过程，就是对原来为明文的文件或数据按 某种算法 进行处理，使其成为 不可读 的一段代码，通常称为 “密文”。通过这样的途径，来达到 保护数据 不被 非法人窃取、阅读的目的。

解密

加密的 逆过程 为解密，即将该 编码信息 转化为其 原来数据 的过程。

加密算法

加密算法分 对称加密 和 非对称加密，其中对称加密算法的加密与解密 密钥相同，非对称加密算法的加密密钥与解密 密钥不同，此外，还有一类 不需要密钥 的 散列算法。

常见的 对称加密 算法主要有 DES、3DES、AES 等
常见的 非对称算法 主要有 RSA、DSA 等
散列算法 主要有 SHA-1、MD5 等。

对称加密

对称加密算法 是应用较早的加密算法，又称为 共享密钥加密算法。在 对称加密算法 中，使用的密钥只有一个，发送和接收双方都使用这个密钥对数据进行加密和解密。这就要求加密和解密方事先都必须知道加密的密钥。

常见算法：

数据加密过程：在对称加密算法中，数据发送方 将明文 (原始数据) 和 加密密钥 一起经过特殊 加密处理，生成复杂的 加密密文 进行发送。
数据解密过程：数据接收方 收到密文后，若想读取原数据，则需要使用 加密使用的密钥 及相同算法的 逆算法 对加密的密文进行解密，才能使其恢复成 可读明文。

非对称加密

非对称加密算法，又称为 公开密钥加密算法。它需要两个密钥，一个称为 公开密钥 (public key)，即公钥，另一个称为 私有密钥 (private key)，即私钥。

常见算法：RSA

因为加密和解密使用的是两个不同的密钥，所以这种算法称为 非对称加密算法。

如果使用公钥对数据 进行加密，只有用对应的私钥才能 进行解密。
如果使用私钥对数据 进行加密，只有用对应的公钥才能 进行解密。

例子：甲方生成 一对密钥 并将其中的一把作为公钥向其它人公开，得到该公钥的乙方使用该密钥对机密信息 进行加密 后再发送给甲方，甲方再使用自己保存的另一把 专用密钥 (私钥)，对加密后的信息 进行解密。

比较：
（1）对称加密加密与解密使用的是同样的密钥，所以速度快，但由于需要将密钥在网络传输，所以安全性不高。

（2）非对称加密使用了一对密钥，公钥与私钥，所以安全性高，但加密与解密速度慢。

（3）解决的办法是将对称加密的密钥使用非对称加密的公钥进行加密，然后发送出去，接收方使用私钥进行解密得到对称加密的密钥，然后双方可以使用对称加密来进行沟通。

散列算法

一类 不需要密钥 的 散列算法。

常见算法：md5,

加盐

密码一般不会直接明文存储
会通过使用一定的算法，例如md5，进行加密存储
但是存在暴力破解的可能
解决方法：最终密码=其他+盐值+md5（明文密码+盐值）
大大提高了安全性
盐值：随机的一段字符串

密码加密——加盐算法（两种方式）_fiance111的博客-CSDN博客

协议

OAuth2

准备工作 | 微信开放文档 (qq.com)

用户登录状态的保存

HTTP 是一种不保存状态，即无状态（stateless）协议。

cookie

将状态保存在客户端

客户端访问服务端的登录接口
服务端根据请求的用户名和密码，认证用户，认证成功后，向响应中写入Cookie

//创建cookie  
Cookie cookie = new Cookie("islegal","yes");  
//设置cookie的访问路径(哪些请求路径可以访问cookie)，默认所有都可以访问  
cookie.setPath("/project1/checkServlet");  
//设置生命周期，取值有三种:
 //大于0，单位是秒；
 //等于0，浏览器关闭
 //小于0，-1 （默认）内存释放  
cookie.setMaxAge(60*60);  
resp.addCookie(cookie);

Pasted image 20220613142653.png
3. 客户端接收响应，并保存

用户再次请求的时候，就会携带cookie
服务端如果可以访问cookie,则可以从中取出数据

Cookie[] cookies = req.getCookies();  
if(cookies!=null){  
    for (Cookie cookie : cookies) {  
        System.out.println(cookie.getName()+" "+cookie.getValue());  
    }  
}

tip:
如何修改cookie?
新创建cookie,只要路径和cookie的名称一致，就可以修改cookie值

优缺点

Pasted image 20220613140452.png

session

基于服务端的状态保存

服务器会为每一次会话分配一个 Session对象
同一个浏览器发起的多次请求,同属于一次会话( Session)

流程：

首次使用到 Session时,服务器会自动创建 Session和JSeeisonID,并创建 Cookie用来存储 JSessionId发送回客户端,
下一次统一浏览器再次访问服务器的时候，就会通过cookie携带JSessionId,来获取原来的Session

作用域
- 一次会话(可能有多次请求，浏览器关闭，会话结束)有效
- 不同组件之间的session可以共享,java中有一块专门的内存保存session

钝化：指关闭服务器后，未关闭浏览器，存储在session中的数据会通过序列化存储在磁盘上
活化：指session中的数据被钝化过的浏览器未关闭，服务器重新启动并将存储在磁盘上的数据读取到session中

session生命周期

//通过req获得session ，
//有一个boolean参数，默认true，没有则会创建一个新的会话;false如果没有回话，则不会创建
HttpSession session = request.getSession();  
System.out.println(session.getId());  
//保存数据  
session.setAttribute("name","gao");  
//获取数据  
String  name = (String)session.getAttribute("name");  
//移除数据  
session.removeAttribute("name");  
//设置sesison的最大有效时间，单位秒  
session.setMaxInactiveInterval(60*60);  
//手动销毁  
session.invalidate();

分布式

cookie

之前的方案都是在服务器端进行改造的，cookie方案是客户端的方案，就是把session信息保存到cookie中，即用户信息保存到cookie中，这样就不需要服务器保存session（用户信息）了。每次请求时，把此cookie传给服务器端，这样服务器端就知道是哪个用户了。

此方案比较实现比较简单，而且还不占用服务器端的内存资源。但是此方案的问题很大哦。

1、cookie在客户端是有限的，存储容量也是很小的
2、安全是很有问题的，因为保存在本地，很容易被人拿到

session复制

session复制是小型企业应用使用较多的一种服务器集群session管理机制，在真正的开发使用的并不是很多，通过对web服务器(例如Tomcat)进行搭建集群。

存在的问题：

session同步的原理是在同一个局域网里面通过发送广播来异步同步session的，一旦服务器多了，并发上来了，session需要同步的数据量就大了，需要将其他服务器上的session全部同步到本服务器上，会带来一定的网路开销，在用户量特别大的时候，会出现内存不足的情况

优点：

服务器之间的session信息都是同步的，任何一台服务器宕机的时候不会影响另外服务器中session的状态，配置相对简单

Tomcat内部已经支持分布式架构开发管理机制，可以对tomcat修改配置来支持session复制，在集群中的几台服务器之间同步session对象，使每台服务器上都保存了所有用户的session信息，这样任何一台本机宕机都不会导致session数据的丢失，而服务器使用session时，也只需要在本机获取即可

session绑定（黏贴）

我们利用nginx的反向代理和负载均衡，之前是客户端会被分配到其中一台服务器进行处理，具体分配到哪台服务器进行处理还得看服务器的负载均衡算法(轮询、随机、ip-hash、权重等)，但是我们可以基于nginx的ip-hash策略，可以对客户端和服务器进行绑定，同一个客户端就只能访问该服务器，无论客户端发送多少次请求都被同一个服务器处理

缺点：

容易造成单点故障，如果有一台服务器宕机，那么该台服务器上的session信息将会丢失
前端不能有负载均衡，如果有，session绑定将会出问题

优点：

配置简单

redis:session集中管理

优缺点

session优点：
1.session中的信息存储在服务端，相比于cookie就在一定程度上加大了数据的安全性。
2.session数据存储在服务端，相比于jwt方便进行管理，也就是说当用户登录和主动注销，只需要添加删除对应的session就可以，这样管理起来很方便。

session缺点：
1.session存储在服务端，这就增大了服务器的开销，当用户多的情况下，服务器性能会大大降低。
3、因为是基于cookie来进行用户识别的, cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击。
4、用户认证之后，服务端做认证记录，如果认证的记录被保存在内存中的话，这意味着用户下次请求还必须要请求在这台服务器上,这样才能拿到授权的资源，这样在分布式的应用上，相应的限制了负载均衡器的能力。这也意味着限制了应用的扩展能力。

token

客户端请求服务端登录
服务端验证用户之后，返回响应的时候，生成一个token
1. 常见生成token的方式就是JWT
客户端接收响应，并保存token到localStor age或sessionStorage
客户端下一次访问服务端的时候，就通过Header携带token

JWT

JSON Web Tokens

JWT 标准的 Token 有三个部分：

1.header(头部)，头部信息主要包括（参数的类型–JWT,签名的算法–HS256）
2.poyload(负荷)，负荷基本就是自己想要存放的信息(因为信息会暴露，不应该在载荷里面加入任何敏感的数据)
3.sign(签名)，签名的作用就是为了防止恶意篡改数据

中间用点分隔开，并且都会使用 Base64 编码，所以真正的 Token 看起来像这样：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ.SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc

Header

Header 部分主要是两部分内容，一个是 Token 的类型，另一个是使用的算法，比如下面类型就是 JWT，使用的算法是 HS256。

{
    "typ" : "JWT",
    "alg" : "HS256"
}

上面的内容要用 Base64 的形式编码一下，所以就变成这样：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Payload

Payload 里面是 Token 的具体内容，这些内容里面有一些是标准字段，你也可以添加其它需要的内容。下面是标准字段：

iss：Issuer，发行者
sub：Subject，主题
aud：Audience，观众
exp：Expiration time，过期时间
nbf：Not before
iat：Issued at，发行时间
jti：JWT ID

比如下面这个 Payload，用到了 iss 发行人，exp 过期时间，另外还有两个自定义的字段，一个是 name ，还有一个是 admin 。

{
    "iss" : "csdn.net",
    "exp" : "201511205211314",
    "name" : "维C果糖",
    "admin" : true
}

使用 Base64 编码以后就变成了这个样子：

eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ

Signature

JWT 的最后一部分是 Signature ，这部分内容有三个部分，先是用 Base64 编码的 header 和 payload ，再用加密算法加密一下，加密的时候要放进去一个 Secret ，这个相当于是一个密钥，这个密钥秘密地存储在服务端。

header
payload
secret
var encodedString = base64UrlEncode(header) + "." + base64UrlEncode(payload); 
HMACSHA256(encodedString, 'secret');

处理完成以后看起来像这样：

SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc

最后这个在服务端生成并且要发送给客户端的 Token 看起来像这样：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ.SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc

客户端收到这个 Token 以后把它存储下来，下回向服务端发送请求的时候就带着这个 Token 。服务端收到这个 Token ，然后进行验证，通过以后就会返回给客户端想要的资源。

服务端如何验证？
和生成signature的方式一样，然后比较signature是否一样

优缺点

不需要在服务端保存会话信息，特别适用于分布式微服务。
自包含(Self-contained):负载中包含了所有用户所需要的信息，避免了多次查询数据库
简洁(Compact):可以通过URL， POST参数或者在HTTP header发送，因为数据量小，传输速度也很快
因为Token是以JSON加密的形式保存在客户端的，所以JWT是跨语言的，原则上任何web形式都支持。

安全问题

CSRF

- 35.CSRF_哔哩哔哩_bilibili

当网站使用cookie保存用户登陆状态时，可能受到恶意站点的诱导，在不知道的情况下下向目标网站发起敏感请求
csrf保护就是当向目标网站发起敏感请求时，要求携带csrf_token,这是一个客户端浏览器附带的伪随机数，通过恶意站点发送的请求不会携带这个数据
springsecurity默认开启csrf保护，对于put,post等方法（不包含get),要求请求时携带csrf_token,前后分离项目本来就是使用token,不必开启csrf的保护