我们正在开发一个移动web应用程序,用户希望(这是一个不可放松的要求)被记录很长时间。
我们正在开发的解决方案包括HTML+JS中的web客户端部分和Java中的中间件部分。在中间件中存储用户凭据不是一种选择,因为我们不希望有某个管理员可以获取用户的所有凭据的单一点。因此,简而言之,以下是这些要求:
我们非常清楚,在HTML LocalStorage或Cookies中存储凭据是一种非常糟糕的安全实践,但是:
1)用户知道他们有很长的时间“记住我”,这是他们的责任(安全性和可用性)。
显然,在HTML中以纯文本存储凭据不是一种选择,因为XSS攻击可以窃取凭据,因此我们设计了一种解决方案,并在这里讨论它的安全性。一个小通知:我们想从一个真实的角度来讨论这个问题,而不是一个学术的观点;)
( a)用户将凭证放入web表单b) JS库使用RSA公钥(1024)加密凭据,并将加密的有效载荷( EP )放在LocalStorage c)中。EP被发送到中间件,该中间件用私钥解密它,并将用户身份验证到后端系统(S)(可能有多个带有SSO的后端系统)--如果客户端存在EP,如果用户想注销,则客户端发送它并再次对用户e进行身份验证(如果用户希望注销,则有一个会话id来避免每次调用解密(会话到期时,客户端重新发送EP) d),客户端删除EP并将登录表单交给用户。
安全点是:
( a)在客户端,只有一种加密的不对称算法( ==>没有人能解密)我们认为管理员在中间件中比在磁盘上窃取凭据要困难得多( c)每隔N个月,我们更新RSA密钥,所有用户都必须重新认证
我唯一能想象到的攻击是:
a)在加密==>之前窃取凭据的浏览器插件--这对于所有web用户都是如此--( b)重放攻击:窃取enc有效负载许可来验证模拟真实用户的==> --这是一个问题,但是用户的凭据是安全的,并且平衡了很长的记忆are (非常长的会话的相同问题)。
我无法想象还有其他类型的袭击。
为了提高解决方案的安全性,我非常愿意听取所有意见(但可用性是非常重要的.)
发布于 2013-01-30 09:05:00
听起来你让事情变得更难了。
显然,与服务器端数据元素相对应的随机、服务器发布的密钥是目前为止最好的解决方案,而且在实践中也是任何有信誉的组织使用的唯一解决方案。但既然你想要的是不同的东西,那就来吧:
登录时,使用salt和一些HMAC (可能还有时间戳)对登录信息服务器端进行加密,base64对结果进行编码,这是您向客户端发出的持久令牌。理想情况下,您还应该以某种方式将登录绑定到设备上;可能是某种静态设备ID,它被发送到服务器并编码到服务器中。
然后,当您需要重新身份验证时,您的客户端将此令牌传递给服务器,您的服务器将对该服务器进行解密、身份验证,然后向您的应用程序发出一个正常的会话密钥。
它并不像随机的、不透明的身份验证令牌那样好(只有当它对应于某个服务器端数据存储时才有价值),但是您说过,由于一些未知的原因,这是不可能的。我会说,如果像这样简单有用的东西是不可能的,那么你就使用了错误的软件。
至于使用非对称密码和基于浏览器的RSA来存储身份验证令牌,我甚至不能想出一个合适的方案。但为了复杂性的缘故,复杂性有时也有它自己的魅力。
https://security.stackexchange.com/questions/29927
复制相似问题