Googled this a bit but didn't find anything. One c...
# lucee
a
Googled this a bit but didn't find anything. One can set the initial Lucee admin password via
lucee-server/context/password.txt
. We're currently using a plain-text value here, which is a bit of a security shortcoming, and was wondering if one can provide the hash of the pwd instead of the clear-text one somehow? Tangentially related, it's not uncommon for Docker images to support environment variables for this sort of thing (eg https://hub.docker.com/_/mysql, and scroll down to "Environment Variables"). The Lucee image page on Dockerhub doesn't mention anything like this, but wondering if there's anything that's just not documented..? (NB: this is specifically a Lucee question, and nowt to do with how CommandBox might do its own thing even betterer)
e
if someone has already compromised the server to the point where they are able to remove or edit the server.xml, they already have sufficient access to do whatever the hell they would like to the server. The only difference between Lucee doing a password reset and AFC is that AFC scripted out "ColdFusionHome" to a bash and bat script which references their password reset jar. Their jar just prompts someone to input something as a password (from what i have observed) and then encodes it. Lucee being open source, if you like the way afc handles their password reset, then submit a solution, am sure it would not only be welcomed but would make headlines as in Coldfusion circles, you're kind of a big deal.
t
@Adam Cameron this might make you shudder but in my docker start up script I take the password from an env var hash it and write it to the lucee configs before starting lucee horrible but it works
⭐ 1
b
@Adam Cameron If you are using CommandBox/CFConfig, yes.
Copy code
CFCONFIG_HSPW=<hashhere>
@thisOldDave Sounds like you could use some CFConfig too šŸ™‚
@Evil Ware FWIW, I'm pretty sure the pass reset script in ACF just puts the plaintext password in the
cfusion/lib/password.properties
file and sets the
encrypted=false
flag which means it doesn't get encrypted until ACF starts the first time. So it's really not much different than Lucee's
password.txt
approach outside of Lucee involving two different files.
šŸ‘ 1
As far as Adam's original question-- if he wants to do this outside of CommandBox/CFConfig, he has two options really. • create password.txt file • warmup server by starting/stopping it • The warmup will hash the password and place it in the lucee-server.xml file and delete the password.txt • Do this as part of his image build Or the other option would basically be for him to re-create what CFConfig does from scratch • Grab my lucee-password-util library from ForgeBox which contains the logic to hash a password to Lucee's format • Create a manual step to hash a plain text password and place the password and the salt used in the hash into the Lucee-server.xml file directly. • This basically requires the ability to run CFML in the container, so it's not very easy outside of CommandBox unless you can somehow create a bash equivalent of the hashing algorithm and XML parsing (yuck) Or honestly, I guess there's a third option • create the hash/salt somewhere outside of the container in a manner that is convenient for him • Replace the salt and hash values directly in the XML file as part of the docker build, which could be done wish
sed
pretty easily.
šŸ‘ 1
⭐ 1
Here's that password util which powers CFConfig to save someone the forgebox search https://www.forgebox.io/view/lucee-password-util
a
Cheers for that @bdw429s. As always you are a star. Dealing with in manually is not too arduous, was just making sure that there wasn't an inbuilt way of doing it before investing my time. Realistically we can just pass the value in as an environment variable from the host system and echo that to the pwd file etc. That's be fine, and enough separation of concerns to keep regulatory bods happy. I could have sworn I'd seen somewhere in Lucee (or poss CF...) Admin for generating a hash of a password so as to not expose the actual pwd in source code / config code somewhere. So was hoping I was vaguely remembering the functionality I was asking about. Thinking now it mighta been something to do with DSN passwords somewhere...
b
You're probably thinking of the datasource passwords-- which are encrypted, not hashed. And, FWIW, the lucee password util will do those as well, šŸ˜†
When you edit an existing datasource and scroll to the bottom they have the application.cfc format for the datasource with the pass in the
encrypted:xxxx
format
āœ… 1
e
@bdw429s I'm sure there is encryption at the password level as ACF is cleared at the US DoD level to operate items, and all passwords require at least FIPS2 compliance or better. Really a minor technical difference, as if the server is compromised it really wouldn't matter but the input while the server is live, vs input while the server is in a warm state. The devil is in the details.
a
Yeah @bdw429s that's exactly what I was (partially) recalling. Cheers.
b
What I was saying is the password.properties file in ACF allows the password to be set in either plain text OR hashed. If it is in plain text, the server will hash it when it first starts. The algorithms and DoD standards in use when the hashing finally occurs is really irrelevant. I was simply pointing out that the password reset batch file still ends up doing the same basic thing as Lucee does at the end of the day. It has the plain text password living on disk for a period of time.
a
@Evil Ware none of this is a concern about servers being compromised. It's just about separation of concerns. It's also largely a regulatory box-ticking exercise in this case šŸ˜‰
e
I am not disagreeing with it does the same thing, Hell lucee does many things simply faster. šŸ™‚
b
I just confirmed this by using the password reset script on a local 2021 server. I entered
test
into the command prompt as my new password and here is the changes it made to my
password.properties
file:
Copy code
rdspassword=test
password=test
encrypted=false
t
@bdw429s its in a multi stage build it is fully CFConfiged in the first stage and then I have a task runner that replaces the build hspwd and salt with ${} before it is copied to the final stage, I then use envsubst to copy vault secrets into the templated files. so it is command boxed up to the hilt until it is deployed for a client
b
Yeah, once you finalize the image, you lose all the fun CFConfig abilities on further starts. What's baked in is there for good unless you manually start replacing it. This is where it would be nice if Lucee had proper first-class support for env vars for these sort of things as it's sort of a catch 22,
I have a client who really wanted to re-use the same docker images across dev/stage/prod and wanted to be able to control anything at start with env vars, so they just decided to not finalize their images and lived with larger images that booted slower in favor of having full flexibility every start.
t
yes it was a pain but I have moved all of the configuration into yaml files that are built from vault secrets and then loaded in Application.cfc
It was a useful exercise in cruft removal if nothing else
šŸ‘ 1
b
An interesting thing to note here, not that it really applies to what you did, is that
${}
system setting expansions that CommandBox/CFConfig does in JSON files can be extended by modules at runtime so you could conceivlablty do this
Copy code
{
  "someSetting": "${myVault.someKey}"
}
And then have a custom module that hit your special vault storage to resolve that key.
My goal was to write some modules to integrate with common vaults or AWS secrets to allow people stuck with fancy enterprise secret vaults to easily use them in their config, I just haven't had the chance.
t
yes I use that in some task runners for the local development envs to get connection strings and auth tokens it works well but Devops use jinja2 and cant be persuaded otherwise
šŸ‘ 1
e
@carehart actually blogged about the whole password cluster a while ago. https://www.carehart.org/blog/client/index.cfm/2020/7/14/why_secure_car_files
c
@Evil Ware well, that was of course only about car files, which are not really in discussion here. But the point was that while the passwords are indeed encrypted in the car (like Brad noted is true of dsn pwds and others in the neo*.xml files), the decryption key is (must be) provided in the car as well. That's needed to import the car into another cf instance (or container, as ACF images support auto-import of car's, if placed in a specific folder at container start).
šŸ‘ 1
And while we're on this whole matter Adam raised, it may be of interest to some (tracking dfferences) that the json created by the cfsetup tool (new to cf2021) DOES store cf pwds as encrypted in the json file, where cfconfig leaves them plain text. I know Brad has his reasons why that's optimal and acceptable, and it relates to points made earlier in this thread. Again, just observing the difference in approaches, which each have pros and cons (that we need not debate here).
b
For datasource passwords, correct. For admin UI logins, CFConfig will export the salted hash into the JSON.
c
Good point to add in distinction. Thx
g
I have read the thread, and I am understanding the use-case issue is the storing of a password as plain text, "somewhere on disk" for a period, however short... and that's not optimal. What I am unclear about is - "let's assume we're starting from the beginning, with enough time and resources" : is there even a solution? Thanks.
t
to be honest once you have worked out that the Railo/Lucee database password encryption was created by a left handed touch typist how you store them becomes mute
a
a left handed touch typist
Now see that sounds like some sort on onanistic euphemism to me.
t
The salt is sdf repeated a couple of times
b
storing of a password as plain text, "somewhere on disk" for a period, however short... and that's not optimal.
@gavinbaumanis If this were to happen only as part of the Docker build process, I wouldn't think it too serious. Ideally, you wouldn't leave the plain text passwords laying around your built docker images since it increases the likelihood of them being discovered. I have clients who prefer to not even leave the encrypted DS passwords inside their docker images. It really depends on what your comfort level is and how large of an infosec team is breathing down your neck. As far as the solutions, I think we covered and re-covered them above.
e
If you want it secure, don't allow it online or inside any network physically connected to the internet in any fashion.