(I was surprised that this question wasn\'t asked on Stack for now, but I\'ve done some searching and couldn\'t find anything o.O)
I am working on service-based webapp a
Double hashing doesn't protect you from the exploit. If one takes the stored user id and hashed password from the cookie and send to the server, he would instantly gain access. With session ids, it would at least time out.
Storing the hashed password as a cookie is very nasty vulnerability and is an OWASP Violation. The whole point in hashing a password is you are forcing the attacker to break the hash in order to login. If the attacker can just pull the hash from the database and then login, then you have a system that is equivalent to storing password in plain text.
Every platform has a session handler, in php just use session_start()
and the $_SESSION super global. By writing your own session handler you will be less secure.
By storing a session ID you can identify different sessions of the same user, and you may want to handle them in any special way (e.g. just allow a single session, or have data that's associated with the session instead of to the user).
And you can distinguish easly activity from different sessions, so you can kill a session without having to change your password if you left it open in a computer, and the other sessions won't notice a difference.