Scratch

sparks wrote:

nXIII wrote:

You could hash the password and store that and the username (or use a random key, although just hashing means you don't need to store any additional data); alternatively you could store the session ID in a cookie. That way, if the cookie was copied to another computer, it would only work while the user was still logged in.

That's a good idea! Wouldn't the session id change when the session expires though?

Yes, it will expire on the client side, but it should work on the server; if not you can make your own "sessions".

Last edited by nXIII (2012-02-27 19:43:29)

sparks wrote:

nXIII wrote:

sparks wrote:

That's a good idea! Wouldn't the session id change when the session expires though?

Yes, it will expire on the client side, but it should work on the server; if not you can make your own "sessions".

Okay, thanks    I've learnt something 

:-) ,

by the way 1 more thing with sessions if you wanna implement you can actually do something with redis it allows you to store volatile keys that it consider it automatically erases a value after sometime    .. thats very nice utility so if your application is quite realtime you can expire the session with the database itself [ which is actually very fast ]

sparks wrote:

Well thanks for the help, everyone 

My website now create a md5($username) cookie which it then compares against a database of md5'd user-names to see if there is a match if you are logged off and the cookie is found! Initially I was going to use the password since that is already hashed, but I felt it was safer to use the user-name as a hash. User-names are unique too, so that will stop people who happen to have the same password from getting into trouble later 

Couldn't an attacker simply md5 another user's username and set that as their cookie while the other user was logged on?

Last edited by nXIII (2012-03-04 19:28:50)

sparks wrote:

nXIII wrote:

sparks wrote:

Well thanks for the help, everyone 

My website now create a md5($username) cookie which it then compares against a database of md5'd user-names to see if there is a match if you are logged off and the cookie is found! Initially I was going to use the password since that is already hashed, but I felt it was safer to use the user-name as a hash. User-names are unique too, so that will stop people who happen to have the same password from getting into trouble later 

Couldn't an attacker simply md5 another user's username and set that as their cookie while the other user was logged on?

Ah. You're right. Should I store the password on a second cookie and check for both?

I would store some random hash which is discarded after the session ends. That way, an attacker could potentially steal the hash and log on while the session was going on, but if a user felt threatened he/she could simply log out and log back in again. You could also store an IP address with the generated session hash and check against it so that not even that could happen.

sparks wrote:

Code:

if ($status == 'ok' & $verificationKey == 0){
        $_SESSION['username'] = $_POST['username'];
        if(isset($_POST['cookieMe'])){
            $randomCookieId = mt_rand() . mt_rand() . mt_rand() . mt_rand() . mt_rand();
            mysql_query("UPDATE membersList SET cookieId='$randomCookieId' WHERE username='$_POST[username]' ");
            setcookie("user", $randomCookieId, time()+259200);
        }
    }

1 use timestamp and md5 hash your timestamp making unique values with user names and timestamps something like
 

 
    $randomCookieId = hash('aes256',('a' . mt_rand()  . ' ' . microtime())); 
    // This will pretty much generate a very unique key everytime x) 
   // Though i presonally suggest using mcrypt

second you code is wide open for mysql_inject

        $_SESSION['username'] = $_POST['username'];

i would have done

                $_SESSION['username'] = trim(htmlentities($_POST['username'],ENT_QOUTES)); // A layer of filter.

In production though we never keep unencrypted information open to database
what we do is hash down everything even usernames and passwords and do operations on those say we do somethign like

               $_SESSION['username'] = hash( 'aes192',trim(htmlentities($_POST['username'],ENT_QOUTES))); // A layer of filter.

And all the values in database follows the same :-) hope that helps.

and yes it worths checking if you wanna do it the database way..

oh by the way if you want you can see the cookies system i suggest in action on http://tapeer.net/mobile.html    it works on cookies for XHR comet serving but the session concept is same as what you want [ if you want i can send u the node.js source code too]

Last edited by fanofcena (2012-03-05 07:01:56)

mysql_real_escape_string()

sparks wrote:

rookwood101 wrote:

mysql_real_escape_string()

I was going to use that, then I read that this sort of injection protection is included as standard setting for new versions of html and wasn't needed anymore...

I think it's always better to be safe, though. What I usually use is sprintf() + mysql_real_escape_string():

$q = mysql_query(sprintf("INSERT INTO `foo` (`bar`, `baz`) VALUES ('%s', '%s')", mysql_real_escape_string($userbar), mysql_real_escape_string($userbaz)));