how to encrypt the db password in application.conf file

[isterM]

Hi,
I'm facing an issue with the db password which is written in clear in
application.conf file
Does someone have an idea to obfuscate/encrypt this db password ?

Thanks

[green]

Does it really need to encrypt db password in application.conf which is supposed only visible to system admin in the production environment ?

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.

[GrailsDeveloper]

You can store it encrpted in the file and use
http://www.playframework.org/documentation/api/1.1.1/play/PlayPlugin.html#onConfigurationRead()
to decrypt it. The problem is that you need a dialog at startup-time
to get the password, which is an very unusual behavior for a web-
server.

Niels

On 8 Feb., 23:59, green <greenlaw...@gmail.com> wrote:
> Does it really need to encrypt db password in application.conf which is
> supposed only visible to system admin in the production environment ?
>

[Pascal Voitot Dev]

I don't know any server that encrypt the DB password in its config...
don't bring much more security IMO... If one can see your application.conf, it means it can see lots of other more interesting things in your system!

;)
Pascal

[Manuel Bernhardt]

Also, there's a difference between seeing the password and being able
to use it. Usually you tie the db user to localhost to avoid external
access in any case, and generate some weird random long password for
the user.

What would be interesting and think has been reported earlier on
already, would be an option to tell Play! to use an alternative
configuration file, both when being run via "play run" and when being
deployed as a WAR.

Some ideas that come in my mind:
- a JVM arg for WAR deployment, and another way of passing an option
in the command line when running "play run"
- a redirect in the default application.conf: in the first line you'd have e.g.

prod.configuration=/some/file/some/where.conf

(note that then only the production configuration is redirected, not
the dev one)

[grandfatha]

I guess there are databases out there that store personal data/
critical business data that shouldnt be open to every developer of an
organization. Thats why the credentials are not allowed to be stored
in SCM for everyone to see. What if 'the new guy' creates a CD of your
business secrets, quits the job and sells it to your competitor?

[grandfatha]

> prod.configuration=/some/file/some/where.conf

To remain DRY this file should be merged onto the default conf file by
Play. This way most settings could stay in application.conf and the
secret stuff would be in the prod.conf, which would get merged onto
the default settings at bootstrap. Should be doable in a plugin,
though.

[Manuel Bernhardt]

But will "the new guy" get an access on a production database machine?
I would think that if you start having sensitive data in your
database, you wouldn't give away this kind of user privileges to
everyone, with or without passwords stored in plaintext for everyone
to see. And without connecting to the database machine, you have not
much of a chance to login to the db console and do evil data theft
things.

(not that it doesn't happen though, witnessed it at one of my former's
employers - though it was not a developer stealing data from the
database somewhere on a terminal late at night, but a sales dude who
got laid off and took all the big juicy client contacts with him right
before being kicked out, by comfortably using the company-wide CRM UI)

my point is: security usually involves more than just encrypting
passwords and you shouldn't rely on a framework to provide "The
Solution"

[Pascal Voitot Dev]

On Wed, Feb 9, 2011 at 9:34 AM, Manuel Bernhardt <bernhard...@gmail.com> wrote:

On Wed, Feb 9, 2011 at 9:10 AM, grandfatha <dki...@googlemail.com> wrote:
> I guess there are databases out there that store personal data/
> critical business data that shouldnt be open to every developer of an
> organization. Thats why the credentials are not allowed to be stored
> in SCM for everyone to see. What if 'the new guy' creates a CD of your
> business secrets, quits the job and sells it to your competitor?

But will "the new guy" get an access on a production database machine?
I would think that if you start having sensitive data in your
database, you wouldn't give away this kind of user privileges to
everyone, with or without passwords stored in plaintext for everyone
to see. And without connecting to the database machine, you have not
much of a chance to login to the db console and do evil data theft
things.

(not that it doesn't happen though, witnessed it at one of my former's
employers - though it was not a developer stealing data from the
database somewhere on a terminal late at night, but a sales dude who
got laid off and took all the big juicy client contacts with him right
before being kicked out, by comfortably using the company-wide CRM UI)

my point is: security usually involves more than just encrypting
passwords and you shouldn't rely on a framework to provide "The
Solution"

you're absolutely right!
security is not only a mechanism of encryption or an algorithm, it is an infrastructure, some processes, lots of human interactions and discipline.
You want to encrypt your password in a configuration file.
So where is done the decryption? (in the application itself?)
where is stored the encryption key?
is this storage place protected also? (you can just move the problem of protection from one place to another in this way)
how do you create and put this encryption key there?
who generates the encryption key?
who is responsible if the secret is endangered?
how do you change the key if it is endangered?
etc...
at the end, it often appears that it's more expensive to set a security policy than protecting the computer itself :)

but once again, I can imagine some usecases where encrypting a password in a conf file could be useful. But if someone who is untrusted can read your config file, it's generally too late: your security has been breached and your data are no more protected anyway!

Pascal
 

[GrailsDeveloper]

Just to give you an real-live example. A web-app which run on a school-
server for intranet usage. All files are there generally not really
protected. I used h2 with crypted database. The passwords to encrypt
will asked at start time. Not nice, not a solution I would provide for
a big company, but a solution for a small customer.
So I think it's better to show a solution, perhaps with a hint that it
doesn't seems to be a clever way, than to discuss if it is correct
requirement.

Niels

On 9 Feb., 10:50, Pascal Voitot Dev <pascal.voitot....@gmail.com>
wrote:
> On Wed, Feb 9, 2011 at 9:34 AM, Manuel Bernhardt <bernhardt.man...@gmail.com
>
>
>
> > wrote:

[David González]

Well, why I wouldn't do this and I know you want to protect the data of your client etc etc how about this

http://www2.playframework.org/documentation/api/1.1.1/play/libs/Crypto.html

1. generate the AES string creating a generator etc etc

2. modify the moment Play! tries to connect using the credentials (look at JPA stuff in play methinks), recompile

3. decrypt the AES string you generated so play don't throw any errors, recompile

4. store the private key in a protected variable to decrypt, recompile?

5. ??

Well, that's the best I could come up, I agree with most of the comments here although for me it looks more like a "how to organize" question. 

my 2cents :) 

Best wishes,

David

[Pascal Voitot Dev]

yes in this case, it is the simplest solution I know...
at the server start, you ask the passphrase to launch the server...

[grandfatha]

> But will "the new guy" get an access on a production database machine?

Nope. That was the point of my post. Currently with Play you have no
other choice then to put it into a place where everyone can see it.

[Olivier Refalo]

Sounds like an issue common to any project, not especially Play.