5 ms·

Why are you storing the whole salt in your database? Isn't it much more common to keep half of it in a configuration file? I know Django has a SECRET_KEY parame

Why are you storing the whole salt in your database? Isn't it much more common to keep half of it in a configuration file? I know Django has a SECRET_KEY parameter for this sort of thing, and hopefully other frameworks do also. How is that really any better? You should assume that if an attack can get to your database, they can get to your web servers and take all of that as well. Such a scheme certainly wouldn't have saved Gawker.

jhchen 16y ago
In Gawker's case this is exactly right. The database AND the source code was accessed so the config file defense would not have worked.
jmillikin 16y ago
Config files are not typically world-readable; the httpd reads them before dropping permissions. Otherwise, a vulnerability in the httpd would allow access to everything in the config (remote server passwords, signing keys, etc). There's no reason why compromising the database would allow attackers into the web server, unless you've configured SSH to allow signing in from arbitrary remote systems.
- tptacek 16y ago
  If you lose code execution on your server to an attacker, you're done. 100% fucked. Everything in your environment needs to get stripped down and rebuilt from trusted sources. Do not be one of those people who rationalizes "oh, I just lost uid=4294967294". Gawker lost root. So will you.
  - JonnieCache 16y ago
    And if you lose root, the disk must be reimaged. Rootkits are too advanced these days to ever make the assumption that you have removed them.
    - bigiain 16y ago
      It's possible that sometime not too far in the future that advice might need to be upgraded to "If you lose root, unplug and destroy the hardware and install a completely new machine from trusted sources". http://www.theregister.co.uk/2010/11/23/network_card_rootkit/ http://www.theregister.co.uk/2010/11/23/network_card_rootkit... (Why yes, I _did_ have that problem weighing on my mind while I investigated several machines that had a weekends worth of exposure to the recent Exim remote root exploit...)
- hoop 16y ago
  > Config files are not typically world-readable; the httpd reads them before dropping permissions. Otherwise, a vulnerability in the httpd would allow access to everything in the config (remote server passwords, signing keys, etc). I think you give people way too much credit. Maybe config files aren't "typically" world-readable but they ARE typically httpd-readable. It's a mistake to assume, that because you might follow best-practices, the rest of the people out there do. You said yourself in a comment on this same post that many people make mistakes because they're too lazy to take that "half an hour of research." Let's make the assumption that that is typical. > There's no reason why compromising the database would allow attackers into the web server, unless you've configured SSH to allow signing in from arbitrary remote systems. Oh, you mean the default behavior? See above.
- kgo 16y ago
  Direct DB access isn't typically world-accessible either. It's not like I can do an XML request to get my hashed password on any site. The point is, if someone has gotten enough access that they can actually get a raw copy of the database, it's just as likely they can get a raw copy of the config files, or /etc/shadow, or whatever else is on the host system.

jhchen 16y ago

In Gawker's case this is exactly right. The database AND the source code was accessed so the config file defense would not have worked.

jmillikin 16y ago

Config files are not typically world-readable; the httpd reads them before dropping permissions. Otherwise, a vulnerability in the httpd would allow access to everything in the config (remote server passwords, signing keys, etc). There's no reason why compromising the database would allow attackers into the web server, unless you've configured SSH to allow signing in from arbitrary remote systems.

tptacek 16y ago
If you lose code execution on your server to an attacker, you're done. 100% fucked. Everything in your environment needs to get stripped down and rebuilt from trusted sources. Do not be one of those people who rationalizes "oh, I just lost uid=4294967294". Gawker lost root. So will you.
- JonnieCache 16y ago
  And if you lose root, the disk must be reimaged. Rootkits are too advanced these days to ever make the assumption that you have removed them.
  - bigiain 16y ago
    It's possible that sometime not too far in the future that advice might need to be upgraded to "If you lose root, unplug and destroy the hardware and install a completely new machine from trusted sources". http://www.theregister.co.uk/2010/11/23/network_card_rootkit/ http://www.theregister.co.uk/2010/11/23/network_card_rootkit... (Why yes, I _did_ have that problem weighing on my mind while I investigated several machines that had a weekends worth of exposure to the recent Exim remote root exploit...)
hoop 16y ago
> Config files are not typically world-readable; the httpd reads them before dropping permissions. Otherwise, a vulnerability in the httpd would allow access to everything in the config (remote server passwords, signing keys, etc). I think you give people way too much credit. Maybe config files aren't "typically" world-readable but they ARE typically httpd-readable. It's a mistake to assume, that because you might follow best-practices, the rest of the people out there do. You said yourself in a comment on this same post that many people make mistakes because they're too lazy to take that "half an hour of research." Let's make the assumption that that is typical. > There's no reason why compromising the database would allow attackers into the web server, unless you've configured SSH to allow signing in from arbitrary remote systems. Oh, you mean the default behavior? See above.
kgo 16y ago
Direct DB access isn't typically world-accessible either. It's not like I can do an XML request to get my hashed password on any site. The point is, if someone has gotten enough access that they can actually get a raw copy of the database, it's just as likely they can get a raw copy of the config files, or /etc/shadow, or whatever else is on the host system.