jSessionID, CFId/CFToken-Which is predictable?

[Jay_B]

I have results from our the new and improved PCI scan and it comes up with one Medium risk vuln.

Description: The remote web application is using predictable cookie-based session IDs. Ideally, session IDs are randomly generated numbers that cannot be guessed by attackers. If the session ID is predictable, an attacker could hijack an active victim's session, allowing the attacker to interact with the server as though they were the victim. If the session ID is used to track the state of authentication, the session ID of an authenticated user could be guessed, bypassing any need for a username or password. In the case of this server, the session ID was found to have an insignificant number of changes between session IDs, which makes guessing very easy.
Remediation: The software needs to be either configured or modified to generate random session IDs.

I currently have enabled
Use J2EE session variables

Assuming I'm getting flagged because of cfid/cftoken predictablility I've setClientCookies = "no" and clientmanagement="no" and restarted the service and everything seems to be working with jsessionids alone... are there any pitfalls to watch out with not using cfid/cftoken?

basic question before I pay for another scan is:

I was under the impression that jsessionids were the most secure and a better alternative than cfid/cftoken. Is that not the case?

EDIT: The scan occurred before I made the client variable changes to the applicaiton.cfm (so I had both jsessionid and cfid/cftoken being set) As of now only jsessionid is being set

[Jay_B]

based on what OWASP has to say

OWASP says

"Best practice calls for J2EE session management. In the event that only ColdFusion session management is available, strong security identifiers must be used. Enable this setting to change the default 8-character CFToken security token string to a UUID. http://www.owasp.org/index.php/Configuration"

It looks like the J2EE sessions are the way to go.

I believe the reason for the PCI flag is that the scan (at least the one from the service we use) was looking at CFID alone. I assume this because cftoken -was- set to use uuid so it should have been secure. The scan probably doesn't know that cfid and cftoken are used in conjunction. So in a way this is a false positive. Based on the new standards coming in it is enough to be out of compliance.

solution to be in compliance is to set clientmanagement="no" and setclientcookies="no" in application.cfm so that cfid and cftoken are not set at all By using only the jsessionid, you are following best practices from OWASP and also get the benefits of session end on browser close

Other thoughts still welcome