J2EE session variables & Non Random Session IDs

Question

Our server keeps failing our PCI compliance test due to the Session ID's being non random.
Description: Web Server Uses Non Random Session IDs       Synopsis: The remote web server generates predictable session IDs.      Impact: The remote web server generates a session ID for each connection.  A session ID is typically used to keep track of the actions of a user while he visits a web site.  The remote server generates non-random session IDs.  An attacker might use this flaw to guess the session IDs of other users and therefore steal their session.  See also : http://pdos.csail.mit.edu/cookies/seq_sessionid.html        Data Received: Sending several requests gives us the following session IDs : CFID=896744 CFID=896745 CFID=896746 CFID=896747 CFID=896748      Resolution: Configure the remote site and CGIs so as to use random session IDs.       Risk Factor: Medium/ CVSS2 Base Score: 6.4       AV:N/AC:L/Au:N/C:P/I:P/A:N
We are using J2EE session variables which I though was the more secure option. Is there something else you have to do to guarentee that the Session ID's are non random or is this the Compliance test picking up on a false positive?
P.S. It's a recent migration to CF10, don't know if that has anything to do with it.

Answer 1

Personally, I use the client scope instead of the session scope so that I don't have to worry about sticky sessions.  That has always worked out nicely for me.
I read that article you referenced, and it's got some interesting stuff.  In particular, I have seen the client scope database tables not purge as they're supposed to.  And the stuff about preparing, executing, and then unpreparing SQL statements on each request is alarming, if true.
However, I have to say that I have never, ever, ever, ever had performance issues due to client variables.  Not once.  Whatever performance hit my application may incur from using client variables has, to this point, been completely dwarfed by the performance of the application itself.  And, c'mon, the stuff about being lazy because you don't want to spend precious engineering time worrying about something like session management (which is never going to add value to your product) rather than coding something actually useful to your end users...that seems overly harsh to me.
I completely agree that storing client vars in the Windows Registry is bananas, as is the defualt 90 day purge limit (though as of CF 9.0.whatever, the default is 1 day, 7 hours, so clearly they've made some changes since this article was written).  But I'm loathe to throw away client-based management.
I think, getting back to the issue at hand, that this may be a false positive.  CFID is sequential, but CFTOKEN is not; that should really be the end of the story.  I'll see if McAfee will listen.  (-;