哈希是否足以加密

Question

使用哈希函数和算法是否足以满足加密数据的需要，同时与服务器通信

我在我的项目中应用salt机制，我将使用输入的密码连接salt，然后将它们全部哈希。

我还需要加密结果吗？

Answer 1

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

1. 客户端将密码明文发送到服务器。
2. 传输使用加密连接（HTTPS / SSL）完成，以防止ManInTheMiddle攻击。
3. 服务器计算明文密码的哈希，然后将此哈希存储在数据库中。没有必要进一步加密哈希值。

确保为每个密码使用随机唯一salt，并使用具有散列密码成本因子的慢哈希函数。好的算法是BCrypt，PBKDF2或SCrypt。

Answer 2

存储密码

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

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

   即使攻击者设法捕获整个数据库，哈希也很难恢复密码

2. 要防止使用彩虹表，您需要 salt

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

3. 您需要 SLOW 哈希，而不是快速哈希

   什么是快速哈希：MD5（认为它已损坏），SHA-1，SHA-2，...不适合，因为攻击者可以执行它们太快并使用字典攻击来尝试使用常见密码并找到这种方式现代钻机上只有几个小时的95％的用户密码。

   需要多慢？尽可能慢。

并且有一个规则0：不要自己发明加密，在你知道它之前你会犯严重的错误。

其他隐私敏感信息

除了密码（电子邮件地址，IP地址，姓名，邮政地址......），CC号码（最好不要去那里），你最有可能还存储访客的其他敏感信息，...

你也需要保护它，在大多数情况下使用哈希不是这样做的方法。其中一些有自己的要求和规定（例如，信用卡数据由发行人监管，他们会强迫您遵守PCI-DSS）。

从本质上讲，你需要做一个风险分析，并通过接受它（“所以它”），转移它（“获得保险”），避免它（“我们不存储它”）来管理风险，或减轻它（“我们将改善我们的工作方式”）。

<强>加密

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

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

所以，你真的需要回到风险分析并选择那里的措施，而不是超越自己，并建议加密作为一种不太可能帮助你应对最大风险的工具。