将用户ID和密码哈希存储在cookie中以进行自动登录？ vBulletin类型的身份验证是否可以接受？

Question

I'm setting up a user account system on my web site. The SO consensus seem to be reflected in this SO question/article. It recommends this approach by Charles Miller to store the username and a large random number 1) in a cookie and 2) in a separate table in the DB. The user can be reauthenticated in each subsequent session by querying this table using the cookie (if it exists). If a match is found, then a new $_SESSION is set for that session. It supports simultaneous logins from different computers.

My question...

Prior to reading security questions on SO, I was thinking about storing user information in a way similar to the way vBulletin does it. As I understand it, they store the user id and the hashed password in separate cookies on the user's browser.

After the user logs in, they use a $_SESSION variable (e.g. something like $_SESSION['user_hash']) to maintain the authentication for each page request. I don't have access to vBulletin software, but I assume that $_SESSION['user_hash'] is maintained in a separate MySQL table along with another piece of identifying information - e.g. user id/password hash/other - in order to enable logins from different computers.

I was thinking about creating the hash by doing this:

$_SESSION['user_hash'] = $random_hash = sha1(uniqid(rand(), true));

For future sessions, if $_SESSION['user_hash'] does not exist, then those two cookies can be used to auto-login this person for a new session. I would plan on implementing the $_SESSION security measures outlined in this SO question .

Is the vBulletin approach acceptable from a security standpoint? If storing the user id and the hashed password in a cookie is problematic, would encrypting them alleviate some security concerns? Or could something else be done to secure the cookies?

Thanks for any suggestions.

Answer 1

The problem with this approach is that there is far more potential for session hijacking than with a standard session cookie. If I were to steal that cookie, I would potentially be able to access the user's account for as long as they don't change their password. If session authentication uses a session ID that's unique to the session, it's easy enough to set the sessions to time out after a period of inactivity by storing the last activity time in the database.

Another thing is that I would argue you are overcomplicating your own code. You're already using PHP's sessions, which I've always found to work very well, so why not just store the PHP session ID and a link to the user record in the database in your user sessions table? What more do you gain from setting another cookie with your own hash in it? That's why PHP is such a nice language to use because a lot of these high level functions, such has session handling, are already done for you