先说几点：

• 立即忘记 MD5。它又老又弱。
• 理想情况下，也不要忘记 SHA1。有SHA2和SHA3。
• 这种纯粹形式的哈希算法对很多事情都很有用，但对密码却没有用。将它们与例如结合使用。PBKDF2，或使用 bcrypt（不要忘记加盐）。

因此，如果我没记错的话，密码是经过哈希处理的，这样在您的数据库遭到破坏的罕见情况下，由于密码被哈希处理，黑客无法看到您数据库中的所有密码。

正确的。虽然这无助于使您的服务器更安全（毕竟，在这种情况下它已经受到威胁），但它可以防止例如。攻击者在其他网站上使用密码。可悲的是，大多数人将一个密码用于多件事。

破解数据库有那么容易吗？我的意思是，与其寻找新的哈希方法，为什么他们不能让他们的数据库更安全或“防黑客”？

你可以（而且你应该）。但：

• 即使您付出了所有努力，攻击者也总有一些机会获得访问权限。您不了解和/或无法修复的软件和设备中的错误，以及更多其他问题。
• 通常你不能尽你最大的努力，因为经理认为安全不重要，没有预算等等。

如果黑客设法侵入了某个数据库，他为什么要知道散列密码？我的意思是他可以更改其他数据列。例如，他可以搜索他的用户名并增加他的银行余额。那么，不应该对所有字段进行哈希处理吗？

如果所有字段都经过哈希处理，那么数据库对您也无用；所以你不能那样做。请记住，一个好的散列不能被反转。

如上所述，一旦您的数据库/服务器受到威胁，对您的损害就已经发生了。散列密码只是防止攻击者也可以访问您用户的其他帐户（然后一些用户会起诉您，因此散列也可以帮助您）。

MD5 和 SHA-1 不再安全，不是因为“大多数密码哈希现在都在互联网上”。实际上，使用盐使密码散列在全球范围内是唯一的，这使得这不可能。它们已经过时了，因为它们太快了，而且太多的候选密码可以太快地针对被盗的哈希进行测试，以致于不方便。

散列的缺点是它不可逆。这就是为什么它不能用于所有敏感数据的原因。例如，如果您的银行余额是散列，那么对您或银行都没有多大好处，而且你们都不知道它是什么。

1. 虽然考虑到配置良好的系统可能并不那么容易，但操作系统或应用程序级别的多个漏洞（如 SQL 注入，甚至可能包含文件）可能会导致数据库受损，这在现实中经常发生。通过散列密码来保护密码是深度防御的一个例子。即使防线失败，获取实际密码仍然相对困难。

2. 出于多种原因，密码是一个很好的目标。一方面，它们允许冒充用户，而不是使用攻击者（可能已泄露）的帐户读取、更改或删除数据。此外，用户倾向于重复使用密码，因此从一个应用程序中窃取的密码很有可能对同一用户的其他帐户有效。至于为什么其他数据不被散列 - 散列是一种方法，你不能从散列中取回原始值（至少不是微不足道的，在现实中并且有许多散列函数，你有很好的机会，但让我们忽略它片刻）。作为一种方式意味着哈希函数适用于检查输入的密码是否与存储的密码相同，但不适用于以未加密形式存储您实际需要的数据。这就是您可能一直在寻找的解决方案，加密，而不是散列。加密数据库中的敏感数据确实是一个好主意，但这也有其自身的问题，例如密钥管理。

破解数据库有那么容易吗？我的意思是，与其寻找新的哈希方法，为什么他们不能让他们的数据库更安全或“防黑客”？

通常，可以使用 SQL 注入通过 Web 应用程序入侵数据库。我们绝对应该优先解决 SQL 注入问题。但是，在大型应用程序中，只需开发人员在一行上犯错，就会引入这样的漏洞。因此，当我们试图阻止它时，我们还会计划其他防御措施，以防漏洞通过。

如果黑客设法侵入了某个数据库，他为什么要知道散列密码？我的意思是他可以更改其他数据列。例如，他可以搜索他的用户名并增加他的银行余额。那么，不应该对所有字段进行哈希处理吗？

在许多情况下，SQL 注入允许攻击者读取数据，但不能更改它。如果密码没有经过哈希处理，他们可以以其他用户身份登录并进行更改。密码散列有助于防止这种情况。此外，用户经常在许多网站上重复使用密码，即使这样做是不好的做法。

为什么只对密码进行哈希处理？

在设计良好的应用程序中，所有身份验证令牌都经过哈希处理。这包括会话 ID 和密码重置令牌以及密码。其他数据（例如您的银行余额）没有经过哈希处理，因为应用程序需要明文格式的数据才能运行。