How should I hide the keystore & trust passwords?

[Lance N.]

We would like to not store the passwords "in the clear" in our configuration files. One way to avoid this is to supply the passwords as system properties, but this places the passwords in the process command line, and is still visible. We encrypt all of our other passwords, S3 keys etc., store those in the config files, then decrypt them at program startup.

I added a hack into the application.run(configuration, environment) method which searches the config tree, finds the password, decrypts it and pokes the clear version. Is there a better way to do this?

[Carlo Barbara]

Similar thread: https://groups.google.com/forum/#!searchin/dropwizard-user/password/dropwizard-user/JwIoX1MIoy0/nS4dTitXhY4J

On Wed, Jan 15, 2014 at 2:08 PM, Lance N. <lance....@gmail.com> wrote:

We would like to not store the passwords "in the clear" in our configuration files. One way to avoid this is to supply the passwords as system properties, but this places the passwords in the process command line, and is still visible. We encrypt all of our other passwords, S3 keys etc., store those in the config files, then decrypt them at program startup.

I added a hack into the application.run(configuration, environment) method which searches the config tree, finds the password, decrypts it and pokes the clear version. Is there a better way to do this?

--
You received this message because you are subscribed to the Google Groups "dropwizard-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dropwizard-us...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Lance N.]

Thank you for your quick response. I did not find that mail. It is easy to add a hack to my own configuration objects where the first getPassword() decrypts and caches. The wrinkle here is doing the same thing for the internal HTTPS ServerFactory: I don't control the HTTPS configuration class.

I looked into using the very recent support for making a subclass of the configuration object creator. For a general-purpose patch I would use that instead, so you can add your own decrypter, etc.

A minor problem is that the DW application has to know about the decrypter. Another option is to deploy the decryptor completely externally to DropWizard. An environment variable is must better than a Java system property.

I know this is bad form, but a system property is in the command line, whereas an environment variable is not. It is very bad to have a password in a process command line: a regular user can see all running programs, but cannot see secure files. One way to do this is to add system environment support to the configuration object creator. 

So, in short, to avoid placing the keystore & trust passwords in the configuration file, the solutions in order of preference are:

1) Application environment variable (need to make a plugin)

2) Decrypter in the app

3) Java system property

I'm using option #2 because of my existing codebase.

Lance

[alexander anguiano]

I wish there is some kind of call back mechanism that would allow you to put you own encryption.  I have been working on trying to find the answer for this  for a while and finally stumble on to the right-ish answer.

The problem is the title of the thread doesn't tell you that it has the solution to the problem.

https://groups.google.com/forum/#!searchin/dropwizard-user/password/dropwizard-user/udpTxNohfxA/UzudAVTRlmMJ

To create the file in your maven project, 

The files goes here

src/main/resources/META-INF/services/io.dropwizard.jetty.ConnectorFactory

see the above thread for the complete details.