0

I'm wondering how we could hide sensitive data (databases passwords and other passwords) from some developers for our PHP projects. We are using Subversion for our projects. Is it enough to just disallow some users to access the folders where we have the files with the passwords? Any other suggestions?

morandi3
  • 1,095
  • 3
  • 14
  • 27
  • 2
    Don't store sensitive data in SVN, perhaps? Keep your passwords and other such information in config files that don't get committed to the repository. – i alarmed alien Sep 28 '14 at 13:36
  • 1
    Just create a config example and only add the sensitive data on the production server. So for example in svn you have the config.php.example file and the on production you copy this file to config.php – Perry Sep 28 '14 at 13:38

3 Answers3

2
  1. Do not store sensitive data in any code versioning system. Keep the variables empty.
  2. After first checkout, set the variables locally.
  3. In case of distributed/remote databases, simply create another access for that user to access that database and provide credentials.
  4. Once you set the values, exclude these files from being updated later.
DJ'
  • 1,760
  • 1
  • 13
  • 26
0

You could have a DB table that stores sensitive data, and only users with right credentials can read from it. Each developer has to enter username and password to access a DB via some configuration file. Also you don't need to set user and password for each developer as you can have ie 3 access levels so create just 3 users ie DeveloperAdmin ( can change password table) DeveloperTrustedRead (can read password table) DeveloperNotTrusted ( no access to password table) So you distribute same db user pass for not trusted dev.

BojanT
  • 801
  • 1
  • 6
  • 12
0

It should be enough.

If you want to implement a cost-effective yet secure way to let different people access the same resource (the password protected one, as a database) with different levels of security, look at this answer Different ways to store a password variable in a Java web application? and implement the option 3 in this way

  • create multiple usernames/passwords to access the same resource - like another answer suggests a DeveloperTrustedRead, DeveloperNotTrustedRead, etc... role in the database, each with a different username and password. DeveloperNotTrustedRead (for a database) should not create procedure, alter table, drop tables, access other DBs other than the one he operates, etc..
  • encrypt username/password for each role with a different key in your application (i.e. option 3)
  • give the untrusted developer the key only to decrypt the username/password linked to the role that has less permissions, like DeveloperNotTrustedRead or DeveloperNotTrustedWrite

This way you can distribute any file in the SVN, as you will be holding the key to decrypt the credentials that matters, while the distributed key will give access to a less powerful/dangerous set of permissions.

This makes sense only if you need them to access the password-protected resource (i.e. a DB) but you are worried to give high privileges to untrusted people, so you want to minimize their permissions for the DB (or any other protected resource) and keep sharing the code easily.

Community
  • 1
  • 1
sc0p
  • 416
  • 2
  • 2