Storing Credentials? (MySQL, APIs, etc.)

Question

I use a small script that fetches the credentials necessary for applications to run (MySQL databases, API credentials for 3rd-party apps, etc.):

function get_credentials($id) {
  $env = $_SERVER['DOCUMENT_ROOT'];
  $host = '/path/to/host/www';
  $local = '/path/to/local/www';  
  if (strpos($env, $host) !== false) $source = '/path/to/host/.wwwcred';
  elseif (strpos($env, $local) !== false) $source = '/path/to/local/.wwwcred';
  $index = file_exists($source) ? json_decode(file_get_contents($source), true) : false;
  return ($index ? true : false) ? (array_key_exists($id, $index) ? $index[$id] : false) : false;
}

The source (.wwwcred) is a flat, plain-text JSON file stored outside the web root with the minimum required permissions. Any application that needs to "login" to anything uses the above function to retrieve credentials; usernames and passwords are never stored inside any script/application.

My Question: Is there a more secure way to complete this task? Is there a procedure for encrypting the passwords stored in .wwwcred (and decrypt before passing)? Or is there a better approach to storing this kind of data altogether?

Answer 1

One potential change I would make is to not store the creds in a home directory. Perhaps something under etc (maybe /etc/external/.wwwcred ). Again, to add another layer of elevation prevention, I'd avoid home directories and anything under document root.

You said already that you have minimal permissions set. I'd probably create a group for all consuming apps (if it's only php, then the apache or www group should work), set the file owner to root:<your group> and set permissions to 640 . If possible, I'd keep all standard users out of that group- this should be something only root and the application layer should see.

Answer 2

nmax, not very code specific but here goes.

I guess it all depends how far you want to go with the security. You could hash the credentials and keep them in a file to 1. cut down on database queries and 2. they don't get accidentally get passed around on backups and dumps etc.

If you went down the hashing route keep in mind one thing:

• work factors

Since resources are normally considered limited, a common rule of thumb for tuning the work factor (or cost) is to make protect() run as slow as possible without affecting the users' experience and without increasing the need for extra hardware over budget. So, if the registration and authentication's cases accept protect() taking up to 1 second, you can tune the cost so that it takes 1 second to run on your hardware. This way, it shouldn't be so slow that your users become affected, but it should also affect the attackers' attempt as much as possible.

While there is a minimum number of iterations recommended to ensure data safety, this value changes every year as technology improves. An example of the iteration count chosen by a well known company is the 10,000 iterations Apple uses for its iTunes passwords (using PBKDF2) 2 (PDF file). However, it is critical to understand that a single work factor does not fit all designs. Experimentation is important.[*6]

As well as the above also think about:

• Transmit Passwords Only Over TLS
• Password Complexity

I have also attached some links on password, TLS and some other OWASP cheat sheets:

• https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet
• https://www.owasp.org/index.php/Authentication_Cheat_Sheet
• https://www.owasp.org/index.php/Choosing_and_Using_Security_Questions_Cheat_Sheet