盐，盐。 这是最低限度的价格。

前几天，我读了这篇Arstechnica文章 ，意识到这种情况多么悲惨。 而且这并不是因为邪恶的黑客而造成的。 这很糟糕，因为很少有人知道如何处理一件非常普通的事情：身份验证（注册和登录）。 但是似乎像LinkedIn和Yahoo这样的很酷的公司都做错了（最近大量密码泄露了）

本文中描述的大多数问题都是使用bcrypt解决的。 并且必须使用盐。 其他选项也是可以接受的-PBKDF2，也许还有SHA-512。 请注意，bcrypt不是哈希函数，它是专门为密码存储设计的算法。 它具有内置的盐生成器。 这是有关该主题的两个堆栈交换问题： this和this 。 杰夫·阿特伍德（Jeff Atwood）不久前也写过关于这个话题的文章 。

什么是盐？ 它是一个随机字符串（准确地说是一系列位，但出于密码存储的目的，让我们将其视为字符串），该字符串在散列之前附加到每个密码上。 因此，“ mypassword”可能会变成“ 543abc7d9fab773fb2a0mypassword”。 然后，您每次需要检查密码是否正确时都添加盐（即salt + password应该生成与存储在数据库中相同的哈希）。 这有什么帮助？ 首先，不能使用彩虹表（用于字符组合的预先计算的哈希表）。 Rainbow表是为较短的密码生成的，并且较大的盐会使密码很大。 由于攻击者知道您的食盐，因此仍然可以使用蛮力攻击，因此他可以只蛮力攻击salt +（尝试的密码集）。 但是，Bcrypt解决了蛮力问题，因为它是故意的“慢速”。

因此，使用盐 。 更喜欢bcrypt。 而且，如果您必须超级安全，那么这不是必须的-这是每个存储密码的网站的绝对最低要求。 而且不要说“我的站点只是一个论坛，如果有人获得密码会发生什么”。 用户倾向于重用密码，因此他们用于您的愚蠢站点的密码也可能是他们的Facebook密码电子邮件。 因此，无论您的网站是什么，都请认真对待，因为您冒着用户在房屋外安全的风险。 如果您认为使用bcrypt很难，那么根本不要使用密码。 使用“使用facebook / twitter登录”，OpenID（实际上比使用bcrypt困难）或其他形式的外部身份验证。

在几次使用“最小”一词之后，我将简要列出一些有关网络安全的事项，除了最低限度地使用盐之外，还应考虑这些事项。 如果您正在处理金钱或其他一些非常重要的员工，那么您将无法承受最低限度的费用：

• 在各处使用https。 可以嗅探发送不安全的会话cookie，攻击者可以“窃取”用户的会话。
• 一次性令牌–通过SMS发送短暂令牌（代码），或通过电子邮件发送登录链接–用于身份验证。 这样，您甚至都不需要密码（将身份验证复杂性转移到移动网络/电子邮件提供商）
• 鼓励使用密码而不是密码-短密码更容易被暴力破解，但长密码却很难记住。 因此，您可以鼓励用户使用容易记住但难以攻击的密码短语，例如“风中的灰尘”或“谁让狗出去了”。 （我的注册页面有一个微妙鼓励的示例）
• 要求对高度敏感的操作进行额外的验证，并且如果登录是自动的，则不允许更改电子邮件（使用具有悠久历史的“记住我” cookie）
• 连续登录失败后锁定帐户-仅当攻击者控制了您的数据库时，“ bruteforce”才可用。 它不应通过您的界面发生。
• 使用证书进行身份验证–公钥加密可用于在用户与服务器之间建立相互信任–用户知道服务器是正确的，并且服务器知道用户不是以某种方式获得密码的随机人。
• 使用硬件令牌–使用数字签名与上述选项相同，但是它们将证书存储在硬件设备上，不能从那里提取。 因此，只有物理设备的所有者才能进行身份验证

Web安全是一个复杂的领域。 对于真实系统，不得遵循Hello World示例。 考虑对系统外部用户的所有影响。 底线：使用bcrypt。

参考： Bcrypt，盐。 这是最低限度的价格。 来自我们的JCG合作伙伴 Bozhidar Bozhanov ，来自Bozho的技术博客博客。

翻译自: https://www.javacodegeeks.com/2012/08/bcrypt-salt-its-bare-minimum.html