How do you avoid storing passwords in version control?

Question

What strategy do you use to avoid storing passwords in version control?

Currently, I have development/test/production passwords saved in three different files and the appropriate file gets used during deployment. All this is committed to version control, but I'm not too happy with that since not all developers need to know those passwords (especially outsourced ones, which have access only while their projects last, which could be only a month).

Storing passwords in database is not a great option:

• I need most of the data during the initialization of Spring context (Java app), and I don't want to build scaffolding for connecting to a single database, and afterwards connecting to the rest of databases and initializing the rest of application
• some of the passwords are only deployment-related; password to access different servers, keystores, etc.; those are the things application can't load after it starts, since it doesn't load it at all

I'm thinking about moving deployment configuration from developer machine to dedicated computer which checks out code from version control and runs build/deployment script, but I'm not really sure what would be the best way to do it.

I also need to say that I don't want ultimate security: I just want to avoid having passwords on every developer's disk and making it too easy.

So I'm asking for your experiences/best practices. How do you do it?

Answer 1

Environment-specific configuration properties I tend to put in, say, a properties file that isn't in source control and isn't part of the build process. When setting up a new environment, part of that setup is to put create that properties file that includes things like database addresses, credentials and names, names of relevant remote hosts and so on.

In Spring you use the PropertyPlaceholderConfigurer to load the properties file. It just needs to be findable by Spring, which usually just means putting it in an appropriate directory under the application server.

Alternatively, you use wrapper to run the application server and the JVM startup options include adding these properties files to the classpath so Spring can find them.

Answer 2

I've seen two approaches to this:

• Move the passwords into another tree of source control that developers don't have access to.
• Don't put any passwords into source control, and the dedicated build manager person needs to type in the passwords every time a deploy is done. This was in a bank where there was a full time guy working on build processes / merging / releases.

Answer 3

This doesn't work in all cases, but this is where the gloriousness of using NT AUTHORITY\NETWORK SERVICE as the identity of your services comes in. If you use this identity, you don't need to maintain a password for it -- you can just use the Computer's AD credentials in the form of DOMAINNAME\MACHINENAME$ to do your protected network and database access.

There are, of course, some key things to watch out for -- not the least of which is that no two apps which share a security boundary are hosted like this on the same server.