just noticed that Adobe released a security update today for CF2021 and 23: https://helpx.adobe.com/coldfusion/kb/coldfusion-2021-updates.html anyone tried it yet?

Am I confused, it says

release date, March 12, 2024.

This is June, right?

it's showing june 11 for me...

ColdFusion (2021 release) Update 14 (release date, June 11, 2024)

I should know more tomorrow when DevOps updates our dev server to try it out.

I'm not certain if it's related, but I know for the last update I had to (and thus just did it out of repetition for today's) add an argument to the java call

-Djdk.util.zip.disableZip64ExtraFieldValidation=true

to get around some issue with the install. I can't remember if it was that error or not though.

I think it is. I just backed out my update 13 install to get to a good state, and I'm about to try the 14 install with that argument.

Doh, my bad, I clicked the obvious link in CF admin, which is to the currently installed version, not the newly offered one. I know this, just spaced, other things on my mind. As you were.

Yeah, that's a dumb default...

So, has anyone else done this update yet? Outside of the above about

Djdk.util.zip.disableZip64ExtraFieldValidation=true

, has anyone seen any issues?

I haven't run into any

Please read details, this update has a potential breaking change to encryption

@Mark Takata (Adobe) and all: Many systems don't store actual passwords, but the hash of the user's password, possibly w a random salt. In that case, if we want to use a better hashing algorithm, how can we update the db? Only thing I can think of would be to update the code to a newer algorithm, then force everyone to change their passwords. Am I missing something?

is it just CFMX_COMPAT (which is the current default algorithm of a hash) that's changed?

Even CFMX_COMPAT isn't going away or changing, it just won't be the default any more, right? But if CFMX_COMPAT is so much less secure, devs would want not to have it used to hash (for instance) passwords, and my question stands, how to get out of that box. (I thikn we're not using it, but the question is real for those whoe are.)

Yeah - hash is one way so you can't go back. The example on the release note is not great as noone should be using two way encryption for passwords - it's much better to use one way encryption for passwords so that devs / dbas / db hackers can't ever decrypt it to get the password as that would not be very secure!

The way I have handled this before is to add a bit field to the membership table like isHashBcrypt (bit, not null, default 0), and then when a user logs in as part of their password check if this bit is zero, check with the old algorithm, and if valid, re-hash using the new one, replace the hash in the database, and then set the bit to 1 so the next time they log in we know to check using the newer algorithm. This makes it seamless for the users and allows the system to quietly update to using a new system in the background. This would also be applied to a password change or reset process so any new passwords coming in get hashed with the new system while older ones continue to work. If you eventually want to purge the old hashes then send emails to users who still have old hashes and tell them their password is expired and they need to set a new one. After a few months of sending those, lock out any accounts that haven't updated or force a reset link to be sent if they try to log in and force a new password for them at that time.

yeah - that's my 'c' but described much better 😄

Agree with storing a passwordVersion column, couldn't think of any better way. And eventually you are going to need to lock out anyone with old versions, which you could do by just clearing out their hash, which you'd want to do for security anyway.

back to the original question - we did update our dev server yesterday and the install was smooth, and so far no code changes have been identified. we do use "hash" and "encrypt" but were already manually setting the type of encryption to something else.

Our issues so far are that hashes (used for caching) stored in the database are longer so we get SQL errors.