什么情况下黑客会得到表但拿不到PHP代码？
好的，所以我了解散列密码中盐的价值......有点。
我正在设置一个基本身份验证方案，在其中设置密码，并且用户无法将密码设置为可能用于其他站点的密码。
那么盐的真正用途是什么？
在什么情况下，有人可能会破坏我的用户表，但又无法访问包含所有数据的其余表，或者显示神奇功能的 PHP 代码？
我正在尝试确定盐的使用对于我的情况是否真的那么重要。
谢谢
Ok, so I understand the value of the salt in my hashed passwords... kind of.
I am setting up a basic authentication scheme where I am setting passwords and users don't have the ability to set the passwords as something that they might use for another site.
So what is the real utility of the salt?
Under what circumstances could someone compromise my user table but not also get access to the rest of the tables with all the data, or my PHP code that shows the magic?
I'm trying to determine whether use of a salt is really that important in my case.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
需要注意的是，SQL注入可用于使用 load 来读取文件数据输入文件。通过攻击者未知的盐值，这将迫使攻击者进行更多猜测以获得纯文本。尽管加盐几乎从不考虑这一点。主要思想是完成两件事：
1）具有相同密码的两个用户将具有不同的密码哈希值。这就是为什么一些加盐系统使用非常小的盐，例如仅几个字节。
2) 迫使攻击者生成更大的rainbow table。在这种情况下，您至少需要 8 个字节。通常，您会看到盐与消息摘要函数具有相同的位数，这使得预计算完全不可行。
获得盐后，可以使用工具 John The Ripper 来暴力破解密码。 GPU 也常用于破解高盐密码。值得注意的是，bcrypt() 由于其对内存的要求较高，因此擅长防御 FPGA 和 GPU。 使用内存硬函数进行密码存储可以产生非常强大的密码存储系统。
It should be noted that SQL Injection can be used to read files using load data infile. By having a salt value unknown to the attacker, this will force the attacker into making a lot more guesses in order to obtain the plain text. Although salting almost never takes this into consideration. The main idea is two accomplish two things:
1) Two users with the same password will have different password hashes. This is why some salting systems using very small salts, such as only a few bytes.
2) Forcing the attacker to generate larger rainbow tables. In this case you want at least 8 bytes. Often times you see salts the same number of bits as the message digest function which makes pre-computation totally infeasible.
Once the salt is obtained a tool John The Ripper can be used to brute force the password. GPU's are also commonly used to break heavily salted passwords. It should be noted that bcrypt() good at defending against FPGA's and GPU's due to its high memory requirements. Using memory hard functions for password storage can yield a very strong password storage system.
据我了解，如果该表被泄露，盐会减慢用户密码的反向计算速度。盐与密码连接，然后进行单向散列，以避免从彩虹表或预散列密码列表中确定受损密码的能力。
As I understand it, the salt slows down the reverse calculation of user passwords in the event of that table being compromised. Salts are concatednated to a password and then unidirectionally hashed to avoid the ability of compromised passwords to be determined from Rainbow Tables, or lists of pre-hashed passwords.
对密码进行加盐（并首先对它们进行哈希处理）的一个大问题是因为很多人……事实上几乎所有人……重复使用他们的密码。此外，大多数用户表还存储电子邮件和/或用户名。因此，如果有人设法获取您所有用户的密码，那么损害不仅会发生在您的网站上，还会影响到这些用户注册的任何其他可以轻松查找的地方。由于所有数据通常都存储在用户表中，因此造成的损害很难夸大。
简而言之;破解的密码不仅使用户能够访问您托管的内容，还会影响客户登录的几乎每个网站的安全。
但要回答标题问题；如果您的数据库受到威胁，您的 PHP 代码也极有可能受到威胁。但是，他们可能只能读取您的 PHP 代码，而大多数数据库访问级别确实需要 INSERT/UPDATE 访问权限才能使应用程序正常运行。有些人将 SQL 访问权限拆分为读取和写入，但这在大多数情况下确实不现实，因为您总是在插入和更新，即使在用户尚未登录的页面中（计数器、喜欢/不喜欢按钮等） .)。
The big issue with salting passwords (and hashing them in the first place), is because a lot of people... in fact almost all people... re-use their passwords. Furthermore, most user-tables also store emails and/or usernames. So if someone manages to get the password of all your users, the damage hasn't just been done on your site, but also anywhere else that those users are signed up where they can easily be looked up. With all the data that normally is stored in usertables, the damage is hard to exaggerate.
In short; cracked passwords not only give users access to the things you are hosting, but affects the customers' security on just about every site they log on to.
But to answer the title question; it's extremely likely that if your database is compromised, that your PHP code is as well. However, they might only get read-access to your PHP code, whereas most database access levels do require INSERT/UPDATE access for the app to function at all. Some people split SQL access to read and write, but that really isn't realistic in most cases because you're always INSERTing and UPDATEing, even in pages where your users haven't even logged in (counters, like/unlike buttons, etc.).
如果随机使用一个 ASCII 字符进行加盐，攻击者需要的表的大小是没有加盐的彩虹表的 256 倍。
对于 2 ASCII char salt，其大小已经是原来的 65536 倍。
真正需要提到的是，为什么你应该使用盐，因为大多数用户使用直接在字典中找到的单词。我没有具体数据，但我猜是很多。因此，即使没有使用彩虹表，攻击者也只能一次“暴力破解”一小组密码。如果您没有盐，请进行一些修改（添加数字等）的字典攻击，假设仅通过一次字典攻击，您就可以得到所有密码的 30%。对于盐来说，这不可能在一次运行中发生，意味着需要更多的时间，意味着对攻击者来说毫无意义。
对于您的另一个问题：
没有什么可以阻止攻击者获取您的其他表数据。但这是带有或不带有盐的哈希密码无法避免的。
If you salt with lets say one ASCII char randomly, the attacker needs a table which size is 256 times greater relativly to a rainbow table without salts.
For 2 ASCII char salt its already 65536 times more size.
What really needs to be mentioned, why you should use salts at all is the fact that most users use words directly found in a dictionary. I have no data on how much, but I guess it is much. So even if there are no rainbow tables used, an attacker can only "bruteforce" a small set of passwords at a single time. If you have no salt, do a dictionary attack with some modifications (addings numbers,...) and you get lets say 30% of all passwords with only one dictionary attack. With a salt this cannot happen in one run, means it takes much more time, means its pointless for an attacker.
For your other question:
nothing hinders an attacker to get your other table data. But thats nothing hashed passwords with or without a salt can avoid.