Is saving the user ID in COOKIES safe?

Asked

Viewed 1,686 times

4

Guard the ID of the user in Cookies is safe as it is easy to see it from the browser. My questions are as follows::

  • Guard the ID of the user in Cookies is safe?
  • If it’s not safe, what method seguro can use?
  • How can I be using it in PHP?

3 answers

6


Depedende much of the use case

As long as the id is not the user’s unique access criterion on the system, there is no problem. Stack Overflow itself displays the user id in the URL, meaning it is not confidential data. You will only need to take certain security measures if at some point your application needs to pick up the cookie id and send it to the server to fetch some user information.

Case-by-case:

  1. You saved the user id in the cookie on page 1
  2. On page 2 you need to grab the user’s email, then pass the cookie id to the server, requesting the user’s email

If it is to be used in this way, it is extremely insecure, since anyone could change their own cookies to take data from any user of their system. Therefore, you would need one more security factor to ensure that only the user who logged into that machine could be doing a data search.

We will have 2 possible solutions to have a secure system in this case:

  • At the moment the user logs in, create a token and store it attached to the user id in your server database and the client cookie.
  • Save the user id in Session, and when the user requests some information, check if the id that was passed is the same as in Session.

Using one of the 2 measures mentioned above you could safely save and use, not only the id, but several data that is convenient for you to save on the client side of your application.

I recommend that you study whether it is really necessary to use cookies or Session, and how best to use it. Both are connected to your system’s performance and security.

4

Any data entered in a cookie is visible the user (if he knows how to access it, of course), as well as liability to be altered by the user. Thus, whether it is safe or not depends on which consequences of that ID exposure.

Rarely is a user ID secret, so I don’t see much problem with it being read. But if in a particular case this is a problem, it is better not to send it to the user, saving it in the session for example (best option), or alternatively encrypt it before sending (worst option, only use if you have no alternative).

As for being changed, it depends on how it is being used, as already addressed in the other answers. In general, the change can be problematic if it allows a user to impersonate other users. In this case, it is important to avoid this change.

One method, already cited, is the use of a session ID or other random access token, which cannot be "guessed" in practice (recommended, in particular because the vast majority of languages/frameworks support this method, including PHP). Another would be sign the cookie before sending it to the customer (either using digital signature [asymmetric] or, simpler, an HMAC), verifying the signature when you receive it back. This way, the data can still be read by the user, but any change in it would invalidate the signature, causing the cookie to be rejected by the server. This method is useful when you can’t/don’t want to store sessions on the server, but at the same time it is more complex to implement correctly (and easier to make mistakes!), so I leave it as an alternative only.

3

No, it’s not safe

The cookie is a clean text information that is stored in the user’s browser, where there is no control. Not only is it possible to see this data but also easy to change. If your system relies on this field to identify the logged in user, simply change the user id to become another user without going through the password.

Safest method is to save the user id to one session, whose data is stored on the server, away from the possibility of being changed by the user.

For the user goes a session ID, random. And by being random, trying to tamper with this ID will most likely result in an empty session, and therefore useless to a malicious user.

  • I think this varies from the design and the security used in it. What if the user has an authentication token? And if I want to make a system where I have the option of the user staying logged in for a long period of time?

  • See this case for example: http://stackoverflow.com/questions/10957584/stay-logged-in-best-practices-how-does-a-usernamein-the-cookie-make-it-more-se

  • 1

    If a GUID token is good. Hardness is the tokens generated with "homemade" random procedures. To keep the user logged in longer, you still have to tinker with the cookie’s lifespan. So, sessions: 1. Uses a well tested random GUID, already with cookie functionality; 2. Changes the Expires of the standard cookie.

  • Exactly, cookies must always be well planned, they are usually one of the main vulnerabilities of a system currently

Browser other questions tagged

You are not signed in. Login or sign up in order to post.