Datasource password in Application.cfc

Hi Everyone,
'tis me again!

I am trying to transfer everything out the admin gui into Application.cfc and am up to configuring the datasources.

The datasources that ARE defined have conveniently got a section to copy/paste from - so I can steal directly from the admin and paste it into the Application.cfc pseudo-constructor : awesome!

I have noticed that the encrypted password for each of the DNS, is different - despite it actually being the same password for all DSNs.

Which is, initially, fine - I am just copy / pasting - but what happens when I want to add a new one?
How do I create the correct encrypted password?
How do I change / update the DSN array in Application.cfc - when we roll a new password out every XX days for DB user account?

Thanks.

Don’t forget to tell us about your stack!

OS: Ubuntu
Java Version: 11
Tomcat Version: 9
Lucee Version: 5.3.9.141

I am loving CFConfig!

I am not actually sure if your reply was actually for me / this thread or not - or perhaps I wasn;t really clear in what I actually really mean to ask - Which is likely the case!

My database username and password are the same for all datasources.
When I look in Lucee admin, the value of the password is;
encrypted:xxxxxxxxxxxxxxxxx

The ‘xxxxxxxxxxx’ portion is different for all DSs

so it would seem that I just can’t copy/paste the literal string encrypted:xxxxxxxxxx

As an example - if I want to use commandBox’s CFConfig to set the DS password;
box cfconfig mailserver save smtp=myMailServer password=myPlainTextPasswordHere

But what if I don’t want to use a plain-text password in this command?
How do I successfully use;
box cfconfig mailserver save smtp=myMailServer password=encrypted:xxxxxxxxx, instead?

Even if I replace the use of CFConfig - with setting everything in the Application.cfc - I still don’t want my passwords in plain-text.

OR do I just set passwords in environment variables and use them, instead?

Thanks!

Remember this encrypted not hashed. The result of encryption can be different for the same string.

That’s what I would do, and what Brad recommends in the post that Andreas linked to.

is it? it’s reversible, you can’t use a hashed password with a remote service…

OK - Next Question;
Because the system environment is copied to the server scope - does that make this is a security issue for credentials? Or am I overthinking it?

Thanks!

just don’t dump the server scope to end users…

it’s not like you can’t access that scope from lucee via other methods

1 Like

I said it was encrypted, not hashed.

I stand corrected, I obviously need more coffee

1 Like

JDBC drivers requires that the plain text password be passed ‘across the wire’ when connecting to the DB, so therefore Lucee has to store the passwords in a reversible format so the plain text version can be acquired when connecting. The encryption algorithm Lucee uses will create different output every time you encrypt the same plain text password, but they will always decrypt back to the same plain text password even though the encrypted forms differ.

Why not? CFConfig automatically encrypts your password and stores it in your XML config files in the same encrypted:xxxx format. In all reality, CFConfig is no different than you using your admin web UI to create a datasource. You type it plain text, and the admin UI put it in the XML files in the encrypted form. The same is true of CFConfig.

You don’t. I mean, that could be built, but why? Let CFConfig handle the behind-the-scenes encryption that needs to happen to your plain text password before its stored in the Lucee XML config files.

This doesn’t make any sense. Declaring a datasource in your Application.cfc is totally different from declaring your datasource in the Lucee XML config files (whether by CFConfig or by the admin web UI). But regardless, you’re not required to use the plaintext version in your Application.cfc– just use the encrypted:xxx form.

Now that said, you should NOT consider the encrypted:xxx format to be safe. Any hacker worth his salt can easily and quickly retrieve your plaintext password from this. In fact, I have an entire password library on ForgeBox that does just this-- it is what powers CFConfig!
https://www.forgebox.io/view/lucee-password-util

If you are wanting to secure your password, don’t put any version of it in your source code, but instead use something like an environment variable, docker secret, etc to store it and use it as a variable in your CFML code.

This is the most common approach, but it’s worth noting, if a hacker gains access to a production server, it’s not really any harder to look at your env vars than it is to read your Lucee XML config files off disk.

Yes and no. You do need to be aware of the fact that all env vars are int he server scope, but it’s not like it was hard to access them prior anyway. Just a couple lines of CFML creating the java.lang.System class was all it took to get them before. The fact of the matter is there’s really no way to make a secret available to a running server without also having that secret available to hacker which has gained access to the server and can run arbitrary code. So your main goals are to keep the passwords out of source control and, if possible, not written to disk somewhere in an accessible form.

1 Like