1. 首页
  2. 问答
  3. 此实施SSO的潜在安全问题是什么？

此实施SSO的潜在安全问题是什么？

2010-02-05 67 views
2

我目前正在研究跨域SSO实现，并且我可能无法使用第三方SSO提供程序。此实施SSO的潜在安全问题是什么？

我在线发现了一个包含系列重定向和加密查询字符串参数的自定义实现。

  1. MrUser登录到http://www.foo.com

  2. MrUser点击一个链接到http://www.bar.com/page.aspx

  3. MrUser上bar.com没有通过认证，但bar.com有重定向到http://www.foo.com/sso.aspx

    4. 验证码

  4. sso.aspx页面检查cookie集合中的有效ASP.NET身份验证Cookie。如果存在，sso.aspx将重定向到http://www.bar.com/page.aspx&ssoauth=[encryptedkey]（其中[encryptedkey]是foo.com和bar.com已同意的MrUser的加密标识）。如果没有有效的ASP.NET身份验证cookie，那么它只是重定向而没有ssoauth参数。

  5. Bar.com执行检查以避免无限重定向循环，然后解密ssoauth值。如果没有ssoauth参数，那么MrUser会被重定向到登录页面，否则Bar.com将使用解密后的id在将其发送到page.aspx之前对MrUser进行身份验证。

这种方法的潜在安全问题（或其他类型的问题）是什么？

（引用：http://blogs.neudesic.com/blogs/michael_morozov/archive/2006/03/17/72.aspx）

编辑：为响应答案援引加密ID是一样的，每次和一个攻击者可以使用它来访问 - 如果有什么bar.com检查引用，以便它只接受来自foo.com的ssoauth参数？

来源

2010-02-05 Chris Dwyer

+0

我建议你看看基于声明的安全性和代号“Velocity” – 2010-02-05 01:12:14

+1

引用者非常容易被欺骗。确保SSO加密密钥是真实的唯一方法是让生成服务器加密执行请求的系统的占用空间。足迹是非常困难的，因为足迹中没有太多的东西不能被复制/欺骗。 – 2010-02-05 01:21:52

回答

2

第一个问题是，任何加密/解密方案都可以清楚地看到。您应该更好地实施一些更加符合PKI加密/解密平台的行，这些平台的加密密钥是公开的，但解密密钥是私有的。加密需要适当复杂以增加“破解时间”，并且需要资源来执行密钥的加密/解密。

事实上，你有一个非共同的域将创建需要提供加密的片头（post或get），并传递它明文。虽然查询字符串信息在请求的生命周期内保持安全（编辑：假设为SSL），但浏览器历史记录并不安全（使其可供常用计算机访问）。

最严重的安全问题是“破解一个/破解所有”的概念。如果其中一台服务器受到攻击并且其加密/解密算法，盐等暴露出来，那么攻击者可以通过随意和按需生成有效的加密SSO密钥来危害所有系统。

这些问题都不是非常悲惨的。我不会在银行或医疗机构执行此计划，但对于像SO或Twitter这样的低风险网站，这是完全可以接受的。这将全部归结为管理资源，风险和收益。

来源

2010-02-05 01:08:14

+0

你能评论我上面的修改吗？ – 2010-02-05 01:19:06

2

任何人都可以使用encryptedKey作为MrUser获得访问权限。需要一个签名或消息认证服务，而不是加密。经过身份验证的消息应包含具有用户标识符的随机数以防止重播。

像这样的协议很难设计。即使是多年来广泛使用和审查的TLS也存在安全漏洞。不要尝试使用未经验证的身份验证机制。

来源

2010-02-05 01:09:20 erickson

+0

你能评论我上面的修改吗？ – 2010-02-05 01:18:38

+1

引用标题可以很容易伪造。这根本不是安全措施。 – erickson 2010-02-05 17:02:18

1

潜在的问题是，如果ssoauth加密密钥只是用户的加密ID。这样的设置将导致每次提供相同的密钥，因此可以由原始用户重用，或者由第三方更坏。

避免这种情况的一种方法是保持foo.com和bar.com服务器的时钟相对同步，并发出包含日期/时间（模5分钟）的密钥。

人们经常试图使用Web客户端的IP地址作为此加密的一个要素，但这是一个坏主意，因为一些代理和网关在其池中使用不同的公共IP来访问不同的域/服务器。

的另一种方式每次以允许不同的密码是有bar.com的重定向到

http://www.foo.com/sso.aspx

包括参数如

http://www.foo.com/sso.aspx?ParamForKey=some_random_number

和使用ParamForKey作为加密部分过程

来源

2010-02-05 01:10:20 mjv

+1

如果'some_random_number'实际上是随机的，那么你仍然容易受到重播攻击。 – 2010-02-05 01:24:17

+0

@Anon。你是对的！这种参数应该是部分随机的，但也包括一些基于时间的排序验证（这会带来同步时钟的需求......） – mjv 2010-02-05 01:33:10

0

有几个问题： 1）加密的令牌有效多久？它应该只对几个秒有效。如果所有服务器都在ntp上，很容易。过期还可以保护用户，以防他们拥有包含加密令牌的链接。验证随机数是很困难的，如果你有很多bar.com服务器 - 你可以说过了几秒钟应该减少重播。

2）SSO跨域的问题是单点标志关闭。如果用户签署foo.com会怎么样？ bar.com上的会话必须失效。你可以将XSRF bar.com注销为黑客:)。您应该每隔15分钟有bar.com beacon foo.com，以查看用户是否仍然登录。

3）如果用户没有签名bar.com并且它是多用户计算机和另一个用户标志到foo.com上？如果用户标识不匹配先前用户的数据，则必须确保不显示。

4）正如别人提到的，你可能需要在userid上签名或者使用HMAC而不是加密。如果你加密，请记住保护密文的完整性。您不希望用户A在密文中翻转位以查看他们是否可以访问bar.com上的用户B的数据。

我会通过https重定向。

最后，正如大家所说，推荐人可以被欺骗。不要相信他们。

来源

2010-02-12 21:22:04 mar

相关问题

 相关问题