What is the best way for storing users IDs or usernames so they will not have to login every time?
I want to forward user to the members page if the stored ID or username is compared with the one stored in database.
Is is safe to do it using cookies and how can I do that?
Don't store their username or password in a cookie. Always assume that everyone on the internet can see every cookie on a person's computer. What you should do instead is save the session_id and the IP address they accessed from to your MySQL table, then save the session_id to a cookie. Most browsers will clear session variables when you close the window, but they will not clear cookies. Therefore you first check the session (are they currently logged in), and if they're not logged in then you check the cookie (were the logged in before, and more importantly- was it from this IP address?)
Of course if they have a session_id but they're not at the proper IP address, make them log in. They could just have an ISP with dynamic IPs, or they could have been listening to network traffic and they're trying to get into the admin user without a password.
This feature should be optional to let people log in from internet-cafe and such, not leaving their data open to everyone.
Yes. a cookie is the only possible way to mark a browser.
You have to store some uniqie and unpredictable value there. Generate some hash out of user's data, store it in the database along with other user data and set it as a cookie
The safest way is to require a valid SSL certificate from the browser, and validate the user-agents certificate server sided. However, in any browser I've seen installing such certificates is a big enough pain & hurdle for users that it's probably not suited for a public website. It can however sometimes be seen in intranets.
I just wrote this solution for anyone else who is interested.
http://rabbie.id.au/my-elegant-remember-me-solution-using-php-mysql-and-cookies/
With my sites, I use a custom written Session class. This stores a sess_id and sess_hash in a cookie, which is unique for the current user. An IP address is also stored in the database, and checked against the current IP to verify it is the same computer, but that is not the main authentication mechanism. Data is then stored, serialised and base64'd in the database. I would advise against using PHP Sessions, because they can be accessed by any user with the ID. Someone posting a link to something with the PHPSESSID in it, can, for example, let them log into their account.
Related
I am building a website and I am using sessions to check user login. I am wondering if there is any better and safer way to check user login. Because sessions are stored in the clients computer I think they are not very safe and easy to hack. Am I correct?How do big websites like facebook and twitter check if their user is logged in or not. I am new to PHP so dont say my question is too basic.
Sessions are not stored in the client's computer. You must be confused with cookies !
Sessions are definitely the way to go here.
No matter what you use as authentication, if the client computer is compromised, the client's method of authentication can be abused. So in this regard, any other way can only be as safe as sessions are.
All big sites use sessions, usually in conjunction with cookies.
I want you to first understand that Sessions are the only way you can identify a client.
You don't store sessions on either the client or server side. (If you want a secure system.)
First you need to understand the need for sessions, only then you can know what sessions are.
The internet is a stateless network of machines, each with their own identifiers. Most of the communication that we do while sending a request to load a page or visit various links are over the HTTP (Hyper Text Transfer Protocol).
HTTP is a stateless protocol, meaning any communication over this protocol is not required by the protocol to be stored on either the server or client.
Let us understand what this would mean, with an example:
Suppose you try to login to http://example.com
You fill the form, hit the send button.
All the data in your form is then sent to the server.
The server checks if the username and password received was right. If right, it sends you the secure data.
In your next call to the web server, you expect to be logged in. BUT, due to the stateless nature of HTTP, your server does not recognize you anymore.
You can make this work by sending your username and password with every call, but that would mean having to enter it every-time for each request.
Here comes the role of cookies, you set the username cookie as Joe and password cookie as qwerty. Now everytime a request is sent the cookies are sent by the browser and you are happy.
This scenario now again has a problem that you need to make an authentication check everytime on your server thus increasing the load on it.
Enter Sessions. Sessions mean states with some context. It may be a logged in user, it may contain preferences you have set or any other similar stuff.
Here, when the user is logged in the first time, the server generates a session ID. This session ID is then stored by the server in a DB, File or it's Memory (RAM) along with any other data like username of the person who is logged in, preferences etc.
The server response then contains the session ID, which may be in the form of a cookie, HTML5 session states or sometimes even hidden fields.
Now, every call the client makes, contains the session ID. The server then checks its session store for any valid sessions with the same ID and get into context therby giving a pseudo state-like mechanism to communications taking place over HTTP.
How long your browser stores this cookie can also be determined by the server while sending the cookie.
There are advanced techniques for further security like changing the session ID each time a call is made, but lets get into that only if you want me to.
Cheers! :)
In this age we have different machines, devices and phones, but sometimes we would like to be remembered by our own name.
I have a website where one person should be able to check "remember me" on the device he is currently working on, and having this working on all of your devices in the house.
Currently I was using a remember me function which creates a hashed key, saving it in the cookie, and in the database.
However - when logging in with the same user, but on an other device, the hashed key in the database is overwritten so the remember me function on the first device is down.
I was thinking to ceate a session table to hold the different sessions, (although it might hold different sessions for one user as well)
So Question:
How can I set/generate a unique session key for a device with php.
a browser fingerprint won't do as I use same browsers on different devices.
anyone ideas?
ofcourse I need a secure solution, preventing copying the cookie to another device or changing cookie information (from your user to admin) is important.
For a start having a hash key instead of a username does not add any extra security.
Just use a cookie with the username in it. The password is there for security.
I would do the session table to store all the sessions. Store the user's ID and the session ID in a cookie, that way when the user comes back, you can check to see if they are both in the table. If they are, they don't have to log back in.
The basic idea is to store the session ids from the different devices and tie them to one user. On the database level that means you don't have a "session_id" field in your user table but a separate table with "session_id" and "user_id" columns.
Please think about the security implications of session fixation and session hijacking. For a description of a more secure "remember me" system, read these articles:
http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice/
http://jaspan.com/improved_persistent_login_cookie_best_practice
ofcourse I need a secure solution, preventing copying the cookie to another device or changing cookie information (from your user to admin) is important.
Ultimately, this is solving the wrong problem.
The way to prevent this is to:
Use HTTPS everywhere.
Send all cookies over HTTPS, with the secure and httpOnly flags.
That's it. This is related to the problem of client authenticity. There are some techniques that can stop lazy attackers (e.g. user agent), but any of these techniques can be spoofed trivially.
On a website I am developing I am currently checking if a user is logged in if it's cookies are set. The thing is I'm using these information for some request on the database and allow him to do some tasks on the website. Though, it came to my mind that if the user edit its cookies, he might be able to be someone else (editing it's username/id). So, is there a way to secure it or do I have to use sessions ?
Yes, you can use cookies. You just need to make sure that the cookie provides data you can use to authenticate the user, and not a token that means the user is authenticated.
Bad cookie:
username=foo,logged_in=true
Good cookie:
token=uifhjrjf4093jf3904j90j390kf934j8438j0493jf9034
And then compare the authentication data against a datastore on the server.
Do I have to use sessions?
Sessions are a way to store temporary about a user (who may or may not be authenticated). They are a quick and easy way to solve part of the problem and not something that should cause reactions of Do I have to? :(.
Most session libraries use cookies to store the token that links the collection of data associated with a session to the browser to which the session belongs.
What I usually do is give a random hash in a cookie, then have point it to a database table in which I store the full browser string, a time to live, a last access time, the username and the hashed password (for comparison in case the user changes passwords because he was compromised, this will invalidate every other sessions except the one that changed his password).
On Monday, I thought I had solved the session hijacking security issue by setting the session as the user IP, until I logged in. I had two users with the same IP (myself and a test user) and it kept switching between the two. Is there a way to prevent this and allow two users with the same IP register on my site?
Thanks in advance,
Terry.
You may have been reading advice about storing the user's IP in a table along with the session id (not in place of). You'd then check to make sure they're coming from the same IP on subsequent requests, otherwise, force them to login again. This method has problems as well a user's ip can change as often as every ten minutes depending on their ISP!
Use the session id provided by PHP as it's unique and difficult to guess. Require it to be read from a cookie and never from the URL.
SSL the entire site if it is a concern and apply a short cookie time out. The ssl will encrypt the cookie and transmission so it can not be sniffed off the wire. A short time to live will make the cookie useless soon after it has been taken from the "logged in" computer if they have direct access to the system. So in short get a security cert and go on as normal with a normal php session.
I take it you're looking for the user's information in the MySQL database, using their IP? That is wrong. The only way to be truely unique is with a primary key field.
Either store the primary key as the session and pull their data, or store relevant information in the session and only pull anything else when it is needed.
I'm developing a web application using Codeigniter. When a user authenticates with my site I'm currently storing their 'user-identifier' in my session cookie (which I have enabled encryption on). Several of my model classes use the value in 'user-identifier' parameter of the session/cookie to make changes to properties of user accounts.
My concern is that I'm wondering if it's possible for someone to take a valid codeigniter-session cookie with a user-identifier that I've set, change the user-identifier's value to the value of a different user, and make changes to another user's account. Would codeigniter/php sessions create an error if someone attempted to change a property of a session cookie?
Open your /application/config/config.php, locate "sess_use_database" and change it to "TRUE" if you haven't already. This way all session variables will be stored in a database table and session cookie will only contain session id string.
For added security, you can also change "sess_match_ip" to TRUE. This way if someone steals your user's cookie and tries to pass it as their own, session will be destroyed.
"if
it's possible to take a
valid codeigniter-session cookie
change the user-identifier's value to
the value of a different user, and
make changes to another user's
account."
My answer is not really CI related, so please bear that in mind.
When you auth the user "username1" what should be sent back to the client, for auth purposes, should be a hash that the server correlates to that user. All communication between the client and the server will rely on that hash.
The server will generate a unique hash per user and the hash should have a short time to live. Can someone capture a hash and pass as that user? Certainly. That's why you should also check for the user's Agent and IP to check if they match the hash in order to prevent session hijacking.
NEVER DO THIS:
If seen some new developers storing the username in a cookie and reliing on that client sent variable to update their databases. Never do this. Do not ever, ever trust the client. When the server gets the client's hash it should check if it belongs to an authenticated user and grab the user_id (variable to update the user data) from the server. NEVER from the client.
I'm not sure what your "user identifier" is exactly. The general rule is, don't store anything in the session cookie but the session ID. Store everything else (like a user ID) internally on server side, and retrieve it using the session ID.
If the user changes the session ID (which is a random string), a new session will start. The idea behind the session ID is that it's impossible to guess other user's IDs - that's why it's random, and so long.