encryption - 散列、加密或两者兼而有之

Question

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

我也看到了很多关于散列与加密的讨论，并发现很明显散列更重要。也就是说，在对 Google 进行了多次深入搜索之后，我还没有找到任何信息来说明加密已经正确散列的密码是否有益、有害或相对中立。

两者的 CPU 成本是否值得？有什么陷阱吗？

Answer 1

加密某些东西会导致需要解密，这反过来又会导致您已经遇到的问题：秘密的安全存储。

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

hashpw := hash(salt + password)

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

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

使用某种密码加密某些东西的好处是能够恢复纯文本，这是散列方式不提供的。它还要求解密密文的系统具有可用的密钥。foo假设你用一些 key加密了一个字符串bar。要解密生成的密文 brn，您需要bar再次使用密钥。此密钥需要在您的系统上进行安全存储，如果密钥暴露给攻击者，则所有安全性都消失了。

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

Answer 2

你在正确的轨道上。使用您提到的密钥派生/密码散列函数。

不要只使用哈希或盐渍哈希。主要问题是传统的散列算法（MD5、SHA-* 等）旨在快速。这对密码存储不利，而且许多实现都是易破解的，即使您添加了盐。

加密总是引入与密钥管理相关的问题。应避免用于密码存储。

KDF 的优点是工作因数。它的设计速度很慢且计算量很大，这就是为什么他们是这种情况的想法。Scrypt 是您正在查看的选项中最具弹性的选项，因为它需要一定数量的内存才能执行。这会杀死 GPU 攻击向量。无论您采用哪种方式，都需要权衡取舍，但只要您在可配置的情况下使用适当的工作因素，您的所有选择都可以。

Answer 3

我会简单地加密密码。散列很快，但对密码来说有点不安全。当我出于安全目的使用散列时，通常用于消息签名之类的事情，例如消息+散列（消息+密码），以便可以验证消息，但我不是该领域的专家。我看不出两者都做的意义。