No need to post the same question in two forums.
I believe that your description is correct except that it misses a key point: To "steal" a session, the thief has to obtain the key.
A session ID isn't a simple "12345," isn't a sequential value, isn't predictable. It looks something like this:
08d461ed174cbe4760b8038dd320d8f3
It's not something you can steal by looking over somebody's shoulder, unless you're some sort of savant. Further, if the key is stored in a cookie and not in a GET url, it's even harder to obtain. (You could do it by spying on the wire with a packet sniffer.)
Sessions are as secure as HTTP can be. If you need even more security, you need to be running SSL (https), which encrypts the data stream between the user and the server.
To your question about how to do it: I give each user an ID that is stored in a database. When you log in, your password is checked; if it's valid, the session is started and the user ID is stored in a session variable. On subsequent pages I check to see whether there is a valid user ID, and if not, I boot the user to the login page.
There's a security hole in that approach, and you already identified it: my user IDs are simple, sequential, and easily faked. To plug that hole, I store another session variable, which is an MD5 cryptographic hash of the user ID concatenated with a secret system passphrase. When I check the user ID, I also check the stored hash (by computing a new one). So long as my system passphrase remains secret -- and in this model it is NEVER sent over the wire -- I have a nearly uncrackable system (so long as the server itself remains secure). This approach was suggested by one of Tim Perdue's columns.
