Store username in cookie for a web site

Question

I want to store the username for a web site in the coockie, is it secure? What an hacker can do with this info?

Answer 1

This entirely depends on what you are doing with the username stored in the cookie. If you are automatically trusting that the username that is provided by the cookie is valid, then you are effectively inviting impersonation of users by hackers.

If, on the other hand, you are simply storing the username so that they can automatically have the username filled in the next time they go to login, it is perfectly fine since a username is not secret information.

If, for some reason, you needed to use a cookie to store authentication, the preferred approach is to use a randomly generated session identifier that is tracked on the server and can be expired.

If server side storage is not available, the server can encrypt the username and an expiration date (and optionally an IP from which they connected) with a symmetric key (like AES) and then pass that encrypted value to the cookie. The server can then verify the cookie later without an attacker being able to alter it. The main drawback to this approach is that once a cookie is issued, it can't be invalidated if the user wants to log out all their sessions (because, say, their computer was stolen.)

Answer 2

I guess the question is why would you do this?

If you're storing the username in a cookie to bypass a step where you would pull that information from the database then you are leaving yourself open to risks if you blindly trust the user to be themselves.

Anything that is in a cookie form is

1. readable by the user
2. can be manipulated by the user

Variables that the user has the ability to modify should not be trusted EVER whether they are stored in the browser (Cookies), submitted by the user through a form (POST or GET variable), or if they are able to be manipulated in the address bar (GET variables).

If you are storing cookies (as some sites do) to remember a user when they return, then you need to hash the variable with a salt and pass that hashed salted variable (with something like a timestamp and something know to you like a private key all hashed together). This makes it much harder for the attacker to get a false positive on cookie manipulation because they would need to have access to the code and present the exact timestamp in order to have a match in the database( see below).

About SESSIONS

Some implementations of SESSIONS in programming languages like PHP will by default store SESSION variables in cookies. Therefore any information that you would not want the user to see should also not be store as a session variable without being hashed or encoded in some form or fashion because it, by default in some languages is transmitted to the browser and provides any would-be attacker information about the way (naming convention and structure) you store your variables.

Provided you're expecting them to only log in from one machine, a good practice would be to:

1. Save the hashed salted one-time variable in a relational table in the database along with a user specific match (such as an ID), AND a timestamp. There needs to be only variable in this table stored per user. This will act as the last visit to the site from this browser. Sessions last as long as the session timeouts allow. This exists only for the last page of their last session and can exist on the page where their session was terminated by them (let's say they log out). If you choose to revive their last session(provided they didn't log out), store the session_ID in the relational table along with this one-time variable since anyone who is packet sifting their traffic likely has their session_id already. They would have to know this one-time key for the user for the site was what was required to make it slightly easier on returning.
2. Upon retrieval of the stored cookie, clean it (strip tags, quotes, anything to be used as an injection attack), check it to make sure it conforms to the expected format (if you're expecting an MD5 hash, don't accept a number, don't accept SHA, etc.)
3. Run a cross check query on the database that checks for a count of 1 for the now cleaned variable in comparison to an existing record in your relational table.
4. IF you've received your count of 1, THEN perform a clean query on the database to pull more information about the user because now the user would be *trusted* or at the very least the variable was at one time in use in your system. If you receive a count of 0 this means it's non-existent and not trusted. If you receive a count of more than one, this means that you're not storing the hashes correctly in the database as every new session should have its own special hash.

If the time is greater than some longer timeframe (1 month for example), then make them provide all credentials as not-recognized. This is an executive decision in relation to User Experience.

If a session has expired make the user reauthenticate. If it's not expired the user should still be logged in unless you have an event in place that kills a user's session after a set amount of inactivity (which means the session *should* not still be active).

At the point the non-logged-in user is recognized, then present them with a challenge and response known to them to verify that it's not someone at their terminal. Do not provide them with any information that can be used against their account in the event their machine has been compromised.

NEVER print anything to the screen directly, write it to a database, or write it to disk from a user without cleaning it. Even secure backend LAN-only intranet websites have the potential to be exploited.

Answer 3

Do not store information like this in a cookie. Use the server's session cache (i.e $_SESSION) for information like this. Cookies can easily be spoofed and the last thing you want is a user impersonating someone else simply by changing a cookie!

Answer 4

I want to store the username for a web site in the cookie, is it secure?

No. If you store information on a users computer, where you have no control over it, it is not secure. That user or anybody else with access to that computer can change the contents of that cookie.

Note that you can encrypt the information before you store it in a cookie, and that you always should validate user input. Even if you previously validated it before storing it on the users computer.

Basically: Never trust user input.

What an hacker can do with this info?

If the data in the cookie is not encrypted and verified the attacker can try so called xss attacks. E.g. you read (what you expect to be) the username from the cookie and sent it back to the user.

E.g.

  Users computer                   Your server

read username from cookie   ----   
                                   Information accepted at the server


                                   Display a greeting without verifying the contents
"Hello Jane. Welcome back!"  -----

With no verification the the return could be a simple:
"Hello" + name_from-cookie +. Welcome back!"

Now imagine someone changing the cookie to "Jane. some command "

The users browser, already in communication with your trusted web server, would try to display this and would try to render the contents of some command.

Now this is just one example where you can say 'but if someone could hack their cookie to do that they could also have done worse things'. This is true. But it is just one flaw which I think I could easily explain. They could do much worse things.

Answer 5

Get usernames from users by using other attacks. All that cookies are are stored information. When cookie stealing can be done you are already in trouble as PHP etc store the session id in a cookie.

Cookies are untrusted information, thus never trust the data and sanatise them.

Also when you do something like: You are logged in as "'.$SESSION['username'].' I hope you dont have users named alert("xss")