Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I have a few private repositories set up on GitHub for some of the projects I am working on for my company. These applications connect to databases and I have database authentication credentials stored in a file called config.php (in plain text).

How risky is this, given that my code is on GitHub's servers? I know that from my end, only people I grant access to for the repo will be able to see this information but do I need to worry about other sources of leakage?

share|improve this question
1  
Assume that GitHub is secretly run by the NSA and they can read anything you store on GitHub. Alternatively, assume that your worst enemy has hacked into GitHub. That's paranoid, but should give your passwords the protection they deserve. –  gnasher729 Mar 18 at 16:39
add comment

4 Answers

up vote 7 down vote accepted

This is an interesting question with several facets that should be broken down.

The first question you asked is "How risky is this?" and the answer is "Very". Exposing those credentials on a 3rd-party service that you don't control and manage then you are increasing the risk. There are lots of ways your credentials could be exposed: service compromise, compromised service accounts, authorization failure in the service, network eavesdropping (if SSL/TLS isn't used to serve code), you granting access to the wrong person, etc.

Basically, consider those credentials exposed.

Sounds terrible, right? Maybe not... Now you have to ask the question "Am I comfortable with that risk?" If you have other mitigations in place then you might be okay with it. If you limit (perhaps with IP whitelisting) where those credentials can be used from then the credentials become less useful to steal. The service could also extremely low value and it doesn't make financial sense to add additional security. If the cost of recovering from a compromise is $10 and adding in extra security would cost $1,000,000 then you live with the risk. (That said, if you've made a commitment to your users about protecting them or their information, you have an ethical obligation to try to honor that commitment, regardless of the cost.)

Some additional thoughts:

"projects I am working on for my company" - You are doing this on behalf of the company you work for, they probably have policies or acceptable practices. If that's the case, those should take precedent over what you're comfortable with. The risk you're creating affects your company and it's reputation, the company gets to make the final call.

Lucas Kauffman suggests a good approach. I can't say if it will work for you but the takeaway is to find a mitigation that works for your deployment process and reduces risk to a comfortable level.

share|improve this answer
add comment

I do this as well as I work on a project stored on Github from different locations. However, the moment my code goes into acceptance or production, the password is changed to something random. So for testing/development, I don't really care about my database credentials being in there, as they are only valid on my development machines and no data in there is confidential.

share|improve this answer
    
Does it help that the database can only be accessed through SSH via a different server that itself needs you to authenticate yourself? –  karancan Jul 3 '13 at 19:10
7  
No, storing credentials for production anywhere else than on the server is not acceptable. For some type of companies auditors even require that the developers are not aware of the password and that they do not get access to it. –  Lucas Kauffman Jul 3 '13 at 19:13
add comment

Regardless of whether your (relaxed?) level of security needs would make it okay to store passwords in the repository, there is absolutely no need to do it.

I just ran into the same problem with database passwords used from php scripts, and my answer was to write a simple php script to automatically generate random passwords. The idea is to run the password generator one time, right after first downloading the source, to generate local passwords. These should never get pushed up to the repository; when the code is downloaded elsewhere (by a collaborator or on the production server), again the generator must be run once locally to get a different set of passwords.

If you cannot be bothered to implement it yourself, just use my code (which currently assumes the database and the php interpreter are run on the same server): https://bitbucket.org/steinb/nopassword

share|improve this answer
add comment

Storing your password anywhere in plain text is always risky. Now I'm not sure if this is possible in php but I know for a fact in .NET it's possible to encrypt the config files.

share|improve this answer
7  
And they key to decrypt this is stored where? –  Lucas Kauffman Jul 3 '13 at 18:40
    
It's been a long time since I set it up for .NET. If I remember correctly I had to install a certificate on the machines that were using that file and the config information for production wasn't in the code repository at all. The config info for local we didn't care about because it doesn't provide access to sensitive data. –  Four_0h_Three Jul 3 '13 at 19:07
    
I have re-tagged the question with the php tag –  karancan Jul 3 '13 at 19:11
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.