Jump to content

Best Login System Practice?


phprocker

Recommended Posts

Hey all.  I was curious what is the best practice when creating a user login system? I've seen them done in the following 2 ways.

 

First I've seen tutorials on logins where after the post data is verified against the database a username session is created and member pages are accessed if the user session is set.

 

Second I've seen tutorials on logins where the username session is verified against the database on every single page.

 

What is the best practice along these lines?

 

Cheers!

Link to comment
Share on other sites

When someone logs in, my query checks for 1 match in the DB for the same username and password.

 

I then insert a record in my session table with the username / session information, etc.

 

On each page, I make sure the Session ID variable equals the session ID in the DB, if not, redirect to log out page.

Link to comment
Share on other sites

I agree with coupe...

 

First, when they register, I salt their password. So say my salt is 'Sn00pDog123' - so I add that to the password they enter.

 

Say their password was 'fishsticks' so my code looks like this:

 

$salt = 'Sn00pDog123';
$rawPassword = $_POST['password'];
$saltyPassword = $_POST['password'] . $salt;

 

I then encrypt the password into a hash. Don't be afraid to use other than MD5 hashes, there's tons of cool ones. You can even re-encrypt an MD5 hash with another type. Real super secret squirrel stuff... helps prevent rainbow table attacks.

 

$hashedPassword = hash('sha256', $saltedPassword);

 

I shove that in the database for them. Then when they login and they enter "fishsticks" at the prompt, I add the salt to the end of that, hash it and THEN check it against the hash in the database. If they match and num_rows is only equal to 1, I pull their data out of the database and create some session variables...

 

$_SESSION['username'] = $username;
$_SESSION['loggedin'] = TRUE;
etc.
etc.

 

Anything you need to know about them on a regular basis just shove it in the session... also you can have a field in the database called 'session' and store their most recent session name in there, and every page load check that the session they are using matches what is in the database... if not, call your logout function and put them back to the login page and/or throw an error/exception.

 

Another way, which I like, if you are using MVC and a front controller is create a registry object and in that store an authentication object (using the registry pattern) and store the values in there, which I believe makes them less vulnerable to session attacks and cross site scripting etc...

 

This takes a while to fully understand but it is a great pattern:

 

http://www.sitecrafting.com/blog/php-patterns-part/

Link to comment
Share on other sites

I agree with coupe...

 

First, when they register, I salt their password. So say my salt is 'Sn00pDog123' - so I add that to the password they enter.

 

Say their password was 'fishsticks' so my code looks like this:

 

$salt = 'Sn00pDog123';
$rawPassword = $_POST['password'];
$saltyPassword = $_POST['password'] . $salt;

 

I then encrypt the password into a hash. Don't be afraid to use other than MD5 hashes, there's tons of cool ones. You can even re-encrypt an MD5 hash with another type. Real super secret squirrel stuff... helps prevent rainbow table attacks.

 

$hashedPassword = hash('sha256', $saltedPassword);

 

I shove that in the database for them. Then when they login and they enter "fishsticks" at the prompt, I add the salt to the end of that, hash it and THEN check it against the hash in the database. If they match and num_rows is only equal to 1, I pull their data out of the database and create some session variables...

 

$_SESSION['username'] = $username;
$_SESSION['loggedin'] = TRUE;
etc.
etc.

 

Anything you need to know about them on a regular basis just shove it in the session... also you can have a field in the database called 'session' and store their most recent session name in there, and every page load check that the session they are using matches what is in the database... if not, call your logout function and put them back to the login page and/or throw an error/exception.

 

Another way, which I like, if you are using MVC and a front controller is create a registry object and in that store an authentication object (using the registry pattern) and store the values in there, which I believe makes them less vulnerable to session attacks and cross site scripting etc...

 

This takes a while to fully understand but it is a great pattern:

 

http://www.sitecrafting.com/blog/php-patterns-part/

 

Yep. Just remember, this isn't even PART of securing a login system Lol. You can take precautions on the login.php page for them to actually login, or register / database etc. But things people dont think about a lot is.. session hijacking. I've taken about a week to actually write a really secure login system and it is nearly impossible to session hijack :)

Link to comment
Share on other sites

For one, if you're building a big site, use OOP and have an authentication class, and preferably use MVC and a front controller, so you can filter all page requests including logins thru that. That way, nothing gets missed... I also use PDO:: for my database connections to prevent injections.

 

Also, don't be dumb and call your $salt variable $salt, LOL... and put it in a config file above the web root, so that the file can't be accessed, I use this file for database info, salt, the few globals I use etc... maybe call it $snoopy or something but not $salt, too obvious.

 

Also never ask security questions on here and/or post code and then post your site's URL  :P

Link to comment
Share on other sites

For one, if you're building a big site, use OOP and have an authentication class, and preferably use MVC and a front controller, so you can filter all page requests including logins thru that. That way, nothing gets missed... I also use PDO:: for my database connections to prevent injections.

 

Also, don't be dumb and call your $salt variable $salt, LOL... and put it in a config file above the web root, so that the file can't be accessed, I use this file for database info, salt, the few globals I use etc... maybe call it $snoopy or something but not $salt, too obvious.

 

Also never ask security questions on here and/or post code and then post your site's URL  :P

 

yeah, I have a $Auth class set up :P

 

and @

Also never ask security questions on here and/or post code and then post your site's URL  :P

LAWL. That's true :P Some people have too much time on their hands :P lmao

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.