利用虚拟主机建设网站的实验报告,网站建设需求分析报告,wordpress 资源站模板,装门做特卖的网站1 认证
1 传统的session-cookie机制
HTTP协议是无状态协议#xff0c;为了解决它产生了cookie和session技术。
浏览器发起第一次请求到服务器#xff0c;服务器发现浏览器没有提供session id#xff0c;就认为这是第一次请求#xff0c;会返回一个新的session id给浏览器…1 认证
1 传统的session-cookie机制
HTTP协议是无状态协议为了解决它产生了cookie和session技术。
浏览器发起第一次请求到服务器服务器发现浏览器没有提供session id就认为这是第一次请求会返回一个新的session id给浏览器端。浏览器只要不关闭这个session id就会随着每一次请求重新发给服务器端服务器端查找这个session id如果查到就认为是同一个会话。如果没有查到就认为是新的请求。session是会话级的可以在这个会话session中创建很多数据连接断开session清除包括session id。这个session id还得有过期的机制一段时间如果没有发起请求认为用户已经断开就清除session。浏览器端也会清除响应的cookie信息。
服务器端保存着大量session信息很消耗服务器内存而且如果多服务器部署还要考虑session共享的问题比如redis、memcached等方案。
2 无session方案-JWT
既然服务端就是需要一个ID来表示身份那么不使用session也可以创建一个ID返回给客户端。但是要保证客户端不可篡改。 服务端生成一个标识并使用某种算法对标识签名. 服务端收到客户端发来的标识需要检查签名。 这种技术称为JWT(Json Web Token)
JWT的缺点是
加解密需要消耗CPU计算资源无法让浏览器自己主动检查过期的数据以清除。
3 token进行用户身份验证的流程
客户端使用用户名和密码请求登录服务端收到请求验证用户名和密码验证成功后服务端会签发一个token再把这个token返回给客户端客户端收到token后可以把它存储起来比如放到cookie中客户端每次向服务端请求资源时需要携带服务端签发的token可以在cookie或者header中携带服务端收到请求然后去验证客户端请求里面带着的token如果验证成功就向客户端返回请求数据
4 token认证方式与session认证方式比较
基于token的认证方式相比传统的session认证方式更节约服务器资源并且对移动端和分布式更加友好。其优点如下
支持跨域访问cookie是无法跨域的而token由于没有用到cookie(前提是将token放到请求头中)所以跨域后不会存在信息丢失问题无状态token机制在服务端不需要存储session信息因为token自身包含了所有登录用户的信息所以可以减轻服务端压力更适用CDN可以通过内容分发网络请求服务端的所有资料更适用于移动端当客户端是非浏览器平台时cookie是不被支持的此时采用token认证方式会简单很多无需考虑CSRF由于不再依赖cookie所以采用token认证方式不会发生CSRF所以也就无需考虑CSRF的防御
而JWT就是上述流程当中token的一种具体实现方式其全称是JSON Web Token官网地址https://jwt.io/
通俗地说JWT的本质就是一个字符串它是将用户信息保存到一个Json字符串中然后进行编码后得到一个JWT token并且这个JWT token带有签名信息接收后可以校验是否被篡改所以可以用于在各方之间安全地将信息作为Json对象传输。JWT的认证流程如下
首先前端通过Web表单将自己的用户名和密码发送到后端的接口这个过程一般是一个POST请求。建议的方式是通过SSL加密的传输(HTTPS)从而避免敏感信息被嗅探后端核对用户名和密码成功后将包含用户信息的数据作为JWT的Payload将其与JWT Header分别进行Base64编码拼接后签名形成一个JWT Token形成的JWT Token就是一个如同lll.zzz.xxx的字符串后端将JWT Token字符串作为登录成功的结果返回给前端。前端可以将返回的结果保存在浏览器中退出登录时删除保存的JWT Token即可前端在每次请求时将JWT Token放入HTTP请求头中的Authorization属性中(解决XSS和XSRF问题)后端检查前端传过来的JWT Token验证其有效性比如检查签名是否正确、是否过期、token的接收方是否是自己等等验证通过后后端解析出JWT Token中包含的用户信息进行其他逻辑操作(一般是根据用户信息得到权限等)返回结果 2 为什么要用JWT
1 传统Session认证的弊端
我们知道HTTP本身是一种无状态的协议这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证认证通过后HTTP协议不会记录下认证后的状态 那么下一次请求时用户还要再一次进行认证因为根据HTTP协议我们并不知道是哪个用户发出的请求所以为了让我们的应用能识别是哪个用户发出的请求 我们只能在用户首次登录成功后在服务器存储一份用户登录的信息这份登录信息会在响应时传递给浏览器告诉其保存为cookie以便下次请求时发送给我们的应用 这样我们的应用就能识别请求来自哪个用户了这是传统的基于session认证的过程。
然而传统的session认证有如下的问题
每个用户的登录信息都会保存到服务器的session中随着用户的增多服务器开销会明显增大由于session是存在与服务器的物理内存中所以在分布式系统中这种方式将会失效。虽然可以将session统一保存到Redis中但是这样做无疑增加了系统的复杂性对于不需要redis的应用也会白白多引入一个缓存中间件对于非浏览器的客户端、手机移动端等不适用因为session依赖于cookie而移动端经常没有cookie因为session认证本质基于cookie所以如果cookie被截获用户很容易收到跨站请求伪造攻击。并且如果浏览器禁用了cookie这种方式也会失效前后端分离系统中更加不适用后端部署复杂前端发送的请求往往经过多个中间件到达后端cookie中关于session的信息会转发多次由于基于Cookie而cookie无法跨域所以session的认证也无法跨域对单点登录不适用
2 JWT认证的优势
对比传统的session认证方式JWT的优势是
简洁JWT Token数据量小传输速度也很快因为JWT Token是以JSON加密形式保存在客户端的所以JWT是跨语言的原则上任何web形式都支持不需要在服务端保存会话信息也就是说不依赖于cookie和session所以没有了传统session认证的弊端特别适用于分布式微服务单点登录友好使用Session进行身份认证的话由于cookie无法跨域难以实现单点登录。但是使用token进行认证的话 token可以被保存在客户端的任意位置的内存中不一定是cookie所以不依赖cookie不会存在这些问题适合移动端应用使用Session进行身份认证的话需要保存一份信息在服务器端而且这种方式会依赖到Cookie需要 Cookie 保存 SessionId所以不适合移动端
因为这些优势目前无论单体应用还是分布式应用都更加推荐用JWT token的方式进行用户认证 3 JWT结构
JWT由3部分组成标头(Header)、有效载荷(Payload)和签名(Signature)。在传输的时候会将JWT的3部分分别进行Base64编码后用.进行连接形成最终传输的字符串: JWTStringBase64(Header).Base64(Payload).HMACSHA256(base64UrlEncode(header).base64UrlEncode(payload),secret)
1. Header
JWT头是一个描述JWT元数据的JSON对象alg属性表示签名使用的算法默认为HMAC SHA256写为HS256typ属性表示令牌的类型JWT令牌统一写为JWT。 最后使用Base64 URL算法将上述JSON对象转换为字符串保存
header {alg: HS256,typ: JWT
}2.Payload
有效载荷部分是JWT的主体内容部分也是一个JSON对象包含需要传递的数据。 JWT指定七个默认字段供选择
# iss发行人
# exp到期时间
# sub主题
# aud用户
# nbf在此之前不可用
# iat发布时间
# jtiJWT ID用于标识该JWT
# 这些预定义的字段并不要求强制使用。除以上默认字段外我们还可以自定义私有字段一般会把包含用户信息的数据放到payload中如下例
payload {sub: 1234567890,name: Helen,admin: True
}请注意: 默认情况下JWT是未加密的因为只是采用base64算法拿到JWT字符串后可以转换回原本的JSON数据任何人都可以解读其内容 因此不要构建隐私信息字段比如用户的密码一定不能保存到JWT中以防止信息泄露。JWT只是适合在网络中传输一些非敏感的信息
3.Signature
签名哈希部分是对上面两部分数据签名需要使用base64编码后的header和payload数据通过指定的算法生成哈希以确保数据不会被篡改。 首先需要指定一个密钥secret。该密码仅仅为保存在服务器中并且不能向用户公开。然后使用header中指定的签名算法默认情况下为HMAC SHA256根据以下公式生成签名: HMACSHA256(base64UrlEncode(header).base64UrlEncode(payload),secret)
在计算出签名哈希后JWT头有效载荷和签名哈希的三个部分组合成一个字符串每个部分用.分隔就构成整个JWT对象
注意JWT每部分的作用在服务端接收到客户端发送过来的JWT token之后
header和payload可以直接利用base64解码出原文从header中获取哈希签名的算法从payload中获取有效数据signature由于使用了不可逆的加密算法无法解码出原文它的作用是校验token有没有被篡改。服务端获取header中的加密算法之后利用该算法加上secretKey对header、payload进行加密比对加密后的数据和客户端发送过来的是否一致。注意secretKey只能保存在服务端而且对于不同的加密算法其含义有所不同一般对于MD5类型的摘要加密算法secretKey实际上代表的是盐值 4 JWT的种类
其实JWT(JSON Web Token)指的是一种规范这种规范允许我们使用JWT在两个组织之间传递安全可靠的信息JWT的具体实现可以分为以下几种
nonsecure JWT未经过签名不安全的JWTJWS经过签名的JWTJWEpayload部分经过加密的JWT
1. nonsecure JWT
未经过签名不安全的JWT。其header部分没有指定签名算法并且也没有Signature部分。
header {alg: none,typ: JWT
}2. JWS
JWS 也就是JWT Signature其结构就是在之前nonsecure JWT的基础上在头部声明签名算法并在最后添加上签名。创建签名是保证jwt不能被他人随意篡改。我们通常使用的JWT一般都是JWS
为了完成签名除了用到header信息和payload信息外还需要算法的密钥也就是secretKey。加密的算法一般有2类
对称加密secretKey指加密密钥可以生成签名与验签非对称加密secretKey指私钥只用来生成签名不能用来验签(验签用的是公钥)
JWT的密钥或者密钥对一般统一称为JSON Web Key也就是JWK
到目前为止jwt的签名算法有三种
HMAC【哈希消息验证码(对称)】HS256/HS384/HS512RSASSA【RSA签名算法(非对称)】RS256/RS384/RS512ECDSA【椭圆曲线数据签名算法(非对称)】ES256/ES384/ES512
5 PyJWT模块
pip install PyJWT:
import jwt
from jwt import algorithms
import base64
认证
HTTP是无状态协议为了解决产生了cookie和session技术。jwt生产的token分为三部分
1、header由数据类型、加密算法构成
2、payload: 负载就是要传输的数据一般来说放入python对象即可会被json序列化
3、signature 签名部分。是签名2部分数据分别base64编码后使用点号连接加密算法使用key计算好一个结果再被base64编码得到的签名
key secret
token jwt.encode({some: payload}, key, algorithmHS256)
print(token, type(token))header, payload, signature token.split(.)
print(header, base64.urlsafe_b64decode(header))
print(payload, base64.urlsafe_b64decode(payload))# 签名部分
rem len(signature) % 4
if rem 0:signature * (4 - rem)
print(signature, base64.urlsafe_b64decode(signature))alg algorithms.get_default_algorithms()[HS256]
newkey alg.prepare_key(key)
signing_input, _, _ token.rpartition(.)
print(signing_input)6 登陆安全–bcrypt模块
使用邮箱 密码方式登录。
邮箱要求唯一就行了但是密码如何存储
早期都是明文的密码存储。
后来使用MD5存储但是目前也不安全网上有很多MD5的网站使用反查方式找到密码。
加盐使用hash(passwordsalt)的结果存入数据库中就算拿到数据库的密码反查也没有用了。如果是固定加盐还是容易被找到规律或者从源码中泄露。随机加盐每一次盐都变就增加了破解的难度。
暴力破解什么密码都不能保证不被暴力破解例如穷举。所以要是慢hash算法例如bcrypt就会让每一次计算都很慢都是秒级的这样穷举的时间就会很长为了一个密码破解的时间在当前CPU或者GPU的计算能力下可能需要几十年以上。
python安装bcrypt模块pip install bcrypt
import bcryptpwd hello123.encode()# 获取盐值每次获取的都不一样
print(1, bcrypt.gensalt())
print(2, bcrypt.gensalt())# 计算生成的密文也不一样
x1 bcrypt.hashpw(pwd, bcrypt.gensalt())
print(3, x1)
x2 bcrypt.hashpw(pwd, bcrypt.gensalt())
print(4, x2)
print(bcrypt.checkpw(pwd, x1), len(x1))print(~~~~~~~~~~~~~~~~)
salt b$2b$12$jGGPpdxKeOd/A1vxwSob7.
print(salt)
print(bcrypt.hashpw(pwd, salt))
# 计算值b$2b$12$jGGPpdxKeOd/A1vxwSob7.lnWJuSP9ZRYAkATmXP.eMeZnIjMLg/e
# 可以看出$是分隔符。 $2b$ -- 加密算法其中12 表示2^12 key expansion rounds
