When making a login system I always had the user submit the form and then I would hash the password and check it against the record in the database. I just had someone say how he thought it was better to hash it using javascript first because if you wait for php to hash it the password can be intercepted between the browser and the server.

Is this true? And if it is can I avoid using javascript because that would mean I would need to only let people with javascript enabled use my website.

The javascript hashing idea is ****, if the user has the js file cached their password will be in it.

Though, the password can be intercepted between the browser to the server (Like when the password is submitted via a form), but if you add "enctype="application/x-www-form-urlencoded"" to your form code, this should fix that problem:

<form id="form3" method="post" action="" enctype="application/x-www-form-urlencoded">
<!-- Crazy stuff here -->
</form>

or, alternatively you could not call the field "password" or just gzip the thing your posting.

The main concern with hashing is rainbow tables, where someone has sat down and figured out what words hash to what, good coders tend to overcome this by adding salt to their hash (extra bits to the string so make it less likely to be a known hash) for example:

PHP Code:

$salthere = "mymagicsalt";
$password = "12345"; // original password

$password = md5($password); // Hashed password
$password = md5($password.$salthere); 


An even more secure system would be to create a random salt and save it in your database for each site you use the login system on. That way its not actually in the PHP files should somebody somehow obtain them.

Ya I was thinking the JS idea was worthless as well.

I have never seen that enctype before, looks cool though. Do I need to do anything on the server end in order to unencrypt it or will the server figure that out automatically?

With that code that hashes the password are you hashing the password then adding the salt and then hashing it again? Right now I just take the password add the salt and then hash it.

XBSHX -> That could only happen if some gets access to my ftp server some how so as long as I am the only one with ftp access I shouldnt really run into problems with that. But your idea of saving the salt in a database, wouldnt that slow down the site because you would have query the database an extra time for each login. Plus then it is transmiting the salt which could be taken and figured out just like a password right?

I wrote my own encryption formula, with a two way thread, and a seed. I am going to start using it re-encrypt sha1 passwords that are stored inside of a cookie. No one will guess what I'm doing.

Although I don't want my formula in the public domain, it was a lot of fun to make, and I'll give a clue: it is based on the manual seeding and reseeding of the random number generator.

The enctype thing doesn't encrypt code, it just declares to the server that form data is coming and the format in which it will arrive.

Proprietary algorithms are almost always easier to hack than hashes. In fact, one of the litmus tests for an algorithm is that knowing the algorithm doesn't help hack it. You'll notice that the algorithm for all publicly-used, standard encryption/hashing techniques is available for the reading. Want the formula for RSA? It's out there. Same deal with the rest.

Let me provide some additional guidance:

1) Use the strongest hash you have on your system. Hashes can be broken, but not in the way one normally thinks of. Currently, I use the PHP hash function with SHA512.

2) Create a random seed for the user. Make it looooooonnnnnnggggg.... The longer the better.

Now, why a specific seed for each user? Well, research has shown that if a hash has a common aspect with other hashes, then the algorithms to break the hash can get smarter as they find more known values. By hyper-randomizing the data, you make it virtually impossible to break in the near future.

3) Do NOT use Javascript for hashing. That would be more secure, but only if you're not using a seed. Otherwise, you have to publish the seed to the HTML page for the Javascript to read virtually wiping out the effectiveness of your whole design.

4) To stop the password from being transmitted plain-text, use a SSL connection. This uses some advanced public-key cryptography that will thwart most users. If you want to obfuscate the password as an added layer of security, then hash it using a Javascript function and a seed which you can expose. That will make lookup tables have a hell of a time. Then, treat the Javascript-hashed value as the user's password and proceed with the additional behind-the-scenes hashing.

5) Use multiple algorithms. Your hash function has access to a number of them. Doing this slows down the generation of the hash but that's insignificant in comparison to the other side effect: hacking becomes substantially more time consuming as well.

6) When using multiple algorithms, change the order the seed is presented. Not sure if this actually helps, but it definitely can't hurt.

6) I would store the user-specific hash in the file system and the hashed password in the database. By separating the storage areas, one is now required to do more than gain just access to your files or just access to your database -- they need both. This is the weakest aspect of this system, but every bit of difficulty counts.

Implement those things and you'll be safer than just about every system out there.

Remember, however, that this is only securing the data you store. Your users may use a password saving function on their browser to save the password or write it down on a sheet of paper and it's all over. Very often it's easier to hack a user than a program. To prevent the user from saving the password in the form (which they may consider an annoyance), you can set autocomplete="off" in the <form> tag.

hmmm I cant find a whole ton of information on sha512. Can it be used with php4? I havent switched over to php5 (although I guess I could I havent read about what the updates are). And then using multiple algorithms you mean first hash it with md5 and then use sha512, something like that?

As far as a uniqeu salt for each user you said keep it in the file system, you mean just create a txt file and store them in there with the users id? I was also thinking to make an array with a bunch of random salts and then in the database just have a number that corresponds to that salt.

For the SSL do you know of a good tutorial for that? I have been searching but its all just sites that want to sell me the certificates and nothing that explains how I actually use it.

I love the "not sure if this actually works" . I will do it anyways.

I also like the idea of autocomplete off I have never heard that before. I am bad with using auto complete and the finger swipe thing with my laptop but I only use that for non-sensitive sites.

Thanks so much for your help, this is awesome, feel myself getting smarter already!

Originally Posted by Truly

hmmm I cant find a whole ton of information on sha512. Can it be used with php4? I havent switched over to php5 (although I guess I could I havent read about what the updates are).

Um, how about that there aren't any more updates for PHP 4 as a reason? I only provide PHP 5 stuff (though, of course, much works with PHP 4). The hash function is for PHP 5.1.2 or above unless you have the PECL module installed. Otherwise you are confined (natively) to md5() and sha1() with sha1() preferred over md5().

Originally Posted by Truly

And then using multiple algorithms you mean first hash it with md5 and then use sha512, something like that?

Yep.

Originally Posted by Truly

As far as a uniqeu salt for each user you said keep it in the file system, you mean just create a txt file and store them in there with the users id? I was also thinking to make an array with a bunch of random salts and then in the database just have a number that corresponds to that salt.

I was thinking a text file, sql lite db, etc. Do whatever you're comfortable with. The more distant the pieces required to help hack, the harder it will be for the hacker.

Originally Posted by Truly

For the SSL do you know of a good tutorial for that? I have been searching but its all just sites that want to sell me the certificates and nothing that explains how I actually use it.

Get a dedicated IP and buy a cert from a place like GoDaddy. They have installation instructions. Yes, the dedicated IP is required. Now, if you have smarter users who don't get scared by browser messages, you could get a secure cert (still need a dedicated IP) from http://www.cacert.org/ . It's just not in the default list of approved CA, so a warning message comes up until you add the cert to your default list.

Originally Posted by Truly

I love the "not sure if this actually works" . I will do it anyways.

I didn't want to assert something as fact unless I had good reason. Since I can't mathematically demonstrate it's effectiveness (or lack thereof) and haven't read any research on it, I can't speak to its effectiveness. However, on a much simpler level, one would think that changing things up a bit would make solving the problem harder.

Originally Posted by Truly

I also like the idea of autocomplete off I have never heard that before. I am bad with using auto complete and the finger swipe thing with my laptop but I only use that for non-sensitive sites.

Thanks so much for your help, this is awesome, feel myself getting smarter already!

Glad to help. Best wishes!

Oh, and get on to PHP 5 ASAP!

Ok so I gave it a shot and pieced together a login system. Below is the code that I have, if you experts (especially Jeremy since you have been so much help) could look it over and tell me where I can improve. My biggest problem, I think, isnt with the login system itself but I dont know how to securely check after that, I am just matching the ip address with the one stored in the session, which is obviously very insecure.

Anyways here it goes:

Registration Page:

PHP Code:


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
 <html>
<head>
<script src="clmenu.js" type="text/javascript"></script>
<link href="clmenu.css" type="text/css" rel="stylesheet" /> 
</head>
<body>
<?php 
//import global variables: primarily database connection information
include "variables.php";
//includes the file that creates the salt and saves the salt in the database (in 2 seperate functions called later down in the code)
include "passenc.php";
//variable used for error checking
$flag=0;
//sets the current date which is added to the database to record the users date of account creation
$date=date("Y/m/d");
//next 3 lines just set variables for inserting into the database and providing protection against sql injection
$uname=mysql_real_escape_string($_POST['uname']);
$pass=mysql_real_escape_string($_POST['pass']);
$email=mysql_real_escape_string($_POST['email']);
//checks to see if the registration form has been submitted
if (isset($_POST['register']))
    {
    //makes sure that the fields havent been left blank
    if ($_POST['uname']!="" && $_POST['pass']!="" && $_POST['confirmpass']!="" && $_POST['email']!="")
        {    
        //attempts to retrieve info from the database that corresponds with the username requested in the registration process
        $result=mysql_query("select * from userdb WHERE uname='$uname'");
        $row = mysql_fetch_array($result);
        //adds an error if that username already exists
        if ($row['uname']!="")
            {
            $error="That username is already in use. <br />";
            //sets flag to 1 which will bypass the rest of the error checking
            $flag=1;
            }
        //makes sure that the last round of error checking was passed
        elseif ($flag==0)
            {
            //includes a file to check if the email is in a valid format and to see if the DNS is valid
            include "emailcheck.php";
            //attempts to retrieve info from the database that corresponds with the email requested in the registration process
            $result=mysql_query("select * from userdb WHERE email='$email'");
            $row = mysql_fetch_array($result);
            //adds an error if that username already exists
            if ($row['email']!="")
            {
            $error=$error."An account has already been registered using that email. Try loging in to that account or retrieve your password if you have lost it.<br />";
            //sets flag to 1 which will bypass the rest of the error checking
            $flag=1;
            }
            }
        //verifies that both password fields are equal or adds an error
        elseif ($_POST['pass']!=$_POST['confirmpass'])
            {
            $error=$error."Both password boxes must be the same. Please try again.";
            //sets flag to 1 which will bypass the rest of the error checking
            $flag=1;
            }
        }
    //adds error if one of the required fields were left blank
    else { $flag=1; $error="One of the following fields have been left blank: Username, Password, Password Confirmation, Email"; }
    //checks to see if validated correctly and then adds to the database.
    if ($flag==0)
        {
        //sets variable salt equalt to the returned value from the function passenc() in the included file passenc.php
        $salt=passenc();
        //pass is hashed
        $pass=hash("sha512",(md5($pass.$salt)));
        //Insert the user into the database
        mysql_query("INSERT INTO userdb (uname, pass, email,joindate) VALUES ('$uname','$pass','$email','$date')");
        //selects the primary key (idnum) from the database that correspond to the email
        $result=mysql_query("select idnum from userdb WHERE email='$email'");
        $row = mysql_fetch_array($result);
        //passes idnum to the function savesalt() in the include file passent.php. This function adds the salt into a seperate table in a seperate database with a different password and username. The idnum from the user database is included with it so that they can be matched back up.
        savesalt($row['idnum'],$salt);
        //informs the users that the registration porcess has been completed and provides them with further instructions
        echo "You have completed the user registration form. <a href='index.php'>Return home.</a>";
        //sets the flag equal to 3 which will stop the registration form from reloading
        $flag=3;
        }
    //if information did not properly validate then the accumulated error messages are displayed along with information on how to get help.
    else 
        { 
        echo $error; 
        echo "<br /> If you continue to have problems please contact us at webmaster@helicon-news.net.";
        }
    }
//if the registration hasnt already been properly completed then the registration form is reloaded
if ($flag!=3)
    {
?>
<!-- Main User Registration Form -->
<form name="regform" method="post" action="register.php" enctype="application/x-www-form-urlencoded">
    <!-- username -->
    Username:<br /><input type="text" name="uname" value="<?php echo $_POST['uname']; ?>" /><br />
    <!-- password and password confirmation -->
    Password:<br /><input type="password" name="pass" /><br />
    Confirm Password:<br /><input type="password" name="confirmpass" /><br />
    <!-- users email -->
    Email:<br /><input type="text" name="email" value="<?php echo $_POST['email']; ?>" /><br />
    <!-- time zone -->
    Time Zone:<br />
    <select name="timezone">
    <option value='-12'>(GMT - 12:00 hours) Enewetak, Kwajalein</option>
    <option value='-11'>(GMT - 11:00 hours) Midway Island, Samoa</option>
    <option value='-10'>(GMT - 10:00 hours) Hawaii</option>
    <option value='-9.5'>(GMT - 9:30 hours) French Polynesia</option>
    <option value='-9'>(GMT - 9:00 hours) Alaska</option>
    <option value='-8'>(GMT - 8:00 hours) Pacific Time (US &amp; Canada)</option>
    <option value='-7'>(GMT - 7:00 hours) Mountain Time (US &amp; Canada)</option>
    <option value='-6'>(GMT - 6:00 hours) Central Time (US &amp; Canada), Mexico City</option>
    <option value='-5'>(GMT - 5:00 hours) Eastern Time (US &amp; Canada), Bogota, Lima</option>
    <option value='-4'>(GMT - 4:00 hours) Atlantic Time (Canada), Caracas, La Paz</option>
    <option value='-3.5'>(GMT - 3:30 hours) Newfoundland</option>
    <option value='-3'>(GMT - 3:00 hours) Brazil, Buenos Aires, Falkland Is.</option>
    <option value='-2'>(GMT - 2:00 hours) Mid-Atlantic, Ascention Is., St Helena</option>
    <option value='-1'>(GMT - 1:00 hours) Azores, Cape Verde Islands</option>
    <option value='0' selected='selected'>(GMT) Casablanca, Dublin, London, Lisbon, Monrovia</option>
    <option value='1'>(GMT + 1:00 hours) Brussels, Copenhagen, Madrid, Paris</option>
    <option value='2'>(GMT + 2:00 hours) Kaliningrad, South Africa</option>
    <option value='3'>(GMT + 3:00 hours) Baghdad, Riyadh, Moscow, Nairobi</option>
    <option value='3.5'>(GMT + 3:30 hours) Tehran</option>
    <option value='4'>(GMT + 4:00 hours) Abu Dhabi, Baku, Muscat, Tbilisi</option>
    <option value='4.5'>(GMT + 4:30 hours) Kabul</option>
    <option value='5'>(GMT + 5:00 hours) Ekaterinburg, Karachi, Tashkent</option>
    <option value='5.5'>(GMT + 5:30 hours) Bombay, Calcutta, Madras, New Delhi</option>
    <option value='5.75'>(GMT + 5:45 hours) Kathmandu</option>
    <option value='6'>(GMT + 6:00 hours) Almaty, Colombo, Dhaka</option>
    <option value='6.5'>(GMT + 6:30 hours) Yangon, Naypyidaw, Bantam</option>
    <option value='7'>(GMT + 7:00 hours) Bangkok, Hanoi, Jakarta</option>
    <option value='8'>(GMT + 8:00 hours) Hong Kong, Perth, Singapore, Taipei</option>
    <option value='8.75'>(GMT + 8:45 hours) Caiguna, Eucla</option>
    <option value='9'>(GMT + 9:00 hours) Osaka, Sapporo, Seoul, Tokyo, Yakutsk</option>
    <option value='9.5'>(GMT + 9:30 hours) Adelaide, Darwin</option>
    <option value='10'>(GMT + 10:00 hours) Melbourne, Papua New Guinea, Sydney</option>
    <option value='10.5'>(GMT + 10:30 hours) Lord Howe Island</option>
    <option value='11'>(GMT + 11:00 hours) Magadan, New Caledonia, Solomon Is.</option>
    <option value='11.5'>(GMT + 11:30 hours) Burnt Pine, Kingston</option>
    <option value='12'>(GMT + 12:00 hours) Auckland, Fiji, Marshall Island</option>
    <option value='12.75'>(GMT + 12:45 hours) Chatham Islands</option>
    <option value='13'>(GMT + 13:00 hours) Kamchatka, Anadyr</option>
    <option value='14'>(GMT + 14:00 hours) Kiritimati</option>
    </select><br />
    <!-- information more specific to the user and their interaction with this site -->
    <h2>Personal Information</h2>
    Country:<br /><input type="text" name="country" /><br />
    City:<br /><input type="text" name="city" /><br />
    Profession:<br /><input type="text" name="job" /><br />
    Degree:<br /><input type="text" name="degree" /><br />
    <h3>Area of Specialty:</h3>
Computers<br /><br />

<a class="pointer" onclick="toggleMenu('graphics')">Graphics and Video</a>
<div name="graphics" class="mL">
<ul>
<li>Photoshop<input type="checkbox" name="graphics" value="photoshop"/></li>
<li>Paintshop Pro<input type="checkbox" name="graphics" value="paintshop"/></li>
<li>Adobe Flash<input type="checkbox" name="graphics" value="flash"/></li>
</ul>
</div><br />
Hardware<br />
Programming<br />
Sound<br />
Networks<br />
Other<input type="text" name="other" /><br />
<input type="submit" name="register" value="Register">
</form>
<?php } ?>
</body>
</html>

passenc.php is used to creat the salt, store it, and retrieve it:

PHP Code:

<?php
//This function is included by register.php
//This function is used to create the salt and store it in a seperate file
function passenc()
    {
    //declares the variable salt
    $salt="";
    //runs through the loop 30 times meaning that a string of 30 charaters will be the end result
    for ($i=1; $i<=30; $i++)
        {
        //randomly chooses a number between 32 and 126 which corresponds with normal english language ascii codes
        $int=rand(32, 126); 
        //converts the randomly generated interger into a character and then adds it to the salt string
        $salt=$salt.chr($int);
        }
        //pre-hases the salt with md5 to make it even more random
        $salt=md5($salt);
        //sends the completed salt back to register.php
        return $salt;
    }
//This function is included by register.php
//This function adds the salt to a seperate table and database along with the primary key (id) or the corresponding row of the userdb so i tcan be matched back up.
function savesalt($id,$salt)
    {
    mysql_query("INSERT INTO salt (userdbID, salt) VALUES ('$id','$salt')");
    }
//This function is included by login.php and is used to retrieve the salt from the database to validate password
function retsalt($id)
    {
    $result=mysql_query("SELECT salt FROM salt WHERE userdbID='$id'");
    $row = mysql_fetch_array($result);
    return $row['salt'];
    }
?>

This is login.php. I had it redirecting to some test page but it wont redirect because I am calling it as a function after the page has already been loaded, I need to figure out a new way to do this.

PHP Code:

<?php 
//this function is called once the login has been verified
/*function redirect()
    {
    $host  = $_SERVER['HTTP_HOST'];
    $uri   = rtrim(dirname($_SERVER['PHP_SELF']), '/\\');
    $extra = 'topsecret.php';
    header("Location: http://$host$uri/$extra");
    }
    //starts a session
    session_start();*/
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<?php
// WEBSITE STARTED AUGUST 10th 2008
//import global variables: primarily database connection information
include "variables.php";
include "passenc.php";
//sets flag as 0 to be used for validation
$flag=0;
//checks to see whether or not the user has submitted the login form
if (isset($_POST['loginsubmit']))
    {
    echo "loginsubmit";
    $dbusername=mysql_real_escape_string($_POST['uname']);
    $flag=0;
    }
//checks to see whether or not the user has a cookie initialized
elseif (isset($_SESSION['uname']))
    {
    $dbusername=mysql_real_escape_string($_SESSION['uname']);
    $flag=0;
    }
//if neither are true then flag is set to 3 as an error catch
else
    {
    $flag=3;
    }
//if the flag is 0 (meaning that they either have a current session or they have submitted the login form)
if ($flag==0)
    {
    $result = mysql_query("SELECT * FROM userdb WHERE uname='$dbusername'") or die(mysql_error());
    $row = mysql_fetch_array($result);
    $dbusername=$row['uname'];
    $password=$row['pass'];
    $userID=$row['idnum'];
    $email=$row['email'];
    $salt=retsalt($userID);
    if (strtoupper($dbusername)==strtoupper($_POST[uname]) && $password==hash("sha512",(md5($_POST['pass'].$salt))) && isset($_SESSION['user'])!=1)
        {
        $_SESSION['ip']=$_SERVER['REMOTE_ADDR']; 
        $_SESSION['uname']=$dbusername;
        $_SESSION['userID']=$userID;
        echo "LOG IN SUCCESSFUL";
        //redirect();
        $flag=0;
        }
    elseif ($dbusername!="" && strtoupper($_SESSION['uname'])==strtoupper($dbusername) && $_SESSION['ip']==$_SERVER['REMOTE_ADDR'])
        {
        //redirect();
        $flag=0;
        }
    else{
        $flag=2;
        echo "error";
        }
    }
    ?>

<form name="login" action="login.php" method="post" autocomplete="off" enctype="application/x-www-form-urlencoded">
username<input type="text" name="uname" /><br />
pass<input type="text" name="pass" /><br />
<input type="submit" name="loginsubmit" />
</form>

And then finally my terrible logged in page topsecret.php

PHP Code:

<?
//this page needs incredible amounts of work because its not secure
session_start();
if (!isset($_SESSION['ip']))
    {
    echo "GET OUT";
    }
elseif ($_SESION['ip']==$_SERVER['REMOTE_ADDR'])
{
echo "you are looking at the worlds most top secret page!<br /><br />";
}
else
{
echo "GET OUT";
}
//ill deal with the logout later, just destroy the session
?>
<a href="">Logout</a>

I know that is alot of code but any suggestions would be awesome, especially on how best to verify who they are after they have already logged in.

Thanks so much!

Overall it looks ok. And, thanks for posting your code. Now others can have something from which to work. 3 things:

1) $salt is not initialized during login (or I'm missing it), so the login above should not work, but once you do that, it should be ok.

2) What are you trying to do with topsecret.php?

3) With all of the error checking you have in place, why do an "or die()"? Catch the error and let the user know to try again later.

4) OOHHHH... EDIT: Need to add this. Don't store the username in the cookie. That gives a hacker 1/2 the problem they need to solve for that user. Make it something wild and store in the database (or have it be another hash). ... Actually, just read it closer, you call it a cookie, but it's actually a session variable. That whole methodology seems corrupted. Can you describe what you were thinking?

You may want to look at http://www.webmaster-talk.com/php-fo...member-me.html (I have a post on there worth reading too) for some added features.

Ya hopefully this thread will help out others as well.

1) It is initialized. $salt=retsalt($userID); retsalt is a function in the included document passenc.php. I just have it all in that file to make things cleaner for me.

2) topsecret.php is just my attempt to make the next step in the login process, a page that you can only see if logged in, I dont fully understand how to go about doing this. What is the best way to check to make sure that people have actually logged in? Right now I am just checking the session IP against their current IP but that cant be a good way at all.

3) Good idea I will do that

4) Ya I need to change that (read your other post, helpful). I thought you shouldnt use cookies for logins. Dont sessions just store a reference cookie on the users computer and keep all the information on the server. Doesnt that make the information marginally more secure?

This kind of goes with #2 as well, but how do you check? You just have a id number (different from the primary key that the database uses) and store that in a cookie and make sure that it matches up and if it does you assume they have been correctly logged in and you let them in? Couldnt someone recreate that cookie then? I think Im missing something here .

Thanks again for all your help so far.

Originally Posted by Truly

Ya hopefully this thread will help out others as well.

1) It is initialized. $salt=retsalt($userID); retsalt is a function in the included document passenc.php. I just have it all in that file to make things cleaner for me.

Great. That's what it needed and I didn't see it.

Originally Posted by Truly

2) topsecret.php is just my attempt to make the next step in the login process, a page that you can only see if logged in, I dont fully understand how to go about doing this. What is the best way to check to make sure that people have actually logged in? Right now I am just checking the session IP against their current IP but that cant be a good way at all.

Use something like:

PHP Code:

if ((int)$_SESSION['userID'] > 0) {
 //User is logged in
} else {
 //User is not logged in.
} 


Originally Posted by Truly

3) Good idea I will do that

4) Ya I need to change that (read your other post, helpful). I thought you shouldnt use cookies for logins. Dont sessions just store a reference cookie on the users computer and keep all the information on the server. Doesnt that make the information marginally more secure?

Sessions are good for storing this information. For greater security, look into database-saved sessions. I was confused reading the code.

Originally Posted by Truly

This kind of goes with #2 as well, but how do you check? You just have a id number (different from the primary key that the database uses)

Not sure what you mean by varying from the primary key in the database. I assign an UNSIGNED AUTOINCREMENT value to the primary key of most tables and use that as the unique identifier for validation purposes. I always call it tablename_id, but you can call it whatever you want so long as you remember what it's good for.

Originally Posted by Truly

and store that in a cookie and make sure that it matches up and if it does you assume they have been correctly logged in and you let them in? Couldnt someone recreate that cookie then? I think Im missing something here .
Thanks again for all your help so far.

Let me explain. Currently, on successful login, you set the username and id in to the session. That's fine (the IP doesn't need to be put in the session as it's available on each page anyway). You can then validate whether the user is logged in by using the code I provided above. Cookies can be used for persistent, "remember me" login features. That's what I thought you may be trying to do and why I referenced the other thread which talks about the security of the cookie to help protect against hacking. Some people will also assign a random id to the user in the database and update this when they visit the page and have the "remember me" feature selected, but that makes it complicated b/c they may be on multiple computers so remember me would only work on one of them at a time unless you store a collection of them and clean up. Much easier to just use the stuff posted in the referenced thread.

Hope that helps! Again, thanks for sharing your code for everyone to learn from.

Sorry more questions for you . When I do eventually finish this I would like to document it really well and post it for others to learn from / use.

You only check to see if the userID has been set? That seems very insecure, isnt it possible for someone to create a fake session? Or because a session is stored on the server they wont be able to get at it to change anything?

I found this link about database saved sessions: http://www.raditha.com/php/session.php
I havent tried it yet but hopefully it will work out. It has example code which should be helpful. Just so I can wrap my head around how this works, all the information is stored in a database and then a cookie on the users computer references the row in the database and eventually I guess it expires and is removed from the DB. Do you think this is worth using, does it substantially increase the security?

My only question about the key was whether tablename_id should be drastically different from it but since you are using autoincrement you probably just choose a different starting number and let it go. I was just wondering if its bad to give out the value of the primary key.

Once again thanks for all your help.

Originally Posted by Truly

Sorry more questions for you . When I do eventually finish this I would like to document it really well and post it for others to learn from / use.

You only check to see if the userID has been set? That seems very insecure, isnt it possible for someone to create a fake session? Or because a session is stored on the server they wont be able to get at it to change anything?

So long as register globals is off or your reference by $_SESSION[''], this is a safe method. The only one who populates that value is you, so you can trust it and I always choose to work with numbers where I can b/c computers do better with numbers.

Originally Posted by Truly

I found this link about database saved sessions: http://www.raditha.com/php/session.php
I havent tried it yet but hopefully it will work out. It has example code which should be helpful. Just so I can wrap my head around how this works, all the information is stored in a database and then a cookie on the users computer references the row in the database and eventually I guess it expires and is removed from the DB. Do you think this is worth using, does it substantially increase the security?

PHP still manages the session for database-stored sessions. It sets the cookie for you and calls your session handling functions. You just have to write the functions to save it to the database and retrieve the information.

So, why is it more secure? Session data is normally stored in files. Files accessible all over the server. Another user on your server may be able to access those files and extract the session data. However, if you've put it in the database, they won't be taking your stuff b/c they will need access to the database to get it.

Just another layer of security.

Originally Posted by Truly

My only question about the key was whether tablename_id should be drastically different from it but since you are using autoincrement you probably just choose a different starting number and let it go. I was just wondering if its bad to give out the value of the primary key.

Once again thanks for all your help.

No. No need to worry about this. Logins aren't based off of the primary key and nothing else should allow the PK as a validation method. See, if you give out the username and login is based off of the username, then 1/2 the problem is solved for a hacker. But, if the PK is exposed, how will they do anything with that? It's useless unless they can login as that user first.

Make sense?

BTW: I'm very busy right now prepping for our annual meeting, so my answers may take a few days.

As far as SSL goes, how much of a site can it be used for? You never see gmail or a forum using SSL, its reserved only for banking normally. Is there a reason besides the cost of buying the certificate? You would assume that these companies, with all of their money, would use SSL on every protected page just to make it more secure.

SSL can be used to connect to any part of your site. It is prudent to have it only encrypt pages which have private or sensitive data on them. And, it's not "normally" reserved for banking. SSL are most often used for protecting financial transactions (e.g. completing a cart purchase, signing into a sensitive area, etc). As for GMail, you may want to consider adding the 's' in the URL to ensure your data is encrypted.

So, why isn't everything encrypted? Encryption takes time and server resources. That's all.

Ok that makes sense.

Hey all.

I have just gone through Truly's script and found two things that I don't really think is right. Slap me if I am wrong please

Just wanted to check one thing with this neat script that Truly made.

PHP Code:

//pre-hases the salt with md5 to make it even more
salt=md5($salt); 


Wouldn't that quite effectivly make the salt less secure? From having a randomized number with rand(32,126)

You had 30 random chars from 32 to 126, now you have 32 random chars from 0 to 15

Also about the alternative with <form enctype="application/x-www-form-urlencoded"> to send data from client to server doesn't really make it more secure.

It's to avoid encoding trouble like people using utf8 and such things, every strange character will be converted in their hexadecimal value, so it won't be endommaged because of wrong encoding use. i mean, you send a "é", interpreted as unicode it will be translated into something like "€", and your result will be f**ked up

in a way it's safer because it is encoding quotes, but that should be done anyway.

As far as I know the only way to do the secure data transfer between user and server is to go into https and then when logged on drop back into http and stay logged on with sessions and/or cookies.

-Ghetto

Just wanted to post to this since it is a relevant subject to this thread.
Best form of Encryption(md5 ect..)