views:

2200

answers:

3

Hello, I am developing a PHP-based login system. Each user has an ID(a number) and a password, which is stored as a salted hash.

I am able to figure out if a login is sucessful or not, but now I need to store that information somewhere(so that the user is not permanently logged out).

In the past, I've played with $_SESSION variables. However, these seem to be deleted when the user leaves the browser, which is undesired. Also, I can not "assume" that the user won't try to trick the system, so it has to be safe.

So, here are my questions:

  1. Should I use $_SESSION or $_COOKIE? What are the main advantages of each of these approaches?
  2. How to implement a 'Remember me' checkbox?
  3. Which information should be stored in the session/cookie variable?

Note that no database security issues are being taken in consideration in this particular question.

Regarding number 3, what I mean exactly is:

  • Should I store the ID and the hashed password of the user in the cookie/session, or
  • Should I store the ID and the non-hashed password of the user in the cookie/session, or
  • Should I store a "SessionID" and the password(hashed or non-hashed?) or
  • Should I store a "SessionID", the "ID" and the password(once again, hashed or non-hashed)?

I want to keep my website as safe but efficient and user-friendly as possible. If a SessionID-based approach is taken, I'd also appreciate some explanation regarding how to store it in the database.

Thank you in advance

EDIT: Eran's and Brian's answers combined seem to be what I need. Unfortunately, I can only mark one of them as accepted. I'll try to go ahead and implement to see which one was more useful.

+4  A: 

For sensitive information (ie, authentication results) use only sessions. Sessions are stored server side and are much less likely to be compromised.

Regarding session lifetime, the default is the lifetime of the browser session - but you can control that. There are several settings that affect that:

session.gc_maxlifetime - effectively controls the lifetime of the session.

session.gc_probability and session.gc_divisor together determine how often session garbage collection will take place.

And last - session.cookie_lifetime controls the lifetime of the session cookie (the cookie that holds the session id so it doesn't have to be tranmistted over the URL). It should match the value of the session.gc_maxlifetime.

Also, never store passwords in sessions or cookies (even in hashed format). Just the results of the authentication.

Eran Galperin
+3  A: 

I want to reiterate Eran's point never store the users password or even a hash of the password in session or cookie data.

In general I've implemented the remember me functionality in web apps using Cookies. A good place to start for information on building a "secure" persistent login system is this blog post on the fishbowl.

If you need to have ensure that the login is secure you have to use https. This is because cookies or sessions can be stolen if they aren't encrypted.

Another good practice to follow is the 2-level login system. You can see this at sites like Amazon, where you can add things to your cart without logging in but if you want to checkout or edit your account in some fashion you have to enter your password again.

Brian Fisher
This followup article takes that to the next level: http://jaspan.com/improved_persistent_login_cookie_best_practice
jmucchiello
A: 

Store the ID in $_SESSION but don't store the hashed or non-hashed password. Once the user has logged in and the ID is saved in $_SESSION, you don't need the password any more.

Stacey Richards