Cookie security

[equanimity]

I am using cookies as the basis to extend sessions for my CMS site.
I have the registration/login system written and working, but I seek some opinions on a few things.

First, security.
When the user logs in, their password is stored in MD5 in the cookie. This actually seems like a fairly common practice, but I have read that it is a bad idea.
How much of a security risk is this?

Secondly, I have a rather flighty question about expiration times.
When the user logs in and the cookie is written, I set an expiration time of one week (from the login). Now, I am assuming that this time doesn't change if the cookie is only read (it gets read every time the user loads a dynamic page. This is how the session continues), but I don't want to assume anything.
Other than them logging out and back in (which writes the cookie again) there isn't any reason for that cookie not to expire in one week, correct?

[oesxyl]

I am using cookies as the basis to extend sessions for my CMS site.
I have the registration/login system written and working, but I seek some opinions on a few things.

First, security.
When the user logs in, their password is stored in MD5 in the cookie. This actually seems like a fairly common practice, but I have read that it is a bad idea.
How much of a security risk is this?
huge

Secondly, I have a rather flighty question about expiration times.
When the user logs in and the cookie is written, I set an expiration time of one week (from the login). Now, I am assuming that this time doesn't change if the cookie is only read (it gets read every time the user loads a dynamic page. This is how the session continues), but I don't want to assume anything.
Other than them logging out and back in (which writes the cookie again) there isn't any reason for that cookie not to expire in one week, correct?
cookie have nothing to do with security in my opinion, you can store temporary some user preferences, specific data inside but you must implement security based on something else and avoid to store something sensible for you or your users in cookies.

regards

[equanimity]

I'd like to ask, how do sites that use systems like vBulletin keep you logged in when you come back?
This is what I am trying to achieve.

[CFMaBiSmAd]

You should not store any personal identifying information in a cookie. This includes - user name, password, user id number, database table row number, a static (unchanging) unique id or any hashed (md5/sha1) salted or unsalted version of these. What you should do is generate a unique id for each person (that you regenerate on each page visit so that it is not static) that is stored in the cookie and in the database under that person's id. The reason I suggest not to store a hashed version of any of this is formation is because a hash of a constant value is still a constant. If someone intercepts a value that never changes, they can use it over and over and over again to impersonate the actual visitor.

This unique id identifies the visitor (you match it in the database to get the actual user name, user id number, or table row number) but it is not based on any personal identifying information. It gets regenerated (like you would regenerate a session id when you are using a session to identify a logged in visitor) so that if someone intercepts the value there is only a short time window where they can use it to impersonate the actual visitor.

The above only addresses what you should or should not store in a cookie that is security dependent.

[oesxyl]

I'd like to ask, how do sites that use systems like vBulletin keep you logged in when you come back?
This is what I am trying to achieve.
I don't know vBulletin. usualy the user management and tracking loged user is implemented on the server using a persistent storage like for example a relational database. The external part of tracking and changing information with user can use a session mechanism and/or cookie.
vBulletin for example delete cookies when I close current session and create coockies at login. I guess that use a database for user management.

regards

[equanimity]

Okay, so the idea is to have a table in my DB for sessions, and have the cookie which holds the session ID expire when the user leaves?

If so, that hurts in two ways.
1) It doesn't help me keep users logged in when they leave and come back
2) It adds queries, which is something I have been very very anal about. Under my current setup, a visitor to the site generates zero queries (other than directly called content specific to a called page) and logged in users only generate 3 queries.

[oesxyl]

Okay, so the idea is to have a table in my DB for sessions, and have the cookie which holds the session ID expire when the user leaves?

If so, that hurts in two ways.
1) It doesn't help me keep users logged in when they leave and come back
how cookies keep your user logged in?

2) It adds queries, which is something I have been very very anal about. Under my current setup, a visitor to the site generates zero queries (other than directly called content specific to a called page) and logged in users only generate 3 queries.
yes but your current setup is very vulnerable, so you have a choice between learning to make it safe or not. That's simple.

regards

[equanimity]

how cookies keep your user logged in?

in php, before almost anything else is done, a check is done for a cookie.
If it doesn't exist, they are a visitor (or logged out user). If it exists, I do a query on their user ID and hashed password into the users table to find a match. Because it is a select query, if there is a match (num rows) I stuff the query result into an array. If there is no match, I clear the cookie.

[CFMaBiSmAd]

A session would be used to remember that a visitor is logged in for the duration of one browser session. A cookie would be used to remember that a visitor is logged in for more than one browser session (i.e. a "remember me" function.)

[equanimity]

A session would be used to remember that a visitor is logged in for the duration of one browser session. A cookie would be used to remember that a visitor is logged in for more than one browser session (i.e. a "remember me" function.)

right.... perhaps I mucked things up a bit when I said cookie session. I implied a differentiation from a browser session. To me, a cookie session implies that the user stays logged in until the cookie expires (or the log out).

Oh yeah, I don't have a "remember me" check box. At present, users stay logged in until they log out or cookie expires. I will probably add that.

Anyway, thanks for the opinions and expertise. You have answered clearly.
I am just surprised because I believe that there are systems in use now that store PWs in cookies. Perhaps I was wrong about that.

[equanimity]

You should not store any personal identifying information in a cookie. This includes - user name, password, user id number, database table row number, a static (unchanging) unique id or any hashed (md5/sha1) salted or unsalted version of these. What you should do is generate a unique id for each person (that you regenerate on each page visit so that it is not static) that is stored in the cookie and in the database under that person's id. The reason I suggest not to store a hashed version of any of this is formation is because a hash of a constant value is still a constant. If someone intercepts a value that never changes, they can use it over and over and over again to impersonate the actual visitor.

This unique id identifies the visitor (you match it in the database to get the actual user name, user id number, or table row number) but it is not based on any personal identifying information. It gets regenerated (like you would regenerate a session id when you are using a session to identify a logged in visitor) so that if someone intercepts the value there is only a short time window where they can use it to impersonate the actual visitor.

The above only addresses what you should or should not store in a cookie that is security dependent.

even salted eh?
wow, this sounds like hardline stuff.
What you are asking for is a user table update query every time a page is run.
I was avoiding this, but if it really beefs up security, then I can also use it to update some other values like a last activity time and a last activity page, and allows me to avoid the use of a 'user's online' table in the future.

So, to see if I am clear on this, let me try to regurgitate it.
When a user logs in, a unique session string is created which is written both to that user's record in the user's table and to that user's cookie. Whenever that users loads a page, the cookie transmits the user's session identifier, which is used to authenticate that user by matching that user's ID in the user table to identify the user, and then a new session string is then created to replace the old one, both in the table and in a cookie rewrite.
How do we safeguard from hijacking a cookie though? The only way I can think of is to have the cookie expire on browser exit, but I also wanted to avoid that. :(