security - 此 SSO 实现安全吗？

Question

客户要求我们为其供应商设计一个简单的单点登录解决方案。在这种情况下，客户拥有许多能够实现简单解决方案的供应商，该解决方案允许供应商的用户登录到我们客户的站点。我想出了这个:

共享数据

以下数据将在我们和给定供应商之间共享。

• user_id - 由供应商提供
• vendor_id - 由我们提供
• vendor_secret - 由我们提供。 “随机”SHA512 哈希

共享哈希函数

我们的规范将定义以下实践来生成适合通过 URL 参数传输的 key :

// Pseudo-code. Assume sha512() is a function in their native language that accepts a string and returns a SHA-512 hash
vendor_id = 341;
vendor_secret = "areallylonghash...";
user_id = "12345abcdef;&";
hash = sha512(vendor_id + ":" + vendor_secret + ":" + user_id);

SSO 流程

1. 用户在供应商网站上点击“登录”，并向供应商的 SSO 入口点发出 GET 请求。
2. 供应商在入口点收到请求(例如 www.avendor.com/sign_in)。
3. 供应商使用上述哈希函数为用户生成哈希。
4. 供应商使用参数 vendor_id、user_id 和 hash 重定向到我们的客户端端点。
5. 我们在端点收到请求。我们从传递的vendor_id中查找vendor_secret，并尝试重新创建发送给我们的哈希。
6. 如果生成的哈希匹配，则在客户端站点上创建 session 。

潜在问题

如果我们在重定向步骤 4 中使用 GET 请求，生成的哈希是否可能最终出现在用户的浏览器历史记录中？如果有人只需点击历史记录中的链接就不太安全。我们可以在重定向时使用 HTTP header 来传输哈希值吗？

如果您已经看到这里，谢谢您。欢迎所有反馈!我们希望确保我们正在部署安全的解决方案。

Answer 1

答案:不，它不安全。

在步骤 4 中，用户代理获得对 vendor_id、user_id 和 hash 的访问权限。现在，客户端可以将他们想要的任何字符串附加到 user_id 并修改 hash 以匹配。我不确定我是否完全理解您的建议，但这似乎可能使一个用户能够以用户名是自己前缀的另一用户身份登录。

您需要使用 HMAC而不是普通的哈希值。

Stay away from implementing your own crypto!