security - 您可以在我的身份验证协议(protocol)中发现漏洞吗？

Question

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

我有两个问题：


不创造是一件坏事吗
我们自己的OpenID提供程序和设置
我们的OpenID消费者只接受吗？
不公开登录或注册
允许，我们想保留
验证简单。
您可以在以下设计中发现严重错误或漏洞吗？


如果您是一个公社可以批准这种设计，那么我将考虑将该代码提取到Ruby on Rails插件中。

请查看flowchart and sequence diagram。

细节：

身份验证提供程序（“ AP”）：


拥有所有数据的中央服务
关于用户。
此设置中仅存在一个“ AP”。
可能有多个“ AP”，但是在这种情况下应该不相关。
“ AP”预先知道每个“ S”。


身份验证客户端（服务“ S”）：


存在几种内部和外部Web服务。
每个服务都事先知道“ AP”及其公钥。


演员（“ A”）：


进行身份验证的最终用户
通过用户名和密码与AP保持联系
可以在登录之前直接请求“ S”或“ AP”的任何URI


“ A”，“ S”和“ AP”之间的连接由HTTPS保护。

认证逻辑简要描述：

这些是对图形流程图和序列图的描述，它们链接在本文的顶部。

1）身份验证提供程序“ AP”


“ AP”向“ S”发出服务器到服务器的HTTP POST请求，以获取随机数。
“ AP”生成身份验证令牌。
身份验证令牌是一个XML实体，其中包括：


到期日期（从现在开始2分钟），
先前要求的随机数（以防止重播），
标识名称“ S”（Service_1的令牌对Service_2不利），
有关最终用户的信息。

身份验证令牌使用AES256加密，加密密钥和初始化向量由AP的专用RSA密钥签名。
首先对结果字符串（“数据”，“键”和“ iv”）进行Base64编码，然后对URL进行编码，以允许它们在URL查询字符串中传递。
最终用户“ A”通过HTTP重定向到服务“ S”（HTTPS GET请求）。


2）服务“ S”


从用户代理接收URL参数中的身份验证令牌。
使用AP的预共享公用密钥解密身份验证令牌。
仅接受一个身份验证令牌一次（令牌包含仅有效一次的随机数）。
检查身份验证令牌中的标识名称是否与服务名称相对应。
检查身份验证令牌是否未过期。


备注：

如果其他人也可以解密身份验证令牌，这不是问题，因为它不包含有关用户的机密信息。但是，至关重要的是，除了AP之外，没有其他人能够生成有效的身份验证令牌。因此，涉及RSA密钥对。

RSA专用密钥仅用于对令牌进行签名，因为它不能加密比实际密钥长度更长的数据。因此，AES用于加密。

由于身份验证令牌是作为HTTP GET请求传递的，因此它将被存储，例如在Apache的日志文件中。使用一次性随机数和到期日期应将重播攻击的可能性降到最低。 POST请求将需要一个HTML页面，该页面具有由Javascript自动提交的表单，这就是使用GET的原因。

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

Answer 1

您会混淆身份验证（“我是我所说的我”）和授权/访问控制（“我被允许访问此文件”）。您可以只实现OAuth，然后使用“是否允许该OAuth身份访问我？”通过HTTPS查询服务器。您无需担心重播攻击，因为您正在使用HTTPS。

“安全性很难，所以我会自己设计。”


身份验证令牌使用AES256加密，加密密钥和初始化向量由AP的专用RSA密钥签名。


AES-256和AES-192的密钥计划很薄。但是，您并不是出于保密目的使用它。您将其用作某种“完整性”检查。它不起作用：攻击者获得“签名”身份验证令牌。攻击者收回了密钥和IV。攻击者使用相同的密钥和IV加密不同的身份验证令牌，并使用相同的“签名”。

对其进行哈希处理并对其进行签名有什么问题？还要注意，如果要使用自定义签名，则需要注意填充（IIRC PKCS，无论添加至少11个字节）。

编辑：并且，如果您使用的密码应该使用哈希/ MAC，则您实际上不应该设计安全协议！