8

What are ways of getting database and other service passwords out of your code? I've read about using per server properties files but when you have a large number of servers it gets to hard to maintain. I've also seen a solution using a CI's build process to "inject" passwords but that makes it difficult to update the password on-the-fly.

Some requirements to help narrow the field of answers...

  1. The password should be easy to change and propagate in the event of a security breach.
  2. Password can not appear in code (due to point 1)
  3. It should be "non trivial" for a human to get a plain-text version of the password
  4. Should work well in the web application and stand alone applications
  5. Easy to adopt from a application developer standpoint

Some nice-to-haves include not introducing a single point of failure, a quick development time, and easy to understand.

This is similar in spirit to this question but with an strong emphasis on maintainability and focuses more on the server side case.

Community
  • 1
  • 1
Andrew White
  • 52,720
  • 19
  • 113
  • 137
  • How about storing it in a database? :) – Joe Enos Feb 03 '11 at 22:20
  • @Joe: that was actually a purposed solution but the idea of a password-to-rule-them-all ended that talk. – Andrew White Feb 03 '11 at 22:23
  • At least you only need to remember one password. You can burn that on a CD and store in in a safe. You will only need to remember the safe combination then. :) – GolezTrol Feb 03 '11 at 22:26
  • @Golez: wouldn't every app have to know the master password or have access to the password table to know what password to use? You can get into some circular logic there. – Andrew White Feb 03 '11 at 22:40
  • 1
    I think I already am. ;-) But as I said in my answer below, I think you can't fully protect this password. The application must know it, and if it is encrypted, the application must be able to decrypt it. The best way to protect is, is putting it in a place where no one can reach it from outside. When someone manages to get your physical server, the fact that they can reach that one file will be the least of your problems. :) – GolezTrol Feb 03 '11 at 22:45
  • @Golez: I totally agree; the goal isn't to perfectly secure the password, just get it out of the code and make it easy the change across a lot of servers. – Andrew White Feb 03 '11 at 22:50

3 Answers3

7

You could store it in plain text in a file in a protected directory that can only be read by the account in which the application is run. In case of a web application, you should always store the password outside the web root folder.

GolezTrol
  • 114,394
  • 18
  • 182
  • 210
1

If you use a database connection pool then the username, password and other database details are generally managed in the Java Web Container and presented to the Java code as a Datasource. You just ask for a Database connection without having to know any of these details.

trojanfoe
  • 120,358
  • 21
  • 212
  • 242
  • We do use container connection pools which is why I included "and other service passwords" since we have those out there as well. In the java stand alone case we don't have a nice container to handle data pools for us. – Andrew White Feb 03 '11 at 22:37
  • I don't think Connection Pools are limited to web/application servers - I believe they work just as well in standalone code too. – trojanfoe Feb 03 '11 at 22:41
  • Correct, but outside of an application server the configuration usually lies inside the application (please prove me wrong). Also there is still the outstanding issue of "other services" (think FTP) – Andrew White Feb 03 '11 at 22:47
  • I'm not sure but I would have thought the configuration is simply 'pointed to' when invoking the pool (there are many implementations). However conceptually this is still inside the application, so it doesn't, perhaps, meet your requirements. As far as 'Other Services' is concerned, I have no idea, sorry. – trojanfoe Feb 03 '11 at 22:53
0

In addition to storing it in a text file outside web root, how about using encryption? With most languages, it's pretty trivial to use an encryption method and, though it might not be strictly necessary to protect from web attacks, it makes it more difficult for another person who may gain access to the file on your system. Additionally, a bit of obfuscation, disguising the file as something else with a boring name that will be likely overlooked, makes it less likely that someone will find it even in the event they have physical access to the server.