2017-01-05 51 views
0

我继承了一个应用程序来维护和我刚刚发现,当来自中,返回的JSON用户登录成功登录包含:给予加密和加密密码的安全风险是什么?

  • 在DB
  • 用户名
  • 用户记录的主键
  • 加密密码
  • 密码的盐

看来,具有盐和加密的密码空隙一般盐的目的。

蛮力或查找表攻击现在又可用作破解方法。

我对此是否正确,是否还有更多的威胁?

+0

这里不清楚“加密密码”是什么意思。你的意思是一个哈希(或可能延长)的密码?或者它实际上是用密钥加密的?你能够将密码解密回明文吗? –

+0

@RobNapier Hello Rob。通过加密密码,我的意思是哈希(密码+盐)=散列结果。 – aero

回答

4

这不是最大的,但通常可以透露盐。你正在考虑一个pepper,这是保密的。

盐渍散列并不意味着防止暴力攻击。这是为了防止rainbow attack。通过在散列算法的输入值中包含salt,除非黑客为每个可能的盐创建查找表,否则无法预先计算查找表。

+1

感谢您的洞察力和翔实的答案约翰。我没有听说过“辣椒”,并认为你第一次读它可能会开个玩笑。 – aero

2

在我看来,即使它不是像放弃一个密码,你放弃的信息,你的前端并不需要在所有并可能导致攻击者获得密码!我的意思是,如果攻击者获得了这些信息,他仍然需要详尽的搜索,将所有可能的密码组合与该盐串联(或者用该盐的密码字典散列),但是您要为他提供离线资源攻击,现在他可以尝试尽可能多的密码,直到他感到无聊,或者他得到真正的密码。

有人可能会认为它与尝试使用不同密码进行身份验证的攻击者是一样的,但主要区别在于,在线攻击中,您可以限制登录尝试的次数,因此他无法使用尽可能多地尝试,而在离线攻击中,他可以尝试尽可能多的密码。

所有这一切都可以通过发送一个布尔值来避免,而不是完整的对象,因为它不需要大量的重构或类似的东西,我认为这是需要解决的问题(并且你应该还要看看他如何处理这些信息,在最糟糕的情况下,他正在检索密码的哈希以将其存储在cookie或本地存储中以保持对用户的身份验证等)。

+0

@aero - 确实很难找到发送密码哈希值的情况,这不应该没有很好的理由。 – martinstoeckli

+0

谢谢埃斯特万。攻击者有机会脱机破解密码是一个附加的安全漏洞。 – aero

1

如果盐&哈希只能从POST到登录处理,那么这里的伤害是非常有限的。

如果有一些webmethod(/currentUser/getDetails)返回数据,那么这是一个风险,如果它们是网站上其他任何跨站点脚本(XSS)漏洞。任何攻击者都可以通过XSS调用此方法,然后检索散列密码和盐以进行脱机破解。

另一种低风险是,如果JSON响应不output anti-caching headers然后在同一台计算机的其他用户可能能够找回自己的密码哈希值。

我更关心的是密码哈希格式为Hash(Password+Salt)格式,而不是使用安全算法(如bcrypt或pbkdf2)的格式。

+0

感谢SilverlightFox,这是对“输出反缓存头”的一个很好的考虑,以及XSS漏洞如何使当前JSON返回更严重的安全威胁。 – aero