Why should I use session id in cookie instead of s

问题:

(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 and I wonder what is the best way for handling user logins. So far I have:

1. When user login in, they supply creditials. Password is salted and hashed locally, than it's transmit to server over POST (so sniffing users won't be able to retrieve original password ie. to check them on the other sites)
2. Login and hashed password are stored in cookie with TTL of 15 minutes (revoked every single webaction)
3. Passwod is server-side salted and hashed again, and than it's compared with password stored in database (so, passwords are double hashed with different salts, this is for someone who'll break into database - they still won't be able to recover login creditionals)
4. User can do at most 3 login attempts per 5 minutes from single IP
5. Users get information about last successful and unsuccessful login attempts alongside with date and IP

Someone had noted that it's better to store unique session id instead of hashed password in cookie and I wonder why it is so important - if someone sniff packets, than it's no matter session id or not - they still can get packet from login with all data needed to pose as legitimate users and login themselves. So are there any other advantages of stored session-id approach over storing login and hashed-password in cookie appraoach?

回答1:

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.

回答2:

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.

回答3:

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.