currently im using session to log in the user. but when i close the browser and open it again i have to log in again. how do you keeo the user logged in in lets say 2 weeks.
is it through cookies then?
So you want a "Remember me on this computer" option? Here's a language-agnostic way how you can do it:
Create a DB table with at least cookie_id and user_id columns. If necessary also add a cookie_ttl and ip_lock. The column names speaks for itself I guess.
On first-time login (if necessary only with the "Remember me" option checked), generate a long, unique, hard-to-guess key which represents the cookie_id and store this in the DB along with the user_id. Also store this as cookie value of a cookie with a before specified cookie name. E.g. remember. Give the cookie a long lifetime, e.g. one year.
On every request, check if the user is logged in. If not, then check the cookie value cookie_id associated with the cookie name remember. If it is there and it is valid according the DB, then automagically login the user associated with the user_id and postpone the cookie age again.
As to the security risks, if the key is long and mixed enough (at least 30 mixed chars), then the chances on brute-forcing the login are negligible. Further on you probably already understood what the optional column ip_lock is to be used for. It should represent the IP address of the user. You could eventually add an extra checkbox "Lock login to this IP (only if you have a static IP)" so that the server can use the user's IP address as an extra validation.
And what if one hijacked the cookie value from an user without an IP lock? Well, there's not much to do against this. Live with it. The "remember me" thing is funny for under each forums and account-hijacks wouldn't hurt that much there, but I would certainly not use it for admin panels and that kind of webpages which controls the server-side stuff.
It's after all fairly straight forward. Good luck.
Read this: http://www.php.net/manual/en/session.configuration.php
The setting that you need is session.cookie_lifetime. Session cookies (eg ones that do not have a lifetime) are deleted when the browser is closed. If you want the sessions to stay alive for longer, set that setting in php.ini, httpd.conf, or .htaccess. Possibly even with ini_set
Edit: Actually you can use this function:
session_set_cookie_params (86400*30);
session_start()
86400*30 is 30 days.
See here: http://www.php.net/manual/en/function.session-set-cookie-params.php
Yes. You use cookies to implement the "auto login" (or "remember me") functionality.
This google search or SO search results, should point you to a right direction.
Yes, you should do that using cookies. Here's the manual entry: http://php.net/manual/en/features.cookies.php
Alternately, you can take a look at this function: http://php.net/manual/en/function.session-set-cookie-params.php. It allows you to modify session cookie settings like its lifetime...
Related
When a user logs into my site it creates 2 cookies, one with a session ID (that relates to the user ID on the backend) and a remember me cookie that lasts for 3 months.
The remember me cookie is constructed as:
userid:timeout:hash
Where the hash is a HMAC SHA256 hash of userid:timeout to prevent tampering.
If the session ID does not exist (user closes their browser and opens it again so the cookie is gone, or the session ID does not exist in memcached) it looks at the remember cookie and re-generates a new session cookie, providing it has not timed out and the hash is correct.
However I don't see the point of having a session cookie at all, as the session ID just points to a user ID in the backend. I can use the remember me cookie instead to retrieve the current user.
So I am thinking of scrapping the session cookie completely, and would be interested in hearing some thoughts on this. Does this approach sound relatively secure? Could I make it any better?
Thanks in advance!
Yes, it is indeed secure enough for most cases, but why including user specific data in the cookie when you can avoid it? Also, there's a small disadvantage with this:
What happens if an user manages to steal a cookie from another user, you'd have to change the whole way the cookies are generated or that user will always have access, therefore resetting everyone's cookies. Imagine now that it's your cookie that gets stolen...
This is my solution for that: create another row in the user table called 'userhash'. When an user logs in, you generate a random hash without taking any of his input, just random, and store it both in the table and in the cookie. Then you only have to store userhash:timeout in the cookie. You check that against the database to see if it exists, if it does, that's your user. When the user logs out, the cookie and the row in the database gets deleted. For obvious reasons, you'd have to check that the cookie exists before comparing (there will be many empty).
Note: This method would only allow one registered cookie at once, so no laptop + desktop. This is good, since stealing is made more difficult as it only lasts as long as the real user doesn't log in, and bad because it only allows 1 computer. But you see the idea and how you could use this method but having several computers logged in... facebook-like.
PD, it'd be nice if you said how secure your app must be actually...
PD2, in case you haven't think about it yet, there are other more serious security concerns (SSL to say one).
When a user log in and check the "remember me" box, I generate a key (very random numbers on a md5) for it and save on it's cookies. If the user is not logged, my code check for a "remember me key" cookie, if it matches with a user, then he's logged in.
My question is, how do I stop users from coping their remember me key cookie and pass it to their friends? Because if they do that, the person who copied the cookie will be logged in without even knowing the password of the account, then they would access a premium account without buying it.
I can't bind the key to the ip, or else the remember me wouldn't work well, since lots of computers change ips very often. I though about saving the user agent and others browser infos, what do you think?
You can detect the sharing of cookies by regenerating the key for the cookie each time it's used. If someone gives a remember-me cookie to someone else (or it's stolen) and they both use it, then they will both end up with different keys after they use their cookie.
Only allow the most recently generated key for each account. If someone uses a key that doesn't match the database value, then invalidate all sessions associated with the user.
My question is, how do I stop users from coping their remember me key
cookie and pass it to their friends?
Best solution is not to use remember me:
https://www.owasp.org/index.php/Guide_to_Authentication#Remember_Me
If you still want to then you could check the requesters browser and ip but then maybe your have useability issues. Limiting the number of concurrent sessions to 1 per paid user may deter the exploit you are concerned about.
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 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 making a forum for learning mostly but hopefully it will have a couple of users some day.
What im wondering is should you use sessions or cookies for user authentication?
A cookie is a short piece of arbitrary data that the server sends through a header; the client stores it locally and sends it back on the next request. This mechanism can be used to maintain state from one request to the next even though HTTP itself is a stateless protocol. Cookies have two disadvantages: They offer only very limited amount of space (4 kB), and because they are sent back and forth in plain, a malicious client can fiddle with the contents before sending it back to the server, effectively making cookie data untrusted.
A session is a file on the server, identified by a unique ID which is sent back and forth between client and server so that the server can identify the client. The most popular way of sending the session ID is through the cookie mechanism, but it is also possible to pass the session ID through the URL (this is why you often see links that contain the URL parameter 'phpsessid'). This solves the two problems with cookies mentioned above: A file on the server can be as large as required, and the client cannot access the data other than through your own scripts.
Authentication is typically solved using cookie-based sessions; once authenticated, a new session is created, and the user ID is stored in it, and when logging out, the session is cleared and a new session ID is generated. Alternatively, you could store username and password in the session, and check them on every request.
Use a session.
A session is identified by a cookie, true, but not the same as storing user auth info in the client cookie, which is bad for security. A session cookie stores a guid or a hash in the cookie, then identifies the session (either database or file system based, depending on your server's php settings) based on that.
I recommend you store the primary key from your user table, not any other info, then look up the user info every time - this allows you to change their validation status, or security level on the fly while they are logged in; otherwise they will have to log out and back in before your administrative changes take effect for them - IE. you can't boot them.
Also, don't store the username/password, because that requires a less efficient query than by the indexed primary key (even if they are indexed as well).
They are essentially the same, working hand-in-hand. When you create a session..say through PHP, a cookie is created to store the session id too. On the other hand, you would create another cookie if you want to implement a "Remember Me" option to prevent your users from logging in every time.
I'm not a PHP expert, but Session and Cookie are related. In other programming languages you have the option of creating "Cookie based session" or "Cookie-less session". I'm not sure about PHP though so maybe you are referring to different concepts.
I feel using session is much more safe and easy then using cookies. The reasons are as follows:
1) In cookie we can only store a single piece of information, whereas in a session we can store as many information as we want.
2) Being stored on hard disk of user, cookies can be played with. Being a person interested in hacking, I have done that and gathered useful information about the user. Sessions cannot be used for such a thing.
If its a small amount of data (just one variable), I would use a cookie. Here is the code...
setcookie("cookie name", "cookie value or variable name", time+ 3600, "\");
this code sets a cookie that is readable for any of your webpages. It also will delete its self in one hour.
You can also see if the cookie exists like this (to see if it has deleted its self).
if (isset($_COOKIE['cookiename']))
{
}
to collect a value from a cookie...
$value = $_COOKIE['cookiename']; //makes a variable for this cookie for your program