4

How do I prevent exposing MySQL usernames and passwords in PHP code when establishing a connection?

TheJulyPlot
  • 7,669
  • 6
  • 30
  • 44
FGrunge
  • 49
  • 3
  • Duplicate of http://security.stackexchange.com/questions/48590/reasonable-way-to-store-encrypted-passwords-in-a-webapps-database-linux – mti2935 Jan 17 '16 at 13:03

3 Answers3

1

Hanky 웃 Panky brings up good points. However, I'd like to add to them:

  1. You can mitigate damage by restricting connecting accounts by roles. Let's say you only allow searching on your website. Allowing only SELECT statements for that particular account will prevent anything else from running. This doesn't work if you have an account for each: SELECT, UPDATE, INSERT, DELETE, as an attacker could combine the privileges and cause serious damage.
  2. You can also deny anyone except those with appropriate admin access to the website, whose login will likely be independent of the webhost. IP-based deny all, allow from , for example. Note that this won't completely protect you if you've been breached, nor will it protect you if your web host is the one accessing the database.

Only those with root/admin/shell access to your website can obtain the username and passwords, unless you improperly chmodded the files. If any of those are true, you have much bigger issues than having your MySQL user/pass known.

Mark Buffalo
  • 22,498
  • 8
  • 74
  • 91
  • +1 for different SQL accounts. There's no need to give an application the access to `DROP TABLE` if it never uses it for example. If a cron must drop tables, then make that cron executed on a machine which isn't connected to the web. – Benoit Esnard Jan 16 '16 at 22:37
  • 1
    Also, another option is to prevent the app to use `DELETE`, and to use `UPDATE table SET is_deleted = true` instead. It's far easier to recover if anything goes wrong, since the application doesn't have evil privileges. – Benoit Esnard Jan 16 '16 at 22:39
1

It is never a good idea to store passwords in source code. Source code has the horrible tendency of becoming public. This can happen by an exposure in your version control system (google aws key github to read some horror stories), you share the source code with someone, a but in your PHP configuration serves your source code, etc...

Also, you should be able to change your password on an independent schedule from source code upgrades. Something storing them in the same file prevents.

Instead, put the password in a configuration file. This file should be outside of the web root to reduce the likelihood that it will be incorrectly served to the user. Secure it with appropriate OS permissions. You can pass the password to your PHP via an environment variable.

Neil Smithline
  • 14,621
  • 4
  • 38
  • 55
0

The typical answer is: store them in configuration files because code files are often published. A new trend seems to be to store it in environment variables, if you can control those when starting the server. On shared hosting this is not the case, and then configuration files are a fine option. After all, once someone gets to your filesystem, they could also change your source code and thereby do anything anyway.

Luc
  • 31,973
  • 8
  • 71
  • 135