PHP Secure Session Login - Best Practice

Question

As part of my web app. This is some code I am considering (I'm not the best of PHP programmers but I programming my own app for a project):

// Start session
session_start();
// Is the user already logged in?
if (isset($_SESSION['username'])) {
    header('Location: members-only-page.php');
}

I want to know, if my login structure is like this, is this secure.

• http://site.com/
• https://site.com/login.php
• https://site.com/login-action.php (MySQL login check, with md5 password check)
• http://site.com/cp/members-only-page.php

I am using MD5(); but I am not entirely happy with the whole $_session["user"]="1" approach that scripts use; surely the likes of vBulletin wouldn't do this?

Appreciate a reply. I've not even touched on the idea of this being Ajax ha!

UPDATE - Psuedo code of my approach. Everything on SSL.

// vars
login string post
password string post

// validation aside from ajax now
login string is empty
redirect to login form with error
password string is empty
redirect to login form with error

// mysql
escape strings
clean html strings

mysql connect external mysql server
if login string is user
    if password md5 match with database md5
        session logged in
    else
        session failed password invalid
        redirect to login form user/pass error
    end if
else
    session failed username invalid
    redirect to login form user/pass error
end if

if file called direct
    redirect 404
    alert_admin function type hacking attempt login page
end if

Answer 1

1. mysql_real_escape_string() does not safeguard you from all forms of SQL Injection, or other types of attack for that matter. You should use a system in which incorperates code to guard against many safeguards individually, an example of such I use on my testing server (not strong enough for production):

   function sanitize($str)
   {
     $str = trim($str);
   
     if (get_magic_quotes_gpc())
       $str = stripslashes($str);
   
     return htmlentities(mysql_real_escape_string($str));
   }
   

Please read the accepted answer for this question to see why any way you filter user input is never full-proof.

--

As far as information about securing user logins, please consider the following tips:

1. Avoid user input whenever possible, and if impossible; sanitize their input.
2. Do not use only md5 for securing user passwords. It is easy to decrypt.
   • Consider using a password salt, unique to each individual user.
3. Keep your own passwords both long, and diverse.
   • Optionally extend these as suggestions to your users' passwords. Example:
     • Must be at least six characters in length.
     • Must consist of a mixed case of characters.
     • Must contain at least one number.
     • (Secure) Must contain at least one symbol.

Rationale and statistics about password strength:

I, (with a nVidia NVS 3100M mobile graphics card), can crack or "brute force" an MD5 or SHA1 hash at a speed of 56,900,000 passwords per second. This means I can complete all passwords of lengths 1 - 6 characters, with a full (a-zA-Z0-9 + symbols) character set; in less than four minutes. Imagine what someone with a decent computer (even a gaming one), or a server could do.

The way to safe against this is to salt your passwords. Depending on how you salt your passwords, the "attacker" would need to try many different means of decrypting before they would be able to guess any of your user's passwords. If your password was not salted, they could brute-force it in the way I have described above.

Read more about PHP Session Security:

PHP Security Guide - Session Security

PHP Session Security (StackOverflow)

Notes on Session Security (SitePoint)

Also Worth Nothing:

You need to decide what your website needs to be secured against. If your website is hosted on a shared server or shared hosting (whether it be a VPN, VPS, or some sort of semi-dedicated solution) you will always be at risk of other malicious users on the system having access to your PHP files, and by extension; your MySQL database. Even on a dedicated server, without proper internal network security you are just as screwed.