How long will a PHP login $_SESSION last?

Pedroski · 02-09-2020, 05:42 PM

Coz of this virus here in China, our new term will not begin on the 17th Feb. School will remain closed. My boss asked me to try and do class online.

The students have to login. This is not really because of security, no sensitive data here. I use the login to catch attendance in mysql:

Code:

include $_SERVER['DOCUMENT_ROOT'] . '/includes/studentdbReadfrom.inc.php' ;
	try
  {
	 // attendance will not increase with multiple logins. Before next week, reset has_been_incremented to zero  	
  	 $sql = 'UPDATE 19BEattendance SET attendance = attendance + 1, 
  	 has_been_incremented = has_been_incremented + 1, time = LOCALTIME() 
  	 WHERE number = ' . $_POST['password'] . ' AND has_been_incremented != 1 ;';
    $pdo->exec($sql);
      }

This stuff is all new to me, I'm learning it on the fly!

How long will a login session last?

Where can I set it to 100 minutes? That would be our normal 2 class periods + 10 minutes break.

michaelk · 02-11-2020, 03:56 PM

Not a PHP expert but since no one has replied yet.

By default a session is 1440 seconds i.e. 24 minutes which is defined by the session.gc_maxlifetime value. How garbage cleaned is also determined by session.gc_probability and session.gc_divisor.

There are various ways to write PHP code for an activity timer using session variables which might be better then letting the garbage collector automatically do it. Be sure to adjust the maxlifetime to greate then 100 minutes.

boughtonp · 02-11-2020, 05:20 PM

Quote:

Originally Posted by Pedroski

This is not really because of security, no sensitive data here.

There will be no data at all when a student realizes they can inject their own SQL into your queries.

Always use parameterised queries.

Pedroski · 02-11-2020, 11:36 PM

I also am not an expert on mysql or php, but I do not think an injection attack is possible here:

$sql above only contains input from the student if

Quote:

$password = md5($_POST['password'] . 'allstudentsdb');

is found in the database. The MD5 of a lump of sql code would probably not be found in the database.

No password, no increment. It just increments the attendance.

The login page contains student input, but that is handled like this:

Quote:

$sql = 'SELECT COUNT(*) FROM 19BE1
WHERE name = :name AND password =

assword';
$s = $pdo->prepare($sql);
$s->bindValue(':name', $name);
$s->bindValue('

assword', $password);
$s->execute();

No direct input. The input is not parsed by mysql.

That's my amateur understanding of this. Always grateful for tips though!

dugan · 02-12-2020, 01:47 AM

Quote:

Code:

WHERE number = ' . $_POST['password']

Are the students all using their student number as their password?

Pedroski · 02-12-2020, 02:45 AM

Yeah, all students use their student number. They would forget any other PW.

This

Quote:

WHERE number = ' . $_POST['password']

only comes after the password has been found. If it were a lump of sql code, the password would not be found.

Quote:

function databaseContainsStudent1($name, $password)

would return false and the code in #1 would never happen, because the else clause happens then.

boughtonp · 02-12-2020, 08:09 AM

Quote:

Originally Posted by Pedroski

only comes after the password has been found. If it were a lump of sql code, the password would not be found.
would return false and the code in #1 would never happen, because the else clause happens then.

That might be accurate in this specific situation, but is exactly the sort of reasoning that causes SQL injection vulnerabilities, when a tired developer overlooks ways around their protections, or a junior developer inadvertently changes something which bypasses them, or whatever.

Mistakes happen, and the best way to guarantee that SQL cannot be inserted is to never insert user-derived input into a query, and the easiest way to do that is to always parameterise queries.

Even ignoring the parameterising, it should be easy to change your initial query from COUNT(*) to return the unique student number, and then use that variable to update their attendance - then you're not using user input directly (I'd still parameterise it), but it also has the added benefit of the code being less brittle, such as for when the requirement to allow passwords to be changed comes along.

Quote:

Originally Posted by Pedroski

...MD5...

MD5 is broken and should not be used in any capacity.

For PHP you can use password_hash which uses the bcrypt algorithm.

Since your passwords aren't secret you can just do a single update to switch them all over (in other systems it's necessary to wait for users to login before verifying, re-encoding with a more secure algorithm, then replacing the hash).