数据库如何被黑客入侵？关于加盐等问题
请耐心等待，我只学习 PHP 几个星期，所以示例代码可能会让我感到困惑。我想我终于明白加盐了！这是为了保护数据库内的密码（如果遭到破坏）。
我不明白的是，如果黑客试图找出用户的密码（假设这是他们的目标），为什么他们必须破解哈希值？这不是更容易吗？防止密码猜测的唯一方法是限制每天输入 X 次密码或验证码吗？
数据库首先是如何被黑客攻击的？是更多的密码猜测还是可以通过MySQL注入获得哈希值？
谢谢！
Bear with me, I have been only learning PHP for only a few weeks, so example code may confuse me. I think I finally understand salting! It's to protect passwords inside database, if breached.
What I don't understand is, why would a hacker have to crack hashes if they are trying to figure out a user's password (assuming that's their goal)? Wouldn't this be easier? Is the only defense from password guessing is to implement a limit of password entry X amount of times a day or CAPTCHA?
How would a database get hacked in the first place? Is it more password guessing or can hashes be obtained through MySQL injection?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
加盐和散列的想法是为了保护密码，以防数据库遭到泄露，无论是通过 SQL 注入、缓冲区溢出攻击，还是仅仅通过进入服务器机房并将磁盘从机房中取出来。你的服务器。加盐不会保护您免受密码猜测，但有助于防止攻击者获取数据。
The idea of salting and hashing is to protect the passwords in case the database has been compromised, whether it was by SQL injection, buffer overflow attacks or simply by going to the server room and pulling the disk out of your server. Salting won't protect you against password guesses, but help in case the attacker gets to the data.
是的，加盐是为了防止密码被反转为明文。它还可以阻止有人说“站点 A 上的加密密码与站点 B 上的相同，因此用户在两个地方都有相同的密码”。
这不仅仅是为了保护用户免受黑客攻击；这也是为了保护他们免受你的侵害。
是的，防止密码猜测的唯一方法是减慢或禁止重复尝试。大多数验证码都是易破解或已损坏的，您不能对拥有原始数据库副本的人施加验证码或猜测限制。因此，即使是加密数据，也不要落入恶意个人之手。不要让它们进入您的 .htpasswd 或 /etc/shadow 文件或数据库。
如果您不使用 salt，（提前）生成彩虹表比直接猜测非常强的密码要容易得多。关键是构建反向映射哈希->密码只需一次即可完成，并且对于拥有彩虹表的任何人来说，（未加盐的）哈希将永远被破坏。
如果您的提供商受到威胁，如果您的代码中存在注入漏洞，如果您的数据库用户帐户密码被猜到，如果您的提供商使用 eBay 出售（假定已擦除）硬盘驱动器，该硬盘驱动器具有三项功能，则数据库可能会被黑客入侵。一年前的数据库副本...它可以通过多种方式发生。
Yes, salting is to protect against the passwords from ever being reversed into plaintext. It also stops someone from saying "the encrypted password is the same on site A as on site B, so the user has the same password in both places".
This isn't just to protect users against hackers; it's also to protect them against you.
Yes, the only defense against password guessing is to slow down or disallow repeated attempts. Most CAPTCHAs are breakable or broken, and you can't impose a CAPTCHA or guess limit on someone who has a copy of the raw database. So keep even the encrypted data out of the hands of malicious individuals. Don't let them at your .htpasswd or /etc/shadow file or your database.
If you are not using salt, generating a rainbow table (in advance) is much easier than guessing a very strong password directly. The key is that building the reverse mapping hash->password can be done once, and the (unsalted) hash is broken forever to anyone possessing the rainbow table.
The database could be hacked if your provider is compromised, if there is an injection vulnerability in your code, if your DB user account password is guessed, if your provider uses eBay to sell off the (presumed wiped) hard drive that had a three-year-old copy of your database on it... It can happen many ways.
这可能很愚蠢，但许多人在不同的网站上使用相同的密码。如果您的数据库遭到破坏并且密码只是经过哈希处理，那么黑客可以使用一些技术（例如彩虹表，甚至一些网站）来查找产生相同哈希值的密码值。然后，该密码可用于尝试访问该用户拥有帐户的其他网站。
如果您的数据库中的密码被加盐，那么这将变得更加困难......并且如果其他网站也使用与您不同的盐来为其密码加盐，那么对于黑客来说就变得不切实际。
It might be foolish, but many people use the same passwords for different sites. If your database is compromised and the passwords are simply hashed, then there are techniques (e.g. rainbow tables, even a few web sites) that a hacker could use to find a password value that results in the same hash. That password could then be used to try and gain access to other sites where the user has an account.
If the passwords in your database are salted, then this becomes significantly harder... and if other web sites also salt their passwords with different salts to yours, then it becomes impractical for the hacker.
这里的关键是，他们并没有试图获取在您的网站上使用的用户密码，尽管在您修复漏洞之后可能会有用。这样，无论出于何种原因，您的网站受到损害，您的用户都不会受到损害。人们倾向于重复密码；那会很糟糕。
The key here is that they're not trying to get the password of a user to use on your site, though after you fix the hole that might be useful. It's so that if, for whatever reason, your site is compromised, there isn't damage to you users. People have a tendency to duplicate passwords; that would be bad.