Feature request: Make CFID random (and longer). We constantly get false positive flags on PCI scans on our websites because CFID is not random. As a work around, we're using Ben's method here https://www.bennadel.com/blog/785-ask-ben-hiding-encrypting-coldfusion-cfid-and-cftoken-values.htm but it would be nice if CFID could just be random (and longer) to begin with (possibly a second UUID). I would think if CF really needs it to be a sequential value for some reason, then maybe a easy fix would CF server could use the current sequential CFID internally and use a UUID externally for the CFID and just have a internal cross-reference table for the internal vs external one.

Jason this is not the forum to make enhancement requests. This Slack is not owned by Adobe nor is it an official channel for communication/support. Please enter your enhancement request at https://tracker.adobe.com cc: @Charvi for visibility

@Jason Roozee The appropriate response IMO is to explain that the CFID is never used alone, but always in combination with the CFToken, which is highly random and provides sufficient entropy.

Checking "Use UUID for cftoken" in CF Admin Server Settings makes CFToken very random, and like Brad said, CFID should always be used in conjunction with it.

I guess the question I might add is, since using it alone is always an anti-pattern, do we do away with that ability and default to a combined key for CFID instead?

I mean, that's what Railo/Lucee did years ago and it's worked well for them

Since JEEE sessions are more secure, and those sessions persist unless you quit the browser or it times out. do folks do anything when the user logs out of your app to force a new session ID when they log back in?

Are they more secure? In what way?

Right, that's why I'm asking, because invalidateSession() only works with cf sessions.

But you also claimed JEEE sessions are "more secure" and I'm asking for a citation there

https://helpx.adobe.com/coldfusion/kb/difference-coldfusion-j2ee-session-management.html

We recommend using J2EE session management, if:
You want to maximize session security, particularly if you also use client variables

We don't use client variables, so maybe that don't apply, but it is their recommendation.

Yeah, I don't think Adobe's docs make a very compelling case there, lol

Perhaps

I can see an argument for how an ultra-secure app like a banking app may desire to have browser loose the cookies on close, but that's not a behavior endemic to J2EE session cookies. It just so happens to be the default

I read everyone's comments. Thank you everyone for chiming in. 1. @Mark Takata (Adobe): Noted. I figured someone from Adobe would chime in and direct me on where to go. 2. @Dave Merrill Yes, you can set it in CF Admin to make CFTOKEN unique, but NOT CFID. 3. We cannot use J2EE session cookies for our use case and too much legacy code that would need to be updated. J2EE sessions have their pros and cons. 4. @bdw429s I agree it's not really an issue and we can just continue to report them as false positives to our PCI scanner vendors, but that's honestly a real pain in the ass for a dozen different websites and having to redo it every 90 days (they only allow false positives for 90 days). It honestly seems like a easy for to make CFID unique and random and provides a layer of privacy on the client side as well (i.e., currently, if a user starts two separate sessions, they can determine how many new sessions were initiated in between and then can determine how many users are hitting a server)

@Mark Takata (Adobe) Mentioned earlier, but I didn't see an official reply: What java version are we supposed to use to install CF updates? The version CF is currently using, or the version it was installed with? I'd guess we should use the current version, because older versions may not have been kept around, and may contain security vulnerabilities. Please confirm.

You should be on the latest, certified, version.

Thanks Mark.