谷涧月的学习流水账

记录设计验权系统时的一些随想

OAuth2.0协议内容

OAuth 2.0 是一个行业标准的协议，用于授权。它允许第三方应用获取有限的访问权限，而无需将用户名和密码提供给第三方应用。OAuth 2.0 专注于客户端开发者的简易性，同时为Web应用、桌面应用、手机和起居室设备提供专门的认证流程。以下是 OAuth 2.0 协议的核心内容和组成部分：

  1. 角色：
    • 资源所有者（Resource Owner）：能够授权访问其资源的用户。
    • 资源服务器（Resource Server）：存储受保护资源的服务器，只有经过授权的客户端才能访问。
    • 客户端（Client）：请求访问受保护资源的应用程序。
    • 授权服务器（Authorization Server）：负责颁发访问令牌给客户端。
  2. 流程：
    • 授权码模式（Authorization Code Grant）：客户端引导资源所有者至授权服务器，用户登录并授权后，授权服务器返回一个授权码给客户端，客户端使用该码换取访问令牌。
    • 密码模式（Resource Owner Password Credentials Grant）：客户端直接使用资源所有者的用户名和密码向授权服务器申请访问令牌。
    • 客户端模式（Client Credentials Grant）：客户端直接向授权服务器申请访问令牌，适用于客户端代表自己访问资源的场景。
    • 隐式模式（Implicit Grant）：适用于纯前端应用，客户端引导资源所有者至授权服务器，用户授权后，授权服务器直接返回访问令牌给客户端。
    • 设备模式（Device Authorization Grant）：适用于无法通过常规流程进行用户交互的设备，例如物联网设备。
  3. 令牌：
    • 访问令牌（Access Token）：允许客户端访问受保护资源的令牌。
    • 刷新令牌（Refresh Token）：用于获取新的访问令牌，通常在访问令牌过期后使用。
  4. 安全性：
    • OAuth 2.0 要求使用HTTPS来保护所有OAuth流程中的通信，以防止令牌被截获。
    • 访问令牌和刷新令牌应该是随机的、不可预测的，并且具有足够的长度。
    • 客户端必须验证授权服务器的重定向URI。
  5. 扩展性：
    • OAuth 2.0 支持多种扩展，例如开放ID连接（OpenID Connect），它允许在OAuth 2.0授权过程中传递用户身份信息。
    OAuth 2.0 协议是复杂的，并且需要根据具体的应用场景和安全要求来正确实施。它旨在提供一个安全、灵活且可扩展的授权框架，以满足不同应用的需求。

JWT和Session-Cookie的使用场景差异

JWT（JSON Web Tokens）和Session-Cookie是两种不同的技术，它们在Web应用中用于身份验证和信息传递，但它们之间存在一些关键的区别：

  1. 存储位置：
    • Session-Cookie：Session存在服务器中，对应Cookie存储在客户端浏览器中，由浏览器自动处理。
    • JWT：可以存储在客户端（通常作为URL的一部分、存储在Cookie中或者LocalStorage/SessionStorage中），也可以存储在服务端。
  2. 安全性：
    • Session-Cookie：可以设置为仅通过HTTPS传输（Secure标志），并且可以设置HttpOnly标志，使得JavaScript无法访问，减少XSS攻击的风险。
    • JWT：本身是自包含的，包含所有必要的信息，因此不需要在服务器上存储会话信息。但是，JWT需要通过HTTPS传输以防止中间人攻击，且应使用强算法（如RS256）签名以防止篡改。
  3. 大小：
    • Cookie：大小受限（通常每个域名限制为20-30个Cookie，每个Cookie大小限制在4KB左右）。
    • JWT：理论上可以更大，但因为需要在HTTP请求头中传输，所以也不宜过大，以免影响性能。
  4. 性能：
    • Session-Cookie：服务端每次响应请求前，需要在服务器上查找会话信息以确定Cookie是否有效，会增加整体请求响应耗时。
    • JWT：需要在每次请求的HTTP头中明确指定，可能会增加请求头的大小，但不需要在服务器上查找会话信息。
  5. 会话管理：
    • Session-Cookie：依赖于服务器端的会话存储，可以很容易地实现会话的注销和失效。
    • JWT：由于是自包含的，不需要服务器存储会话信息，但一旦发出，除非过期，否则不能轻易撤销。
  6. 跨域访问：
    • Session-Cookie：受到同源策略的限制，不能跨域访问。
    • JWT：由于是作为请求的一部分发送，可以跨域使用。
  7. 用途：
    • Session-Cookie：主要用于跟踪会话状态，也可以用于存储用户偏好等信息。
    • JWT：主要用于身份验证和信息交换，尤其是在分布式系统中。

总的来说，Session-Cookie更适合用于会话管理，如果账号被盗用或者登录信息修改了可以立即取消上一次登录生成的会话信息，也因为session只保存在服务器中，也能保证敏感信息不会被窃取，而JWT更适合用于分布式系统中的身份验证和信息交换，不需要另外存储会话信息，对性能的影响小。

JWT(Json Web Tokens)包含哪些信息

JWT（JSON Web Tokens）是一种紧凑且自包含的方式，用于在各方之间以JSON对象的形式安全地传输信息。JWT通常包含三个部分，用点.分隔，分别是Header（头部）、Payload（负载）和Signature（签名）。下面是每个部分通常包含的信息：

  1. Header（头部）：
    • typ：类型，通常为JWT。
    • alg：指定签名算法，如HS256（HMAC SHA-256）或RS256（RSA签名）。
  2. Payload（负载）：
    • iss：发行人（Issuer），指的是token签发的主体。
    • exp：过期时间（Expiration Time），token的有效期。
    • iat：发行时间（Issued At），token签发的时间。
    • nbf：生效时间（Not Before），token在此时间前不可用。
    • sub：主题（Subject），通常指用户的唯一标识。
    • aud：受众（Audience），token的预期接收者。
    • jti：JWT ID，提供token的唯一标识，防止重复使用。
    • 自定义声明：除了以上标准声明外，还可以包含其他业务相关的自定义声明。
  3. Signature（签名）：
    • 签名部分是由Header指定的算法、一个秘密（对于HS算法）或公钥/私钥对（对于RS或ES算法）以及Header和Payload的编码后的字符串组成的。签名用于验证消息在传输过程中未被篡改，并且，对于使用私钥签名的token，还可以验证发送者的身份。
    JWT的结构如下所示：
    1
    <Header>.<Payload>.<Signature>

• Header和Payload通常使用Base64Url编码。
• Signature是使用Header中指定的算法和密钥对Header和Payload的编码字符串进行签名的结果。
JWT的设计目的是在各方之间安全地传输信息，同时确保信息的完整性和可验证性。由于JWT可以包含敏感信息，因此在使用JWT时，必须通过HTTPS等安全协议传输，以防止中间人攻击。

使用哈希加密算法加密保存敏感信息的一些注意事项

使用哈希加密算法加密保存敏感信息时，需要注意以下几个重要的事项：

  1. 选择合适的哈希算法：
    • 应使用当前认为安全的哈希算法，如SHA-256或SHA-512，避免使用已不安全的算法，如MD5和SHA-1。
  2. 盐值的使用：
    • 为了防止彩虹表攻击，每个密码在哈希前应该加上一个唯一的盐值。盐值可以增加密码破解的难度。
  3. 哈希输出长度：
    • 哈希输出应足够长（建议256位以上），以防止暴力破解和生日攻击。
  4. 安全存储哈希和盐值：
    • 存储哈希值时，应将盐值与哈希值一起存储，但盐值本身不需要保密。
  5. 避免时序和功耗分析攻击：
    • 使用恒定时间和随机化哈希算法，以防止通过分析算法执行来破解哈希值。
  6. 密码轮换和多因素身份验证：
    • 在遭受攻击后，仅存储哈希值是不够的。应采用密码轮换和多因素身份验证。
  7. 数据传输安全：
    • 敏感数据的传输应通过安全的通信通道（如HTTPS/TLS）进行，以防止中间人攻击。
  8. 使用最新的安全标准：
    • 加密与哈希算法不断发展，应定期更新应用程序，使用最新的安全标准和库。
  9. 密码存储格式：
    • 一些哈希算法（如bcrypt）的哈希值包含了算法标识、成本因子和盐值，这些信息都嵌入在哈希值中，无需单独存储。
  10. 密码长度限制：
    • 某些哈希算法（如bcrypt）对密码长度有限制，若密码超出此限制，需要进行额外处理。
  11. 不可逆性：
    • 哈希算法的设计理念和加密原理确保了它在密码保护中的不可替代性。通过盐、成本因子以及不可逆的特性，可以有效抵御暴力破解和彩虹表攻击。
  12. 安全开发实践：
    • 采用安全的开发实践对于保障敏感信息的安全至关重要，包括进行代码审查、定期的安全培训、漏洞扫描等。
    遵循这些注意事项可以帮助提高敏感信息的安全性，保护用户数据免受恶意攻击。

MD5保存密码为什么不够安全了，SHA-256相比MD5有什么优势

MD5不如SHA-256安全的原因主要包括以下几点：

  1. 哈希长度：
    • MD5产生128位的哈希值，而SHA-256产生256位的哈希值。更长的哈希值意味着更大的哈希空间，从而使得碰撞的概率更小，提高了安全性。
  2. 抗碰撞性：
    • MD5已被证明存在漏洞，容易受到碰撞攻击，即可以找到两个不同的输入值，它们产生相同的MD5哈希值。相比之下，SHA-256对碰撞攻击的抵抗力更强，目前还没有发现有效的攻击方法。
  3. 安全性：
    • MD5的安全性较弱，存在已知的漏洞，而SHA-256目前被认为更安全，没有发现严重的漏洞。
  4. 计算性能：
    • 尽管MD5在计算速度上比SHA-256快，但安全性是更重要的考量因素。SHA-256虽然计算速度较慢，但由于其更长的哈希长度，提供了更高的安全性。
  5. 应用场景：
    • SHA-256由于其高安全性，被广泛应用于数字签名、区块链、文件校验等需要高安全性保障的场景。而MD5则更多用于一些对安全性要求不高的场景。
  6. 雪崩效应：
    • SHA-256具有高的雪崩效应，即输入的微小变化会导致输出的哈希值发生巨大变化，这增强了其安全性。
  7. 密码学弱点：
    • MD5的密码学弱点已经被广泛研究和利用，包括长度扩展攻击和碰撞攻击，而SHA-256在这方面的表现更为稳健。
    综上所述，SHA-256在安全性、抗碰撞性、输出长度等方面都优于MD5，因此在需要高安全性的应用中，SHA-256是更安全的选择。
工作笔记 JWTOAuth2.0哈希算法