I want to store the username for a web site in the coockie, is it secure? What an hacker can do with this info?
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!
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.)
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.
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.
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:
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.
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
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).
Some implementations of
Provided you're expecting them to only log in from one machine, a good practice would be to:
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.
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")