散列是否足够加密

Question

在与服务器通信的同时，使用散列函数和算法是否足以加密数据

我正在我的项目中应用盐机制，我将把盐与输入的密码连接起来，然后将它们全部散列。

我还需要加密结果吗？

Answer 1

网站传输用户密码的通常工作流程如下所示：

1. 客户端将密码明文发送到服务器。
2. 传输是通过加密连接 (HTTPS/SSL) 完成的，以防止 ManInTheMiddle 攻击。
3. 服务器计算明文密码的hash，然后将该hash 存储在数据库中。无需进一步加密哈希。

确保为每个密码使用随机唯一盐，并使用具有成本因子的慢速哈希函数对密码进行哈希处理。好的算法是 BCrypt、PBKDF2 或 SCrypt。

Answer 2

存储密码

要安全地存储用户密码，您需要做 3 件事：

1. 不要存储普通密码，而是存储一个哈希

   即使攻击者设法捕获了整个数据库，哈希也使得恢复密码变得极其困难

2. 为了防止使用彩虹表，您需要一个盐

   盐以明文形式存储（可以与散列一起）并且是随机的，每个用户一个，并且您可以在用户更改密码时轻松选择几个。

3. 您需要 SLOW 散列，而不是快速散列

   什么是快速哈希：MD5（认为它已损坏）、SHA-1、SHA-2 ……不适合，因为攻击者执行它们的速度可能过快，并使用字典攻击尝试常用密码并找到这种方式在现代设备上，您只需数小时即可获得 95% 的用户密码。

   需要多慢？尽可能慢。

还有一条规则 0：不要自己发明加密货币，你会在不知不觉中犯下严重的错误。

其他隐私敏感信息

除了密码（电子邮件地址、IP 地址、姓名、邮政地址……）、抄送号码（最好不要去那里）、……之外，您很可能还会存储访问者的其他敏感信息。 .

您还需要保护它，并且在大多数情况下使用哈希并不是这样做的方法。其中一些有自己的要求和规定（例如，信用卡数据受发卡机构监管，发卡机构会强制您遵守 PCI-DSS）。

本质上，您需要进行风险分析并通过接受风险（“就这样”）、转移风险（“获得保险”）、避免风险（“我们不存储”）来管理风险，或减轻它（“我们将改进我们的工作方式”）。

加密

为什么媒体会让你相信在那个难以理解的“加密”事物中有一个“神奇”的解决方案，实际上它需要在正确的条件下正确完成才能具有任何意义。

例如如果您加密服务器的整个磁盘：它不会保护您免受攻击者滥用您的服务器脚本并访问数据库（因为数据库引擎和网络服务器脚本已经可以访问解密的磁盘）

因此，您确实需要回到风险分析并选择其中的措施，而不是超越自己并建议将加密作为一种不太可能帮助您应对最大风险的工具。