1. script for login process is located on a SSL-enabled server, so usernames and passwords are encrypted.
https:// is an envelope encryption, so POST data, which is a part of the packet data, not packet headers, is encrypted. As long as you POST or COOKIE data that needs encryption, you're fine. GET is not secure.
2. upon successful login, user is relocated to a non-SSL-enabled server which hosts the scripts that contain the authenticated-user-only features.
If this is what you're doing (header() or a meta-refresh html tag).
So, while usernames and passwords are protected by SSL, the PHPSESSID is not. In other words, anyone who captures that HTTP GET packet can get the session ID. Is that true?
There are a few different attack vectors with SESSION data. Needless to say, never store or authenticate by a PHP SESSION id only; use cookies or encrypt a page with script and include() the content per page, and force users to login every page change.
Another question is while that session ID is valid only before an unset() and a session_destroy(). So the attacker who has the session ID must fake the session before the real user logout. Is that true?
Before the session is destroyed and the temp file where it is stored is deleted from the harddrive. Do not store sensitive information or use a SESSION id to authenticate a user. -- Jared Farrish Intermediate Web Developer Denton, Tx Abraham Maslow: "If the only tool you have is a hammer, you tend to see every problem as a nail." $$
