在什么情况下，黑客会得到表而不是PHP代码？

好的，所以我理解我散列密码中的salt值。。。有点

我正在设置一个基本的身份验证方案，其中我正在设置密码，而用户无法将密码设置为他们可能用于其他站点的内容

那么盐的真正用途是什么呢

在什么情况下，有人可能会破坏我的用户表，但却无法访问包含所有数据的其余表，或者无法访问我的PHP代码

我想确定在我的情况下，盐的使用是否真的那么重要

---

据我所知，salt会在该表被破坏的情况下减慢用户密码的反向计算。salt与密码关联，然后单向散列，以避免从彩虹表或预散列密码列表中确定泄露的密码。

如果随机使用一个ASCII字符进行salt，攻击者需要一个比不含盐的彩虹表大256倍的表

对于2个ASCII字符，其大小已经是原来的65536倍

真正需要提到的是，为什么你应该使用盐类是因为大多数用户使用直接在字典中找到的单词。我没有多少数据，但我猜是很多。因此，即使没有使用rainbow表，攻击者也只能一次“暴力强制”一小部分密码。如果你没有salt，做一些修改（添加数字，…）的字典攻击，你只需要一次字典攻击就可以得到30%的密码。对于salt来说，这不可能在一次运行中发生，这意味着它需要更多的时间，这意味着对攻击者来说毫无意义

关于你的另一个问题：

---

没有任何东西会阻止攻击者获取其他表数据。但是，无论是否加盐，对密码进行哈希处理都无法避免。

对密码进行哈希处理（并首先对其进行哈希处理）的最大问题是，许多人。。。事实上几乎所有的人。。。重新使用他们的密码。此外，大多数用户表还存储电子邮件和/或用户名。因此，如果有人设法获得了你所有用户的密码，那么损害不仅发生在你的网站上，而且还发生在那些用户注册后可以轻松查找的任何其他地方。由于所有数据通常都存储在usertables中，因此损失很难夸大

简言之；破解的密码不仅让用户能够访问您托管的内容，而且会影响客户登录的每个网站的安全

---

但要回答标题问题；如果数据库被破坏，PHP代码也很可能被破坏。但是，他们可能只获得对PHP代码的读取权限，而大多数数据库访问级别确实需要插入/更新权限，应用程序才能正常运行。有些人将SQL访问权限拆分为读写权限，但在大多数情况下这并不现实，因为您总是在插入和更新，即使在用户尚未登录的页面中（计数器，如/不像按钮等）。

应该注意的是，SQL注入可用于使用读取文件。由于攻击者不知道salt值，这将迫使攻击者进行更多猜测，以获得纯文本。尽管盐渍几乎从不考虑这一点。主要思想是两件事：完成两件事：

1） 具有相同密码的两个用户将具有不同的密码哈希。这就是为什么一些盐析系统使用非常小的盐分，例如只有几个字节

2） 迫使攻击者生成更大的漏洞。在这种情况下，您至少需要8个字节。通常情况下，您会看到与消息摘要函数相同的位数，这使得预计算完全不可行

---

一旦获得了salt，就可以使用工具强制输入密码。GPU也常用于破解加密密码。需要注意的是，bcrypt（）由于其高内存需求，擅长防御FPGA和GPU。可以产生一个非常强大的密码存储系统

如果您希望您的用户在密码表被盗时不会受到严重影响（他们无论如何都会受到影响，因为在这种情况下，您应该强制所有人立即更改密码，以尽可能减少损害），那么Salt非常重要。你为什么关心事故是怎么发生的？你会问在什么情况下安全气囊会激活，并考虑不在你的车上安装安全气囊吗？也许你应该为这个问题选择一个不同的答案。所以我猜问题是，在网站被破坏后，反向计算密码的后果是什么。就我而言，什么都没有；安全漏洞需要修复，密码需要重新生成，但一旦我发现并修复了问题，拥有我编的10-15个密码的人不会有任何好处，对吗？所以没有盐？你可能在谈论md5，你也可以用sha256等进行散列，如果不是123456类型，很难找到原始字符串…这和我说的没什么区别。此外，今天我很高兴应用程序使用哈希。如果腌制得更好。事实上，有数以百万计的应用程序甚至不使用任何类型的散列。所以sha256不是不使用盐的标准。无论如何，即使使用sha256，使用盐也更安全，这是事实。数据必须安全保存多年，谁知道一个邪恶的混蛋是否已经在计算它了这不是邪恶，而是聪明。。。当然，密码应该是咸的，我只是说纯md5最容易破解。。。每个非标准哈希/加密都很好。。。如果你不知道它是什么，你就无法破解它。你指的是默默无闻的安全？我永远不会使用任何加密/哈希算法，这些算法不是公共可用的，并且由crypt检查