小编Pet*_*epo的帖子

你能发现我的身份验证协议中的漏洞吗?

前段时间我们需要一个多个Web服务之间的单点登录身份验证解决方案.至少在那个时候我们认为OpenID协议过于复杂,我们不相信它的Ruby on Rails插件.因此,我们设计了自己的协议,而不是实现OpenID提供者和OpenID使用者.

我有两个问题:

  1. 不创建我们自己的OpenID提供商并设置我们的OpenID消费者只接受它是不是一件坏事吗?不允许公开登录或注册,我们希望简化身份验证.

  2. 您能否在以下设计中发现关键错误或漏洞?

如果你作为一个公社可以批准这个设计,我会考虑将这个代码提取到Ruby on Rails插件中.

请查看流程图和顺序图.

细节:

身份验证提供程序("AP"):

  • 中央服务,包含有关用户的所有数据.
  • 此设置中只存在一个"AP".
  • 有可能有多个"AP",但在这种情况下这不应该是相关的.
  • "AP"事先知道每个"S".

身份验证客户端(服务"S"):

  • 存在多个内部和外部Web服务.
  • 每个服务事先都知道"AP"及其公钥.

演员("A"):

  • 通过用户名和密码使用AP对自己进行身份验证的最终用户
  • 可以在登录前直接请求任何"S"或"AP"URI

"A","S"和"AP"之间的连接由HTTPS保护.

简要描述了认证逻辑:

这些是对本文顶部链接的图形流程图和序列图的描述.

1)Auth Provider"AP"

  • "AP"向"S"发出服务器到服务器HTTP POST请求以获取现时.
  • "AP"生成身份验证令牌.
  • 身份验证令牌是一个XML实体,包括:
    • 到期日(从现在起2分钟),
    • 先前请求的随机数(以防止重播),
    • 识别"S"的名称(Service_1的令牌不适合Service_2),
    • 有关最终用户的信息.
  • 身份验证令牌使用AES256加密,加密密钥和初始化向量由AP的私有RSA密钥签名.
  • 产生的字符串("data","key"和"iv")首先进行Base64编码,然后进行URL编码,以允许它们在URL查询字符串中传递.
  • 最终用户"A"被HTTP重定向到服务"S"(HTTPS GET请求).

2)服务"S"

  • 从用户代理接收URL参数中的身份验证令牌.
  • 使用AP的预共享公钥解密身份验证令牌.
  • 仅接受一次身份验证令牌(令牌包含仅一次有效的nonce).
  • 检查身份验证令牌中的标识名称是否与服务名称相对应.
  • 检查身份验证令牌是否已过期.

备注:

如果其他人也可以解密身份验证令牌,这不是问题,因为它不包含有关用户的机密信息.但是,除AP之外的其他任何人都无法生成有效的身份验证令牌.因此涉及RSA密钥对.

RSA私钥仅用于对令牌进行签名,因为它无法加密长度超过实际密钥长度的数据.因此,AES用于加密.

由于身份验证令牌是作为HTTP GET请求传递的,因此它将存储在例如Apache的日志文件中.使用一次性随机数和失效日期应尽量减少重放攻击的可能性.POST请求需要一个HTML页面,其中包含由Javascript自动提交的表单,这就是使用GET的原因.

服务"S"仅在服务器到服务器API请求中生成随机数.因此,未经身份验证的生成请求不应构成DoS漏洞.

security authentication encryption cryptography

4
推荐指数
1
解决办法
1092
查看次数