提供盐和加密密码的安全风险是什么？

Question

我继承了一个要维护的应用程序，我刚刚发现当用户登录时，成功登录时返回的JSON包含：

• 数据库中用户记录的主键
• 用户名
• 加密密码
• 密码的盐

似乎使用Salt和Encrypted密码一般会使盐的目的无效。

现在可以再次使用强力或查找表攻击作为破解方法。

我对此是否正确，是否存在更多的威胁？

Answer 1

它不是最好的，但通常可以公开盐。你想到的是pepper，这是保密的。

盐渍哈希不是为了防止蛮力攻击。它旨在阻止rainbow attack。通过将输入值中的salt包含在散列算法中，除非黑客为每个可能的盐创建查找表，否则无法预先计算查找表。

Answer 2

在我看来，即使它不是给出密码的东西，你也会泄露你的前端根本不需要的信息，这可能会导致攻击者获取密码！我的意思是，是的，如果攻击者获得了这些信息，他仍然需要进行详尽的搜索，所有可能的密码组合与该盐连接（或者用该盐哈希密码字典），但是你要为他提供资源一个离线攻击，现在他可以尝试尽可能多的不同密码，直到他感到无聊，或者他得到真正的密码。

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

所有这一切都可以通过发送一个布尔值而不是完整的对象来避免，因为它不需要一个巨大的重构或类似的东西，我认为这是需要的东西要修复（你还应该看看他对这些信息做了什么，在最坏的情况下，他会检索密码的哈希值，将其存储在cookie或本地存储中以保持身份验证用户，或类似的东西）。

Answer 3

如果盐和＆amp; hash只能从POST到登录处理程序，然后这里的损坏非常有限。

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

另一个低风险是，如果JSON响应不是output anti-caching headers，则同一计算机的另一个用户可能能够检索其密码哈希。

我更担心密码哈希值是Hash(Password+Salt)格式，而不是使用安全算法（如bcrypt或pbkdf2）的格式。