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!
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.