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

这篇具有很好参考价值的文章主要介绍了【用户认证】密码加密,用户状态保存,cookie,session,token。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

相关概念

认证与授权

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

用户认证的逻辑

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

密码加密

加密与解密

加密

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

解密

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

加密算法

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

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

对称加密

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

常见算法:

【用户认证】密码加密,用户状态保存,cookie,session,token,网络,java,安全

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

非对称加密

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

常见算法:RSA

因为 加密 和 解密 使用的是两个不同的密钥,所以这种算法称为 非对称加密算法
【用户认证】密码加密,用户状态保存,cookie,session,token,网络,java,安全

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

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

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

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

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

散列算法

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

常见算法:md5,

加盐

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

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

协议

OAuth2

  • 准备工作 | 微信开放文档 (qq.com)
    【用户认证】密码加密,用户状态保存,cookie,session,token,网络,java,安全

【用户认证】密码加密,用户状态保存,cookie,session,token,网络,java,安全

用户登录状态的保存

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

cookie

  • 将状态保存在客户端
    【用户认证】密码加密,用户状态保存,cookie,session,token,网络,java,安全
  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);

【用户认证】密码加密,用户状态保存,cookie,session,token,网络,java,安全
3. 客户端接收响应,并保存
【用户认证】密码加密,用户状态保存,cookie,session,token,网络,java,安全

  1. 用户再次请求的时候,就会携带cookie
    【用户认证】密码加密,用户状态保存,cookie,session,token,网络,java,安全
  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,网络,java,安全

session

基于服务端的状态保存

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

流程:

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

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

  • session生命周期
    【用户认证】密码加密,用户状态保存,cookie,session,token,网络,java,安全
//通过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,网络,java,安全

优缺点

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

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

token

【用户认证】密码加密,用户状态保存,cookie,session,token,网络,java,安全

  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的保护文章来源地址https://www.toymoban.com/news/detail-520556.html

框架

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博客

到了这里,关于【用户认证】密码加密,用户状态保存,cookie,session,token的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 3-1. SpringBoot项目集成【用户身份认证】实战 【技术选型篇】基于Session、Token、JWT怎么选?

    通过第二章2-2. SpringBoot API开发详解 --SpringMVC注解+封装结果+支持跨域+打包,我们实现了基于SpringBoot项目的 API接口开发 ,并实现 API结果统一封装、支持跨域请求 等等功能,接下来开始第三章,主要做用户身份认证,主要实现一套 统一鉴权的用户身份认证的机制 。 我已经提

    2024年01月22日
    浏览(52)
  • 【Spring Security】认证&密码加密&Token令牌&CSRF的使用详解

    🎉🎉欢迎来到我的CSDN主页!🎉🎉 🏅我是Java方文山,一个在CSDN分享笔记的博主。📚📚 🌟推荐给大家我的专栏《Spring Security》。🎯🎯 👉点击这里,就可以查看我的主页啦!👇👇 Java方文山的个人主页 🎁如果感觉还不错的话请给我点赞吧!🎁🎁 💖期待你的加入,一

    2024年02月04日
    浏览(43)
  • Qt+QtWebApp开发笔记(四):http服务器使用Session和Cookie实现用户密码登录和注销功能

      前面实现了基础的跳转,那么动态交互中登录是常用功能。   本篇实现一个动态交互的简单登录和注销功能,在Qt中使用Session和Cookie技术。        链接:https://pan.baidu.com/s/1nkmsHgr-11Khe9k6Ntyf_g?pwd=1234     Web应用程序通常处理用户输入。将开发一个登录表单,看看

    2024年02月06日
    浏览(86)
  • 【全栈接口测试进阶系列教程】postman接口测试实战cookie,token,session鉴权,Base64,MD5,RSA加密,Sign签名,持续集成postman+Newman+jenkins

    目录 【一:postman简介和安装以及postman的登录和注册】 一、postman下载 二、安装、注册/登陆 三、简单使用 1.postman模拟发送get请求: 2.postman模拟发送post请求:  3.post数据类型说明: 【二:postman发送get请求,post请求实战以及页签详解】 发送GET请求 响应页面 发送POST请求 【三

    2024年02月10日
    浏览(54)
  • cookie+session和token

    总结说在前面: session:起源于服务端,保存在服务端(服务器或者数据库),通过cookie传递给用户,用户每一次发送HTTP请求的时候,通过验证cookie中的session-id来验证用户身份。 jwt(json web token):起源于服务端,保存在浏览器(cookie或者storage),和session一样,用户每一次发

    2024年02月19日
    浏览(39)
  • cookie,session和token详解

    目前网络上进行用户验证的方法主要有三种:cookie,session,token,他们之间存在相似也有各自的优缺点,本文将着重强调。 cookie是浏览器存储在本地的文件,主要用于存储服务器对用户进行的标记,大小有限一般只为4kb,用户在第一次进行服务器请求时,服务器会生成对应的

    2024年02月13日
    浏览(38)
  • cookie、session、token的区别

    HTTP无状态 当登录一个大部分网站的时候,第一次登录之后,之后的很长一段时间当我们再次访问网站的时候都不需要我们再次登录了,这个是怎么回事呢? 我们都知道http是无状态的,什么是无状态:关闭网页,再次访问服务器,服务器是不能知道是你在访问。所以就是靠接

    2024年02月08日
    浏览(32)
  • session、cookie、token的区别?

    今天就来理一理session、cookie、token这三者之间的关系! 我们都知道 HTTP 协议是无状态的,所谓的无状态就是客户端每次想要与服务端通信,都必须重新与服务端链接,意味着请求一次客户端和服务端就连接一次,下一次请求与上一次请求是没有关系的。 这种无状态的方式就

    2023年04月12日
    浏览(40)
  • cookie、session和token的区别

    作用:三者的作用是在浏览器上保存用户的登录态,其实就是实现用户在网页上登录过一次后,一段时间内再次访问不需要重新登录,会实现自动登录的一个效果。 cookie: 是客户端用来存放数据的一个容器,大小约为4k,是服务器发送到用户浏览器并保存在本地的一小块数据

    2024年02月14日
    浏览(43)
  • 九、会话控制——cookie、session、token

    HTTP是一种无状态协议,它没有办法区分多次的请求是否来自于同一个客户端,无法区分用户。而产品中又大量存在这样的需求,所以我们需要通过会话控制来解决问题。 常见的会话控制有三种: (1)cookie (2)session (3)token cookie 是HTTP服务器发送到用户浏览器并保存在本

    2024年02月11日
    浏览(39)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包