Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Where do i store username and userid? sessions or cookie?

Tags:

php

There are many instances in my code where quick access to the logged in username and userid is needed. I currently use cookies. This isn't secure.

I thought sessions would be a solution but sessions expire.

Another option, is to store a unique token in a cookie and then match with a stored token in the database, to retrieve logged in user data. This is the most secure solution but the problem i see with this is, there are many times in my code where the logged in username and userid is needed but querying all the time would use up resources unnecessary(is this true?)

What is the solution?

like image 966
user892134 Avatar asked Jul 18 '12 11:07

user892134


People also ask

Should session ID be stored in cookie?

Session IDs can be stored as cookies locally at the client end. When a request is made to the server, the server transmits the cookie containing the session ID. The server has stored the session ID and associated information from the last session and makes it available to the client if the session ID matches.

Where should you store a session ID?

Session identifiers can be stored in cookies, localStorage, and sessionStorage. Session identifiers can be sent back to the server via cookies, URL params, hidden form fields or a custom header. Additionally, a server can accept session identifiers by multiple means.

Where are cookies and sessions stored?

Cookies and sessions are both vitally important since they record the data that the user has provided for a variety of purposes. Cookies and Sessions are used to store information. Cookies are only stored on the client-side machine, while sessions get stored on the client as well as the server.

Should cookies store usernames?

Usernames are generally safe to be stored as a cookie as long as they are not the only data checked when accessing sensitive areas. Its better practice to store all data in cookies hashed, this will be more secure and safe enough for most applications.


1 Answers

I'm going to try to coalesce everything that's been said in the comments into one answer. As such, please show other helpful users some love by upvoting their answers / comments! I'm also going to give a brief overview of how sessions work, to make the answer useful to a wider audience.

When a user logs into a website, a session is created to identify them. Sessions are handled in PHP by creating a session ID, then associating that ID with a variable store on the server side, which is accessed in PHP scripts using the $_SESSION superglobal. The session ID is stored in a cookie on the client-side, and identifies their session.

In order to remain secure, the session ID must be unique, random and secret. If an attacker guesses your session ID, they can create a cookie on their own computer using that same ID, and take over your session. They'd be logged in as you! This is obviously bad, so PHP uses a strong random number generator to create those session IDs. In order to make things more secure, you can enable SSL site-wide and inform the browser to only ever send the cookie over SSL, using the HTTPS-only flag. This might be overkill for your site, though.

In order to prevent leaked session IDs from being useful forever, or bad guys sneaking into your room after you've gone out to the shop, sessions use timeouts. It is best to have them expire after a reasonably short time - between 10 and 60 minutes depending on your security requirements. You can reset the timeout every time you view the page, so an active user doesn't get logged out.

In order to allow the user to be remembered (i.e. the "remember me" checkbox), you need to provide a cookie that works as an authentication token. Keep in mind that this token is, for all intents and purposes, the same as having your password. This means that if the bad guy steals the cookie, they can log into your account. In order to make this option safe, we can use a one-time token. These tokens should be single-use, random, long and secret. Treat them as if they were passwords!

Here's how to implement them:

  1. Generate a random token. Use /dev/urandom if you can, otherwise you need several hundred values from mt_rand to get something "random" enough, then hash the resulting string with SHA1 to produce the token.
  2. Use a strong password hashing algorithm (e.g. PBKDF2 or bcrypt) to create a hash of the token. Do not use SHA1 or MD5 for this purpose - they are NOT designed for hashing passwords!
  3. Insert the hash into a database table, along with the ID of the user it belongs to and the date it was created.
  4. Set the token in a cookie on the user's side.
  5. When the user visits the site, is not logged in, and a login token cookie is detected, hash the token value from the cookie using the same algorithm you used in step 2, and look it up in the database. If it matches an entry, log the user in as that ID.
  6. Delete the entry from the database and issue a new one (back to step 1).

You should also run a script that looks for very old session tokens (e.g. 3 months or more) and delete them. This will require the user to log in again when they come back after a long period of inactivity.

For a longer explanation of this, and many more important bits of information about secure web form login systems, read The Definitive Guide to Forms-Based Website Authentication and take a look at the OWASP project.

like image 121
Polynomial Avatar answered Sep 24 '22 03:09

Polynomial