If you're worried about someone listening over the line that could hijack session tokens, SSL is really the only solution to this, whether the token changes or stays constant.

I guess even SSL would not be of much help. HTTP snooping is not the only way a attacker could obtain the session ID. Sometimes an attacker could use other vulnerabilities in the system / domain pages and obtain the session ID of the user. E.g. If in case there is XSS in some Mantis page or page in the same domain (where Mantis is installed); attacker could easily obtain the session ID of the user and impersonate him / her.

Also, in this particular case, session ID snooping has larger implication - since it is non random and it directly makes the requirement of a username and password redundant.

@pklanka: I added HttpOnly cookie security in 1.2.0 which is a security feature now supported by all the major browsers that I'm aware of. This feature prevents sensitive cookies like the session IDs being read from within JavaScript code running on the site.

I do agree we need to rotate session IDs between multiple user logins. I thought we would have been doing this already with the PHP session cookies. In other words, I think MantisBT uses both PHP and custom session IDs. I've never looked into this area a great deal so I'll try to investigate it further.

@jreese, do you know how MantisBT treats PHP vs MantisBT session IDs?