【用户认证】密码加密,用户状态保存,cookie,session,token

相关概念

认证与授权

认证(authentication )是验证你的身份的过程,而授权(authorization)是验证你有权访问的过程

用户认证的逻辑

  1. 获取用户提交的用户名和密码
  2. 根据用户名,查询数据库,获得完整的用户信息,包括真正的密码
  3. 比较提交的密码和查询到的密码
  4. 如果二者相等,则用户认证成功;否则用户认证失败

密码加密

加密与解密

加密

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

解密

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

加密算法

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

常见的 对称加密 算法主要有 DES3DESAES 等
常见的 非对称算法 主要有 RSADSA 等
散列算法 主要有 SHA-1MD5 等。

对称加密

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

常见算法:

【用户认证】密码加密,用户状态保存,cookie,session,token_第1张图片

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

非对称加密

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

常见算法:RSA

因为 加密 和 解密 使用的是两个不同的密钥,所以这种算法称为 非对称加密算法
【用户认证】密码加密,用户状态保存,cookie,session,token_第2张图片

  1. 如果使用 公钥 对数据 进行加密,只有用对应的 私钥 才能 进行解密
  2. 如果使用 私钥 对数据 进行加密,只有用对应的 公钥 才能 进行解密

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

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

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

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

散列算法

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

常见算法:md5,

加盐

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

  • 密码加密——加盐算法(两种方式)_fiance111的博客-CSDN博客

协议

OAuth2

  • 准备工作 | 微信开放文档 (qq.com)
    【用户认证】密码加密,用户状态保存,cookie,session,token_第3张图片

【用户认证】密码加密,用户状态保存,cookie,session,token_第4张图片

用户登录状态的保存

HTTP 是一种不保存状态,即无状态(stateless)协议。

cookie

  • 将状态保存在客户端
    【用户认证】密码加密,用户状态保存,cookie,session,token_第5张图片
  1. 客户端访问服务端的登录接口
  2. 服务端根据请求的用户名和密码,认证用户,认证成功后,向响应中写入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,session,token_第6张图片

  1. 用户再次请求的时候,就会携带cookie
    【用户认证】密码加密,用户状态保存,cookie,session,token_第7张图片
  2. 服务端如果可以访问cookie,则可以从中取出数据
Cookie[] cookies = req.getCookies();  
if(cookies!=null){  
    for (Cookie cookie : cookies) {  
        System.out.println(cookie.getName()+" "+cookie.getValue());  
    }  
}

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

优缺点

【用户认证】密码加密,用户状态保存,cookie,session,token_第8张图片

session

基于服务端的状态保存

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

流程:

  1. 首次使用到 Session时,服务器会自动创建 Session和JSeeisonID,并创建 Cookie用来存储 JSessionId发送回客户端,
    Pasted image 20220613142745.png
  2. 下一次统一浏览器再次访问服务器的时候,就会通过cookie携带JSessionId,来获取原来的Session
  • 作用域
    • 一次会话(可能有多次请求,浏览器关闭,会话结束)有效
    • 不同组件之间的session可以共享,java中有一块专门的内存保存session

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

  • session生命周期
    【用户认证】密码加密,用户状态保存,cookie,session,token_第9张图片
//通过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集中管理

【用户认证】密码加密,用户状态保存,cookie,session,token_第10张图片

优缺点

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

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

token

【用户认证】密码加密,用户状态保存,cookie,session,token_第11张图片

  1. 客户端请求服务端登录
  2. 服务端验证用户之后,返回响应的时候,生成一个token
    1. 常见生成token的方式就是JWT
  3. 客户端接收响应,并保存token到localStor age或sessionStorage
  4. 客户端下一次访问服务端的时候,就通过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的保护

框架

Spring Security

  • Spring Security
  • Spring Security Community :: Spring Security

Shrio

参考资料

  • 认证 vs 授权 | Authing 文档
  • Token的详细说明,看这一篇就够了 - 简书 (jianshu.com)
  • JSON Web Token 入门教程 - 阮一峰的网络日志 (ruanyifeng.com)
  • 4种分布式session解决方案_断橋殘雪的博客-CSDN博客
  • session-cookie,jwt状态保持的差异,以及优缺点_他们叫我浪浪的博客-CSDN博客
  • 浅谈常见的七种加密算法及实现 - 知乎 (zhihu.com)
  • 对称加密和非对称的加密 的优缺点和理解 - 知乎 (zhihu.com)
  • 密码加密——加盐算法(两种方式)_fiance111的博客-CSDN博客

你可能感兴趣的:(网络,java,安全)