title: Why should I use session id in cookie instead of storing login and (hashed) password in cookie?
body: <p>(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)</p>
  
  <p>I am working on service-based webapp and I wonder what is the best way for handling user logins. So far I have:</p>
  
  <ol>
  <li>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)</li>
  <li>Login and hashed password are stored in cookie with TTL of 15 minutes (revoked every single webaction)</li>
  <li>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)</li>
  <li>User can do at most 3 login attempts per 5 minutes from single IP</li>
  <li>Users get information about last successful and unsuccessful login attempts alongside with date and IP</li>
  </ol>
  
  <p>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?</p>