Ok, let's get rid of the fear-tactics being used in this topic ok? There is no inherent security risk in the way the ACP is managed now. As someone else already pointed out, it has been this way since 1.3, and I assure you - if there was a problem, it would be found and fixed by now.
Using a cookie to validate the session proved LESS secure. If an XSS attack somehow gets through, an attacker can then just fix their cookie and reach your ACP.
Presently, a secure session id is used, which of course can't be known unless you share it remotely with a user. We mitigate any links to external resources through the ACP (i.e. if you view a member who links to an offsite avatar, you actually go through a special local script on the public side that looks up the avatar, to try to prevent you referrer URL being passed), though it's not always 100% possible to stop this. For this reason, we also by default match your IP address. Unless you actually go edit a file to disable this, you're fine.
On a local environment where everyone's IP address is the same, you have bigger issues (as in no one can use the site). That's what the "Match x-forwarded-for" setting is for, at which point your IP addresses are no longer the same, and the ACP then does not suffer from the issue Wolfie is suggesting.
Why "would it be nice if there was something that would help to make it a little bit tighter"? Can I ask you this - how many times has your ACP been hacked through someone getting your ACP session ID? If it's 0, then why does it need to be tighter?
Let's worry about real issues here, instead of non-issues. :) This, I'd say, is presently a non-issue.