Question

最近我一直在寻找为项目添加一些安全性。我一直在对这种情况进行大量研究，发现显然密码哈希是必须的。此外，我得出结论，最好的选择是使用bcrypt，PBKDF2或scrypt。

此外，我已经看到很多关于散列与加密的讨论，并发现很明显散列更重要。也就是说，经过对谷歌深处的多次搜索后，我还没有找到任何有关加密已经正确的密码密码是否有任何好处的信息，可能造成伤害或相对中立。

这两方面的CPU成本是否值得？有没有陷阱？

Answer 1

加密某些内容会导致需要解密，从而导致您已经遇到的问题：安全存储密码。

假设您希望将密码存储为哈希而不是纯文本，那么您基本上就是这样做：

hashpw := hash(salt + password)

然后将salt和hashpw存储在文件中，并使用此数据而不是纯文本密码。（请注意，在许多情况下，盐和密码串联的顺序至关重要，这只是流程的可视化，仅此而已;使用工具生成盐渍哈希）。

然后，可能的攻击者需要猜测salt和纯文本密码以检查是否匹配存储的hashpw，与您正在使用的哈希算法一样安全（冲突率）。

使用某种密码加密某些内容的好处是可以恢复纯文本散列方式不提供。它还要求解密密文的系统具有密钥可用。假设您使用某个键foo加密字符串bar。解密生成的密文 brn您需要再次使用密钥bar。此密钥需要在系统上安全存储，并且密钥是否暴露对于攻击者来说，所有的安全都消失了。

作为一般的经验法则，我会说哈希提供了一种存储文本的好方法检查（例如，密码），因为其安全性由冲突率确定哈希算法。另一方面，加密是您用来存储其余部分的技术数据安全。

Answer 2

你走在正确的轨道上。使用密钥派生/密码散列函数，就像你提到的那样。

不要只使用哈希或盐渍哈希。主要问题是传统的哈希算法（MD5，SHA- *等）旨在快速。这对于密码存储是不利的，即使你添加一个盐，许多实现也是易碎的。

加密始终会引入与管理相关的密钥问题。密码存储应该避免使用。

KDF的优势在于工作因素。它的设计速度慢且计算成本高，这就是为什么他们对这种情况有所了解的原因。 Scrypt是您正在考虑的最具弹性的选项，因为它需要一定量的内存来执行。这会杀死GPU攻击向量。无论你采取哪种方式都有权衡，但只要你使用适当的工作因素，你的所有选择都是可以的。

Answer 3

我只是加密密码。散列很快，但对密码有点不安全。当我出于安全目的使用散列时，通常用于消息签名之类的事情，例如消息+哈希（消息+密码）以便消息可以被验证，但我不是该领域的专家。我没有看到两者兼顾的重点。