Please, advice if my thoughts are correct. I have searched for information but have not found exact answer.
User enters username and password and the entered username/password are the same as in mysql.
I create $_SESSION['loggedin'] = 1; This means that somewhere on server is created file with random name like r21bj2a3.... and in user browser is created cookie with value like r21bj2a3....
On next page I check if( $_SESSION['loggedin'] == 1 ). User browser connect to server, send to server information like: I have cookie with value r21bj2a3...., please send me content of ? session? Server sends information that for the particular cookie session loggedin is 1.
As I understand if malicious user gets cookie value r21bj2a3...., sends to server and gets the same answer as normal user?
Depending on $_SESSION['loggedin'] I can not identify particular user? To identify particular user after successful login I can create unique token, record in mysql and pass with session? And on password protected page from the passed session I get token value and check (select) if such value exists in mysql. Is this way ok? May be post some link with good method?
Regarding token. I pass the token value with sessions. That means if malicious user get cookie value, send to server and get answer, containing token value (so malicious user gets rights of normal user)?
I suggest to save all active sessions in the database, you can create a table for doing that, to prevent session hijacking, you can check each particular session (login) and see if user already authenticated, then, do not allow second authentication.
The problem here, how to recognize user?
You can bind some Information like USER_AGENT, and IP Address, however, these information can also be spoofed by hacker, but, the probability is less.
Also, once user signed out, you can delete the session record in the database.
HTTP is stateless protocol.It does not keep track of data across several pages.So we require session which can be globally accessible across all pages in website
For identifying the user who is currently logged into website we need to store value of user_id field in user table into session after he is authenticated successfully.
e.g.
$_SESSION['user_id']=$result['user_id']
And to determine whether user is logged in or not we can check the value of $_SESSION['user_id'] variable .If it is empty then user is not logged in else user is logged in
To identify which user the session belongs to, just set a viable in the session
$_SESSION['user'] = user
You are correct about the cookie giving access to the session. If security is important, use SsL.
Related
This is the use case:
a hacker login to a web site private pages of another user ("the correct user") using his/her pw
the correct user, without logging-in, changes its password using the "forget password" function
the hacker never log out and his session stay on because he still has the credential as a session data in his browser
What I would like to do is this: once the correct user changes his/her pw the session of the hacker is destroyed by the reset password user function. But the correct user browser has not any reference to the session id/code of the hacker ones so if it is run the function session_destroy() this does not affect the hacker session, just the correct user one. But, since some unique ids linked to the user account are set as session data, it is theoretically possible to identify the session having that field valorized to the correct user id and erase the session itself. The problem is how to do it, does Codeigniter have any function to find a session saved on the server searching for its field values? Currently, I use the default way to keep track of the sessions, so on disk.
Since php login application uses session id(one for each user) which is stored in cookie which is send as header information to server that allows the user to get automatically logged in(assuming that the user is already logged in some another tab in same browser lets say Chrome).
My question is if I store that user session id cookie information in another browser(lets say Firefox) and open the same application, will the user will get automatically logged in or not.
Or if someone finds out my session id and store them in its browser will the application will allow the user to login or not.
Take a look at session hijacking.
If somebody steals your session cookie, and you are still logged into the website, then yes. The attacker can log in using that session cookie.
And because of the answer given by #JonTan, you may see the fact that auto-login based only on PHP's session ID is not secure.
There all sort of solutions to that problem, but the base of each of them is to try and identify as many "unique" attributes of the user.
For example, store the user user-agent and ip address. When you "auto-login" the user, check for those details as well, and if they don't match than destroy the session. You may also add another token that you generate from this data as an "extra" security attribute and store it in the cookie, and check if that token match as well (you will most likely want to generate this token based on the user-agent, ip etc, so that you will be able to regnerate the token to match).
So, if a login/registration system is created, so that when the user logs in, the user is redirected to another members-only page (member.php), I would store the login information in the user's session.
When the user navigates to the members page, prior to allowing him to see content, I'd want to make sure that the username/password is valid, and the user is validly logged in. How might I ensure that the user is validly logged in when he/she gets to the member's page, to me it seems like using:
if (!isset($_SESSION['username']))
{
die("You aren't allowed to access this page");
}
would work, however I want to ensure it's secure, and to me, it just doesn't seem secure enough (because if there was some way of spoofing a session, all they'd have to do would be to include any sort of text as the username).
I don't really know, so how would I check whether the user should have access to the page?
Session variables are stored on your server, not on the users computer like a cookie. So the user can't ever modify $_SESSION['username']. The only thing you have to really be wary of with sessions is session hijacking (where a user gets the session id of another logged in user, and uses it to pose as that user)
A user may spoof a session ID cookie if they know a valid value, but not the session data itself, which is stored on the server.
Thus, they may not just "send you" session data with a certain username.
If they have access to the browser of someone who is logged in, they may be able to steal their SESSID (which is stored on the client), but per-IP sessions can mitigate that somewhat.
Put an encrypted password cookie/session var with a salt perhaps, to be checked against the db every now and then.
how do you check if a user already has logged in?
so that if a user in another browser cant log in with the same account.
also, is this a good solution or should i let the user log in in the other browser and then log out the current user and display a message (you are logged in from another location) just like messenger does?
Using sessions is a good way to do this, and is a very common method for controlling authentication.
The flow usually looks something like this:
User visits site, and session_start() is called. A unique session identifier is set for that visitor (ie. a cookie).
User submits his login credentials to a login form
Login credentials are verified, and this fact is stored in the session data with $_SESSION['logged_in'] = true, or something similar
For the rest of the user's time on the site, you can check $_SESSION['logged_in'] to see if the user has logged in.
In order to control a user's logins, you could simply have a field in a database (users table is fine) indicating what the current session id is (retrieved with session_id()) for the user, and if it doesn't match the cookie value you just received, then you immediately call session_destroy() for that id, and consider the user as logged out.
Using $_SESSION means you don't have to worry about generating your own tokens, and gives you the power of the built-in superglobals to facilitate storing information about the user's authentication status.
Personally, I would allow multiple sessions to be active for a user for most web sites, as there's usually not a good reason not to, but it obviously depends on the nature of the site. However, storing the current active session id as mentioned above is a pretty simple way to accomplish this.
Generate a random token upon signing in (or use the sessionid), and store this in the database and in the users cookie. With each page access, ensure that the users token matches the database entry. If the two don't match, alert the user that they've logged in elsewhere.
You could also store the login time, which subsequently would be the time the token was assigned, and require 30 minutes before permitting another user to login with the same ID.
The first half of the question was answered well with how to detect the multiple users but how to treat them I think still needs a bit of work.
First if a user logs in correctly let them in, don't prevent them if they are logged on some other place. If you really don't want the user to have two open sessions then log out the old one or simply update the session id that you are saving so you can bounce out the old connection. You can inform if you want but I would only message the session that you invalidated. If you message the user logging in it becomes annoying when you are only dealing with the case of a user switching computers and they forgot to log out of the old session.
Well All solutions mentioned above will work but if on every page access you are making a call to database and checking for the session token to see weather its the same token assigned to user .. will kill your response time. what i'll suggest is use a caching mechanism instead of database in above said solutions. storing session token into database will add extra field to your database which is actually not required. Use open source caching solution like memcache.
you can make a table like userLoginStatus with fields like clockIn time & clockOut time,
and insert current time in clockIn when user is do login, leave clockOut time blank at that time, it should be updated only when user do clock over logout button,
so you can check specific user's current status, where clockOut is empty that user should be logged in. because it updated only when user do logout.
Im making a login/logout class that logs users in, sets cookies based on user's choice. The user enters their email/password and it checks the database, email/password combo exists a session is created, and a cookie is set (with the users id) and the user is redirected... I then have a function that logs users in by taking the user id saved in that cookie, checking whether that user id exists and then saving the users data in a session yet again... i was wondering if anybody see's anything potentialy wrong/unsafe about this.
Short Example, im sure you guys can get the gist of it...
function login($email, $password, $remember){
// Check the database for email/password combo
if(/*user exists*/){ // if the user exists
$_SESSION = /*User data*/ // save the users data in a session
if($remember){
setcookie('user_id', /*User id*/); // save the user id in a cookie
}
header("location: index.php");// redirect
}
}
function Check_Cookie(){
if(isset($_COOKIE['user_id'])){
return $this->Log_In_ID($_COOKIE['user_id']);
}else{
return false
}
}
function Log_In_ID($id){
//Check the database if the user id exists
if(/*user exists*/){ // if the user exists
$_SESSION = /*User data*/ // save the users data in a session
header("location: index.php");// redirect
}else{
return false;
}
}
Its not a detailed example of what im trying to ask, but im sure you can get the gist of it... Does anybody see anything potentially wrong with this. If you guys have any recommendations id love to hear them...also, do you guys use oop to log users in, or any other ways.
If your user ID is a sequential number, this is pretty insecure as anyone can just change their cookie to another reasonable-looking number based on their own (e.g. if mine is 1274, I could try some other numbers in that range) and immediately spoof that user.
You would be better off assigning a temporary ID associated with that user, like a GUID. Since GUIDs are astronomically unique and practically collision-proof, they're also virtually impossible to guess or predict from outside the system.
When the user logs in, you create a new GUID and store that with the user:
UserID TokenID Expires
1274 {3F2504E0-4F89-11D3-9A0C-0305E82C3301} 9/25/2009 12:00:00
When a user returns, look up their user ID by the token, make sure the token hasn't expired and log them in. Then change their token. This secures you against the following:
An attacker cannot guess another user's token and spoof them
Token expiration cannot be circumvented by ignoring the cookie's expiration date
Since tokens change constantly, even if an attacker does manage to gain access to a user's cookie, the window of opportunity to take over is very small.
You should not trust the cookie data. What happens if I edit my cookie and set my ID to say, "1" (which is likely to be an administrative user)?
Basically, don't do this.
If you want a "remember me" type function, just save a username in a cookie so you can prepopulate the login form when the user returns -- but force them to reauthenticate.
Cookies are very easily altered- so if you are only storing the ID a user could change it. By guessing they could access other accounts and potentially even get admin access. Generally I store ID along with a token when I use cookies for authentication.
You can take for example a hash of the ID and a salt value and store it- You can then verify the token when the user connects. It isn't perfect and there are more considerations for a high security site- but for a standard site that should be a good start.
Another tactic is to store a long unique session ID and use that to log the user back in.