4

I am using PHP with a singleton PDO to access the database, and it it obviously need MySQL's username and password.

As we all should know, the username and password should not be stored in a public directory.

I can therefore do something like require 'some_path/my_secrets.php'; which sets a bunch of variables, but then these variables are defined potentially globally which is not a good idea (granted, not globally when using a singleton, but still). Okay, I can only require the secret file within some function, but that is a lot to remember...

Is there a better way to make private data available to the PHP script? Also, any other steps I should be taking? Thank you

user1032531
  • 24,767
  • 68
  • 217
  • 387
  • possible duplicate of [Is it ever ok to store password in plain text in a php variable or php constant?](http://stackoverflow.com/questions/568657/is-it-ever-ok-to-store-password-in-plain-text-in-a-php-variable-or-php-constant) – Daniel A. White Feb 23 '13 at 14:54
  • 1
    to have only one global variable, you could have a global config array... – mb21 Feb 23 '13 at 14:54
  • @DanielA.White. Yes, I saw that one as well as http://stackoverflow.com/questions/6322766/php-basics-where-to-store-mysql-password-used-by-php, however, they are asking different questions. – user1032531 Feb 23 '13 at 14:56
  • @mb21. I was thinking if it was called in the initial file, but guess you are right. Still, do you want things like your database password floating around in a big program which might inadvertently print it on the screen? – user1032531 Feb 23 '13 at 14:57
  • You may take a look how QuickCMS or QuickCart is made. There is a global `$config[]` array. – Kamil Feb 23 '13 at 17:08

4 Answers4

1

I had the same problem and initially

  • DB passwords were stored in an include file within the includes directory (ie to prevent a incidental PHP code display directly from the web files)

then came another idea, a bit more complex but still pretty doable

  • Make a C program that owns the DB data encoded and delivers the data from a system call. The source code (that includes the encoded passwords) is owned somewhere safe. The C code has to perform some checks to ensure the call is made from PHP etc...

but this is pretty expensive - C is fast, but loading all the time the passwords through system is expensive. Therefore adding APC to the game makes the whole thing easier and faster

  • during the first request, load the DB data into APC permanent variables - thus the data is in memory and more difficult to obtain from outside. Typically the algorithm is

algo

Check if APC variables are set
If yes use them
If no load them from C program, only once

APC documentation

  • Another idea, using php-fpm for instance is to set an environment variable within the fpm configuration (readable only by root) that contains the passwords

Finally, you could also create your own PHP extension that provides the data from the C code (extensions are usually written in C). This is some extension documentation.

This is not the definitive answer in how to prevent passwords stealing, but at least it would make more difficult for the hacker to determine the passwords - and would require also more knowledge.

Déjà vu
  • 28,223
  • 6
  • 72
  • 100
1

Most systems I know have a .htaccess protected include file. Inside you define a config array and done. Maybe not the most secure way of doing it but that is many shops, CRMs and other web services do it.

Christoph Grimmer
  • 4,210
  • 4
  • 40
  • 64
0

First off, I would say, unless your PHP app needs it, restrict the permissions of the app's database account as much as possible (e.g.: read access on appropriate tables, perhaps write access as few as possible). If your app needs admin access to create tables, etc., that's a whole 'nother can of worms.

Secondly, as ring0 suggests, don't store the database password in plain text. I would recommend using a hashing API to store a hash of your password, such as this: https://gist.github.com/nikic/3707231. And of course, the hash might be best stored in some other 3rd place (at least a separate file). If your users are trustworthy, and you can figure out a way, you could have the hash be computed from the user's log-in information, but that might require separate entries in your password file for each user (because each hashed DB password will be different).

There is never a foolproof way, and I'm not a security expert, but I know plain text is always bad for storing passwords, so I think this is a step in the right direction.

Ogre Psalm33
  • 21,366
  • 16
  • 74
  • 92
  • 1
    Good point about restricting permissions at the table level. In regards to your second point, I am pretty sure that only applies to hashing your user's individual passwords, and not the root MySQL password. – user1032531 Feb 23 '13 at 15:58
  • All I'm saying is it's probably better to store a hashed password in a separate file, than store a plain-text password in your code or in a file, regardless of the purpose of the password. – Ogre Psalm33 Feb 24 '13 at 00:49
0

Your solution is fine.

Most of the suggested solutions are just exaggerated as although they may higher the level of security a bit they are not worth the additional effort.

Because the security should not only rely on the secrecy of the password. At best, even if the password get’s revealed, its knowledge is worthless for an attacker as he cannot use it.

This means, use a MySQL user dedicated to your application with permissions following the principle of least privilege and only allow the access to the database from that application’s web server (see MySQL Access Privilege System).

Gumbo
  • 643,351
  • 109
  • 780
  • 844