Please enable JavaScript.

Coggle requires JavaScript to display documents.

凤凰架构安全性 - Coggle Diagram

- - - - 保密
        
        传输
        
        验证
        
        使用BeanValidation
        
        HTTPS
        
        SSL/TSL
        
        三轮握手确定三个随机数，和加密方法，最后一个用公钥加密，根据三个随机数确定一个密钥，然后使用密钥进行对称加密通信
        
        摘要与加密
        
        摘要不能恢复，非对称是数字签名，对称加密可以恢复
        
        客户端加密
        
        中间人攻击
        
        client_hash = BCrypt(MD5(password) + salt) // MFfTW3uNI4eqhwDkG7HP9p2mzEUu/r2
        使用 BCrypt 对盐值和Md5加密后的密码加密保证彩虹表无法攻击因为是慢函数
        
        服务端加密
        
        每一个密码（指客户端传来的哈希值）产生一个随机的盐值
        
        将动态盐值混入客户端传来的哈希值再做一次哈希，产生出最终的密文，并和上一步随机生成的盐值一起写入到同一条数据库记录中
        
        Spring Security 5 中的BcryptPasswordEncoder， Cost 参数值为-1，经转换后实际只进行了 210=1024 次计算，并不会对服务端造成太大的压力
        
        BCryptPasswordEncoder本身就会自动调用 CSPRNG 产生盐值，并将该盐值输出在结果的前 32 位之中，因此也无须专门在数据库中设计存储盐值字段
        
        验证
        
        对客户端传过来的密码，使用数据库存储的盐值加密，与数据库存储的密码比对
      - cookie-seesion
      - JWT
        
        失效问题
        
        重放攻击
        
        携带数据有限
        
        令牌存在哪
        
        在线人数统计问题
    - - 用户->角色->许可->资源
      - spring security 用户->角色/权限->许可->资源
    - - 面向于解决第三方应用（Third-Party Application）的认证授权协议
      - 授权码模式
        
        客户端模式
        
        密码模式
        
        隐式授权模式
  - - - 访问受保护资源时第一次访问返回401状态码，并返回的header中携带认真的方式如下：
        WWW-Authenticate: <认证方案> realm=<保护区域的描述信息> Proxy-Authenticate: <认证方案> realm=<保护区域的描述信息>
        
        第二次访问需要按方式携带认证信息，认证不通过返回403 通过200
      - 常用的有basic和bearer
    - - 表单认证
      - WebAuthn
        
        注册账号，服务端生成随机字符串challenge 和UserId 返回给客户端。
        
        客户端的WebAuthn API 接收到上面两个参数，并发送给验证器，即设备上的指纹等认证设备
        
        认真设备为当前域名和userId生成密钥对,私钥加密challenge ，将加密后的串和userId和公钥返回给客户端
        
        客户端将信息返回给服务端，服务端验证userId 并使用公钥解密字符串若与challenge相等则保存公钥，注册成功
        
        登录即是输入用户名服务端再发送一个challenge 和userId ,验证器验证域名和用userId 一致则challenege加密返回,服务端使用公钥解密，成功则登录