Cookies vs. sessions

Question

The concept is storing persistent data across page loads for a web visitor. Cookies store it directly on the client. Sessions use a cookie as a key of sorts, to associate with the data that is stored on the server side.

It is preferred to use sessions because the actual values are hidden from the client, and you control when the data expires and becomes invalid. If it was all based on cookies, a user (or hacker) could manipulate their cookie data and then play requests to your site.

Edit: I don't think there is any advantage to using cookies, other than simplicity. Look at it this way... Does the user have any reason to know their ID#? Typically I would say no, the user has no need for this information. Giving out information should be limited on a need to know basis. What if the user changes his cookie to have a different ID, how will your application respond? It's a security risk.

Before sessions were all the rage, I basically had my own implementation. I stored a unique cookie value on the client, and stored my persistent data in the database along with that cookie value. Then on page requests I matched up those values and had my persistent data without letting the client control what that was.

Basic ideas to distinguish between those two.

Session:

1. UID is stored on server (i.e. server-side)
2. Safer (because of 1)
3. Expiration can not be set, session variables will be expired when users close the browser. (nowadays it is stored for 24 minutes as default in php)

Cookies:

1. UID is stored on web-browser (i.e. client-side)
2. Not very safe, since hackers can reach and get your information (because of 1)
3. Expiration can be set (see setcookies() for more information)

Session is preferred when you need to store short-term information/values, such as variables for calculating, measuring, querying etc.

Cookies is preferred when you need to store long-term information/values, such as user's account (so that even when they shutdown the computer for 2 days, their account will still be logged in). I can't think of many examples for cookies since it isn't adopted in most of the situations.

SESSIONS ENDS WHEN USER CLOSES THEIR BROWSER,

COOKIES END DEPENDING ON THE LIFETIME YOU SET FOR IT. SO THEY CAN LAST FOR YEARS

This is the major difference in your choice,

If you want the id to be remembered for long time, then you need to use cookies; otherwise if you just want the website to recognize the user for this visit only then sessions is the way to go.

Sessions are stored in a file your php server will generate. To remember which file is for which user, php will also set a cookie on the user's browser that holds this session file id so in their next visit php will read this file and reload the session.

Now php by default clears sessions every interval, and also naming convention of session make it auto expire. Also, browsers will not keep the cookie that holds the session id once the browser is closed or the history is cleared.

It's important to note that nowadays browsers also support another kind of storage engines such as LocalStorage, SessionStorage, and other webdb engines that javascript code can use to save data to your computer to remember you. If you open the javascript console inside Facebook, for example, and type "localStorage" you will see all the variables Facebook uses to remember you without cookies.

Short answer

Rules ordered by priority:

• Rule 1. Never trust user input : cookies are not safe. Use sessions for sensitive data.
• Rule 2. If persistent data must remain when the user closes the browser, use cookies.
• Rule 3. If persistent data does not have to remain when the user closes the browser, use sessions.
• Rule 4. Read the detailed answer!

Source : https://www.lucidar.me/en/web-dev/sessions-or-cookies/

---

Detailed answer

Cookies

• Cookies are stored on the client side (in the visitor's browser).
• Cookies are not safe: it's quite easy to read and write cookie contents.
• When using cookies, you have to notify visitors according to european laws (GDPR).
• Expiration can be set, but user or browser can change it.
• Users (or browser) can (be set to) decline the use of cookies.

Sessions

• Sessions are stored on the server side.
• Sessions use cookies (see below).
• Sessions are safer than cookies, but not invulnarable.
• Expiration is set in server configuration (php.ini for example).
• Default expiration time is 24 minutes or when the browser is closed.
• Expiration is reset when the user refreshes or loads a new page.
• Users (or browser) can (be set to) decline the use of cookies, therefore sessions.
• Legally, you also have to notify visitors for the cookie, but the lack of precedent is not clear yet.

The appropriate choice

Sessions use a cookie! Session data is stored on the server side, but a UID is stored on client side in a cookie. It allows the server to match a given user with the right session data. UID is protected and hard to hack, but not invulnarable. For sensitive actions (changing email or resetting password), do not rely on sessions neither cookies : ask for the user password to confirm the action.

Sensitive data should never be stored in cookies (emails, encrypted passwords, personal data ...). Keep in mind the data are stored on a foreign computer, and if the computer is not private (classroom or public computers) someone else can potentially read the cookies content.

Remember-me data must be stored in cookies, otherwise data will be lost when the user closes the browser. However, don't save password or user personal data in the 'remember-me' cookie. Store user data in database and link this data with an encrypted pair of ID / key stored in a cookie.

After considering the previous recommandations, the following question is finally what helps you choosing between cookies and sessions:

Must persistent data remain when the user closes the browser ?

• If the answer is yes, use cookies.
• If the answer is no, use sessions.

when you save the #ID as the cookie to recognize logged in users, you actually are showing data to users that is not related to them. In addition, if a third party tries to set random IDs as cookie data in their browser, they will be able to convince the server that they are a user while they actually are not. That's a lack of security.

You have used cookies, and as you said you have already completed most of the project. besides cookie has the privilege of remaining for a long time, while sessions end more quickly. So sessions are not suitable in this case. In reality many famous and popular websites and services use cookie and you can stay logged-in for a long time. But how can you use their method to create a safer log-in process?

here's the idea: you can help the way you use cookies: If you use random keys instead of IDs to recognize logged-in users, first, you don't leak your primary data to random users, and second, If you consider the Random key large enough, It will be harder for anyone to guess a key or create a random one. for example you can save a 40 length key like this in User's browser: "KUYTYRFU7987gJHFJ543JHBJHCF5645UYTUYJH54657jguthfn" and it will be less likely for anyone to create the exact key and pretend to be someone else.

Actually, session and cookies are not always separate things. Often, but not always, session uses cookies.

There are some good answers to your question in these other questions here. Since your question is specifically about saving the user's IDU (or ID), I don't think it is quite a duplicate of those other questions, but their answers should help you.

cookies vs session

Cache VS Session VS cookies?

What is the difference between a Session and a Cookie?

I personally use both cookies and session.

Cookies only used when user click on "remember me" checkbox. and also cookies are encrypted and data only decrypt on the server. If anyone tries to edit cookies our decrypter able to detect it and refuse the request.

I have seen so many sites where login info are stored in cookies, anyone can just simply change the user's id and username in cookies to access anyone account.

Thanks,