Hi there
I run a forum in which the users login with their usernames and password. At the moment when they login it stores their username and whether they are loggedin in a cookie, and it does not store their password. Is this a secure way to do it? Would it better to use sessions and why? Should the password be stored?
Many Thanks
Richard
you should have some way to authenticate the user through a cookie or a session. if the only cookies that ensure they are logged in is one holding their username and one saying if they are logged in, its not very secure. Anyone with a little knowledge could make a cookie or use a program to send them and automatically be logged in as anyone they want. you should at the least store an enctypted or hashed version of their password in a cookie and on each pageload make sure the password in the db matches up to the one in the cookie. sessions are also an okay idea, but by default a session ends when the browser is closed so unless you dont mind people logging in each time they come on you could use some sort of session authentication.
A user can modify his cookies. So doing it this way a user could change their user id and access someone else's information, or not log in at all and just set a cookie saying they are if they know any valid user id. If you're going to store information like this in a cookie you should encrypt it first.
Sessions are the better way to do this since a user cannot modify information stored in a session, and it is very hard to guess another valid session id.
Generally speaking you should not store the password either in the cookie or the session, and only in the database in hashed form.
mtmosier wrote:Generally speaking you should not store the password either in the cookie or the session, and only in the database in hashed form.
Can you explain why must the password in the database by hashed please? I am just curious.
Thanks.
Because if your site were hacked (completely, or through something like a sql injection attack) then an attacker could get access to your users table. Even if your application has no vital data to protect, users have a tendency to use the same password for many different sites. So it could be possible for an attacker to take the username/password combination from your site and use it to gain access to the user's bank website.
Oh. I get it. Thanks. I will definitely keep this in mind.
Best regards....
Many thanks!
Hi again,
Any ideas why sessions would affect the posting of a form? The username and password inputs do not come through when submit is clicked :S
Richard
whats the code you are using. are you using session_start and assigning the $SESSION variables values from the $POST array?
Hi there
Its before I even put variables in the sessions that it is not working now - If i echo the variables they don't display, even though they worked fine when I was using cookies, so it can't be a fault in the form :S
try print_r($_POST) and see what it displays.
Just this:
Array ( )
In the script before I was just using $username etc to pick up the post data, but i've also tried $_POST["username"] and it doesn't work either
Thanks once again
Richard
so then if you try getting rid of all session functions and variables in that script will the print_r once again result in showing data? if so post the code of both with and without session stuff and we can see if there are any small mistakes or if its really a strange behaviour. just out of curiousity, what php version is it you are using?
I have now located the problem - It is not setting the sessions properly, or it is not reading them properly -
Is this correct?
session_start() - on the first page the user goes to
$SESSION['username'] = $username;
$SESSION['loggedin'] = "Y";
more code
if (!isset($SESSION['loggedin'])||$SESSION['username']=="" || $getingt['isbanned']=="Y")
{
session_start should be on every page that you will use a $_SESSION variable on.
my simple session test is this:
ses1.php
<?php
session_start();
if (!isset($_SESSION['count'])) {
$_SESSION['count'] = 1;
} else {
++$_SESSION['count'];
}
echo $_SESSION['count'] . "<br />\n";
echo "<a href='ses2.php'>Page 2</a>";
?>
ses2.php
<?php
session_start();
echo $_SESSION['count']++;
echo "<br />\n<a href='ses1.php'>Page 1</a>";
?>
see if that basic example keeps incrementing the number for you.
I have now found out that the problem must be in the reading as it writes them successfully, as long as they are being carried through properly.
Woops me again - sorry and thanks for your help!
I think that the problem must be that the sessions aren't being carried through the pages correctly, because they echo on the same page as they were created, but on other pages. (When I pages i mean sections of the code, as a use ?Loc= for each page in one php file)
Many many thanks
Richard
Ah thank you I didnt see your post (#15)
IT WORKS!
Thank you soo much for your help! They say you learn something new each day...
I really can't be grateful enough
Thanks!
drew010 wrote:you should at the least store an enctypted or hashed version of their password in a cookie and on each pageload make sure the password in the db matches up to the one in the cookie.
we may use several items in the match in addition to the password cookie. userid, user-email, user-password. userid and user-email are in plaintext in database, we can save them in cookie encrypted. password is already encrypted in the database, we can save the encrypted value directly, right?
the whole idea for the saving the encrypted value in cookie is that for prevent attackers who sign in as your user, and then analysis the cookie and then try to break into other users account, right?
if the clients computer is attacked by the attackers and his cookie is grabbed by the attacker, then encrypted or not encrypted cookie values, will that still make difference?
or with not encrypted cookie value, the attacker could sign in from his computer, but with encrypted value, the attacker has to pretend to sign in from the victim's computer? so encrypted cookie value still add a layer of the protection here?
drew010 wrote:sessions are also an okay idea, but by default a session ends when the browser is closed so unless you dont mind people logging in each time they come on you could use some sort of session authentication.
How about session fixation attack? PHP cookie is also under the "session fixation attack", or php cookie cannot be attacked by session fixation attack?
session id is a cookie, the when session fixation attack get your session id, does it mean it get your cookie, so php cookie is also attacked by session fixation attack method?
in the manual, session chapter has mentioned the session fixation attack. but cookie chapter doesn't, even cookie could set up to have a life time as session, but cookie has nothing to do with the session (or session fixation attacks)?
How session and cookie works in php? is using cookie a alternate approach to prevent session fixation attacks?
Thanks!