Which one is better for a Login system, Sessions of Cookies

[Andor]

**Sessions or Cookies

 

Hi,

 

As the title of the topic says... I'm working on a project and I need to make a login system for an admin panel. And I'm not sure which one to use. Sessions or cookies?

 

And an other question. I managed to make it so the login creates a coockie of the username and IP combined. But I don't know how I can call it. Since 

 

Here's my Login code that creates the cookies:

class auth {
	
	function user_info_check( $username, $password ) {
		
		global $db;
		
		$sql = "
			SELECT *
			FROM users
			WHERE username = '".$username."'";
		
		if(!$result = $db->query($sql)){
			die('There was an error running the query [' . $db->error . ']');
		}
		
		if ( $result->num_rows < 1 ) 
			die('Account dosen\'t exists');
		
		$row = $result->fetch_assoc();
		
			$pass1 = $row['password'];
			$user1 = $row['username'];
			$permission = $row['permission'];		
		
			if ( $username != $user1 ) {
	
				die('Account dosen\'t exists');
				
				}	
				
			if ( $password != $pass1 ) {
	
				die('Wrong Password');
				
				}	

			return array($username,$permission);
			
		}
	
	function login() {
		
		global $username, $password;
		
		// Returns the User's Username and Permission
		$info = $this->user_info_check($username,$password);
		
		setcookie($info[0]."-permission", $info[1], time()+3600);
		setcookie("user-".$info[0], $username, time()+3600);
		}		
}

The user_info_check() uses the username and password from the login form, to get the requested data, which is the username and permission.

 

But my problem is... if I create the session named "user-Andor" for example, Andor is the username, How can I call it if I don't have the username saved anywhere?

 

Thanks!

 

Edited November 14, 2013 by Andor

[Ch0cu3r]

Sessions uses cookies. The only difference being that sessions stores the data on the server.

 

If you use cookies then the user can easily modify the data stored. Where as with sessions the data is private, all the user sees will be the unique session token assigned to them. However if someone malicious gets access to this token then session hijacking can occur.

http://phpsec.org/projects/guide/4.html

http://stackoverflow.com/questions/12233406/preventing-session-hijacking

 

Personally I'd use sessions. Use cookies for non sensitive data.

Edited November 14, 2013 by Ch0cu3r

[Andor]

I see. Thanks! And also thanks for the Links. 

[KevinM1]

Why are you using 'global' in classes?  Why are you using 'global' at all?  

 

I can't believe that there are resources out there that use 'global'.  It's just mind-boggling.

[Andor]

I have a DB class that connects to the database and it's included into the called in the in the main file. Should I call it in each function instead?

[trq]

I have a DB class that connects to the database and it's included into the called in the in the main file. Should I call it in each function instead?

You should be passing your database dependency into the auth object when it is instantiated.

[Andor]

I see.  Well, I only started to work with classes and objects like 5 months ago. But I'll look into this, thanks!

[KevinM1]

I see.  Well, I only started to work with classes and objects like 5 months ago. But I'll look into this, thanks!

 

More to the point, you should never use 'global' at all.  Not in functions, not in class methods, nowhere.  The whole point of functions and objects (especially) is to create modular pieces of code that can be used in a variety of situations.  'global' ties your function or method to its environment, nullifying that modularity.  If a function or method needs data to complete its job, pass it through the argument list.  That's why it's there.  And if the resources (books, videos, tutorials) you're using to learn make use of 'global', consider them suspect and get better resources.

Edited November 14, 2013 by KevinM1

[boompa]

Using the suggestions given in this thread, your class should look something like this:

 

 

<?php

class auth {

    private $db;

    public function __construct($db) {
        $this->db = $db;
    }

    private function user_info_check( $username, $password ) {
        $sql = "
            SELECT *
            FROM users
            WHERE username = '".$username."'";
        if(!$result = $this->db->query($sql)){
            die('There was an error running the query [' . $db->error . ']');
        }
        if ( $result->num_rows < 1 )
            die('Account doesn\'t exist');

        $row = $result->fetch_assoc();
        $pass1 = $row['password'];
        $user1 = $row['username'];
        $permission = $row['permission'];    
        if ( $username != $user1 ) {
            die('Account dosen\'t exists');
        }    
        if ( $password != $pass1 ) {
            die('Wrong Password');
        }    
 
        return array($username,$permission);
    }

    public function login($username, $password) {
        // Returns the User's Username and Permission
        $info = $this->user_info_check($username,$password);
        setcookie($info[0]."-permission", $info[1], time()+3600);
        setcookie("user-".$info[0], $username, time()+3600);
    }    
}

 

Other bad things in this include:

 

1. Saving passwords in cleartext in the database. You should be storing salted cryptographically-strong hashes; see password_compat for PHP 5.3 or 5.4, use the internal password hashing functions on 5.5+.

2. Putting permissions into a cookie which could be modified by the end-user, instead of using session variables which are stored on the server.

3. No obvious DB input validation/sanitization could lead to SQL injection attacks; your DB class may be doing some sanitization, but chances are it's still using the outdated, deprecated, and unsafe mysql_* functions under the covers. You should use PDO or [url=http://php.net/manual/en/book.mysqli.php]mysql[/il] with prepared statements to prevent SQL injection.