在传输过程中保持密码安全答案

【问题标题】：Keeping passwords secure during transmission在传输过程中保持密码安全
【发布时间】：2015-01-19 10:34:32
【问题描述】：

在我的网络应用程序中，我正在实施用户无法选择的密码黑名单。正如 Jeff 的 God Login 帖子中提到的，这是因为一些密码非常常用，并且存在于暴力破解工具使用的 readily available wordlists 中。

我曾计划将列入黑名单的密码存储在数据库表中（明文），并带有MD5 hash of it as a Functional Index。因此，当查询发送到服务器时，它看起来像这样：

SELECT 1 
FROM blacklist AS a 
WHERE MD5(a.password) = 'MD5stringOfPasswordSubmitted';

我不认为这些密码的“明文”存储是个问题，因为这些密码被列入黑名单。没有用户可以将其设置为其中之一。所以谁在乎此表中的密码是否以明文形式存储。

但是，这个查询到数据库服务器的传输是我应该担心的问题吗？

如果我的用户正在尝试设置他们的密码，此时应用程序将对密码进行 MD5 处理，将其发送到数据库以查询此黑名单表。如果没有返回结果，应用程序将允许他们将其作为密码（只要还满足其他验证要求）。

这是我应该担心的事情吗？

这是否可以通过另一种方式实现，以便用户尝试设置的密码仍然保持安全？是否真的有必要通过 Bcrypt 存储盐渍哈希（就像在我的用户表中一样），即使只是为了这个黑名单使用？在我的应用程序的本地目录结构中使用 YAML 文件是否会有同样的风险？

其目的是防止用户选择常见的密码，并在验证过程中以非常快速的方式（因此是 MD5）对其进行检查。

【问题讨论】：

需要更多帮助吗？如果是这样，我会更新我的答案。

标签： security hash passwords password-hash

【解决方案1】：

我看不出查询的传输会出现什么问题。如果你的 Web 应用程序进行了 MD5 编码并且攻击者截获了与数据库的通信，那么他就无法从中取回用户的密码。

MD5 存储密码并不安全，因为攻击者可能能够找到导致相同哈希值（冲突）的密码，但无法将哈希值转换回其来源的明文。

如果您在查询数据库时担心泄露其他敏感数据，可以考虑对通信通道进行加密。

【讨论】：

【解决方案2】：

我不会担心密码的传输，因为它们是使用单向算法进行散列的（正如 user18044 指出的那样），但是更多地扩展了 MD5 的弱点 - 我根本不会使用该算法，特别是如果你不使用盐。原因是因为 MD5 rainbow tables 已为一组非常大的可能密码组合创建。事实上，您所指的密码列表很可能是在搜索 MD5 表或使用online services 后生成的，这将通过提交 MD5 哈希为您提供密码（如果密码之前已经被破解或在某些桌子）。我建议使用盐或使用另一种算法，如 SHA-256。安全性是我的专长，我有一个能够以每秒数千亿次的速度破解 MD5 哈希的设备，但是如果涉及到盐，它要么会减慢我的速度，要么会一起阻止我（如果不知道盐）。相同的设备可以破解 SHA-256，但破解每一个所需的时间要长得多，因为 SHA-256 迭代自身的次数足够多，使每次迭代的速度足够慢，从而降低了破解的可行性。

正如已经提到的，我肯定会使用 SSL 来更好地保护所有传输的数据。

【讨论】：

【解决方案3】：

但是，这个查询到数据库服务器的传输是我应该担心的问题吗？

这取决于您的网络拓扑。例如

数据库服务器是否在同一个专用本地网络上？那么这是低风险的。
是同一网络上的数据库服务器，但与其他机器和用户共享。那么这是中等风险（您需要信任所有其他机器和用户）。
数据库服务器是否跨互联网？那么这是高风险的。

根据您接受的风险级别，您可能希望使用 SSL/TLS 保护与数据库的连接。

即使您使用 MD5 进行散列，MD5 也被认为是一种弱散列算法，因此如果 MITM 在您的数据库上查询密码时抓取了密码，他们可以通过诸如 John the Ripper 之类的工具使用单词列表和拦截用户设置的任何密码。

您可以尝试使用另一种算法对密码进行哈希处理，但这意味着在您的系统上实施“静态盐”（称为胡椒），以避免对截获的数据进行任何哈希比较。简单地连接 SSL/TLS 来完全避免这种情况可能会容易得多。

对于密码本身的存储（一旦通过您的检查），请务必在此处使用安全算法，例如 bcrypt 或 scrypt。

【讨论】：