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

Question

前段时间我们需要一个多个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漏洞.

Answer 1

您会混淆身份验证("我就是我说的是我")和授权/访问控制("我可以访问它").您只需实施OAuth,然后通过HTTPS查询服务器"是否允许此OAuth身份访问我？".您不必担心重放攻击,因为您使用的是HTTPS.

"安全很难,所以我会自己设计."

身份验证令牌使用AES256加密,加密密钥和初始化向量由AP的私有RSA密钥签名.

AES-256和AES-192具有弱密钥时间表.但你不是用它来保密; 你正在使用它作为某种"完整性"检查.它不起作用:攻击者获得"签名"身份验证令牌.攻击者恢复了密钥和IV.攻击者使用相同的密钥和IV加密不同的身份验证令牌,并使用相同的"签名".

散列它并签署哈希有什么问题？另请注意,如果您要使用自定义签名,则需要注意填充(IIRC PKCS-无论添加至少11个字节).

编辑:如果您使用的密码应该使用散列/ MAC,那么您真的不应该设计安全协议!