PHP Secure Login Tips And Tricks

Every website on the internet faces a similar threat, hackers. Every single website can be a target of a hacker if security measures aren't implemented properly especially when it comes to login pages where our most sensitive data are being held. Hence, there is a need to better understand how well your login page has been implemented to be considered as really secure. In this article, you will get a list of PHP secure login tips and tricks that will definitely help you decide on your secure rating of your login page.

Length Of your username and password

Both your username and password should be at least 6-8 characters long. A longer combination of username or password will make brute force attack or any other password cracking algorithm longer to crack. This can really help your network administrator to detect an attack before the attack penetrates through your login page.

Encrypt your password

We all know that encryption is necessary in term of any password. But i would still like to stress such importance. We are very dependent on encryption algorithms such as MD5 or SHA-1. However, these two algorithms are no longer that secure as compared to the older days. On Wednesday, February 16, 2005 SHA-1 has been broken by three china researchers. Although it is more towards collision attack rather than pre-image one we can assure one thing is that SHA-1 can be broken. You can read more about it on Bruce Schneier article. On the other hand, you can find MANY MD5 cracker online nowadays through Google. eg. md5crack.com. But similarly they are all collision attacks.  Wiki explains MD5 vulnerability in a way you will be discouraged from using it. It is time to encrypt your users password using SHA-2 such as sha256, sha384, sha512 or better. If you are using PHP 5.12 or above, there is a new function, hash that supports SHA-2.

$phrase = 'This is my password';
$sha1a =  base64_encode(sha1($phrase));
$sha1b =  hash(’sha1′,$phrase);
$sha256= hash(’sha256′,$phrase);
$sha384= hash(’sha384′,$phrase);
$sha512= hash(’sha512′,$phrase);

For people who are using PHP 5.12 and below, you can try to use mhash which is an open source class for PHP.

$phrase = 'This is my password';
$sha1a =  base64_encode(sha1($phrase));
$sha1b =  base64_encode(bin2hex(mhash(MHASH_SHA1,$phrase)));
$sha256= base64_encode(bin2hex(mhash(MHASH_SHA256,$phrase)));
$sha384= base64_encode(bin2hex(mhash(MHASH_SHA384,$phrase)));
$sha512= base64_encode(bin2hex(mhash(MHASH_SHA512,$phrase)));

SHA-2 should be used to secure your future application. Although MD5 and SHA-1 can still be used for authentication purposes with a very secure password combination. eg. (eQ@xC#Eif2dsa!e2cX2?"}23{D@.

NOTE**: NEVER DOUBLE HASH!

Double hashing is *worse* security than a regular hash. What you’re actually doing is taking some input $passwd, converting it to a string of exactly 32 characters containing only the characters [0-9][A-F], and then hashing *that*. You have just *greatly* increased the odds of a hash collision (ie. the odds that I can guess a phrase that will hash to the same value as your password).

sha1(md5($pass)) makes even less sense, since you’re feeding in 128-bits of information to generate a 256-bit hash, so 50% of the resulting data is redundant. You have not increased security at all.

Credit goes to Ghogilee

****updated on 8 Oct 09

On the note of Ghogilee, i found a few errors which i would like to point out. Double hashing here is referring to two different hash function.  It does reduce the search space but doesn't *greatly* increased the odds of a hash collision.  On the other hand, SHA-1 should be a 160-bit hash not 256-bit and not only does this doesn't increased the security but also weaken the hash function as the hacker will only required to crack the weaker hash function in this case md5.

You may want to visit Better Hashing Password in PHP for more information. If you wish to understand the risk and stuff you can do with hash function, please visit Enhance Security Hash Function For Web Development. Here i document the most detail hash function i could for your information.

Enhance Hash With Salt

Once you have decide your secure password encryption algorithm, the last thing you might want is to have different user having the same encryption algorithm hash code. This can bring another problem of more than one account being compromised at the same time when there are multiple same hash and short password can easily be cracked with ease when your database and tables have been known. We can generate a salt in order to overcome this problem so that the string is longer and more random (providing that the salt + password are random enough).

define('SALT_LENGTH', 15);
function HashMe($phrase, &$salt = null)
{
$key = '!@#$%^&*()_+=-{}][;";/?<>.,';
    if ($salt == '')
    {
        $salt = substr(hash('sha512',uniqid(rand(), true).$key.microtime()), 0, SALT_LENGTH);
    }
    else
    {
        $salt = substr($salt, 0, SALT_LENGTH);
    }

    return hash('sha512',$salt . $key .  $phrase).$salt;
}

The above function contains two parameters. The first will take in a phrase and generate a SHA-2 salt if the second parameter is placed with an empty variable. However, if both parameters contain values, it will be used when you wish to compare between two hashes. We can use the above method this way,

$username = cleanMe($_POST('username'));
$password = cleanMe($_POST('password'));
$salt = '';
$hashed_password = HashMe($password, $salt);
$sqlquery = 'INSERT INTO  `usertable` ("username", "password", "salt") VALUES  ("'.$username.'", "'.<d>$hashed_password .'", "'.$salt.'") WHERE 1';
..

The above will insert the information into the table when user is being created. We will check the user with the following salt.

$username = cleanMe($_POST('username'));
$password = cleanMe($_POST('password'));
$salt = '';
$sqlquery = 'SELECT `salt`, `password` FROM  `usertable` WHERE `username` = "'.$username.'" limit 1';
..
#we get the data here and placed into variable $row
$salt = $row['salt'];
$hashed_password = HashMe($password, $salt);
if($hashed_password  == $row['password']){
#verified
}
else{
#ACCESS DENIAL
}
..

The objective of salt is to lengthen the password in the table and also create a totally random hash code for each password. Hence, even if your table is being compromised, it will really take a lot of time for them to crack those hashed password. (We are assuming login page already implemented protection against multiple false log in)

Do not use easy guess username for administrators

It is always wise to use a slightly more challenging username for any administrators on your system. Username like 'admin', 'root' or 'super' will surely be the one on the hacker list to determine any administrator username. Be smart! Use something more challenging such as 'iamtheking' as a username instead (if your login system is case insensitive).

Log user login attempt

It is actually wise to log every important event in a system. Definitely, login page is one of them. We can determine whether any attempt of attack on our system is being carry out with a proper logging system. The log file or table can be very useful to track back what had gone wrong during a specific time frame when an attack occurs to determine whether an attack was launched to determine whether the login page was compromised.

Handle Error

It is important to prevent any error from being displayed to malicious users. These information is very useful for them to determine how to break into your system. Hence, they will try any type of value in order to break your PHP functions. Therefore, an ampersat symbol (@) should be placed in front of any function to prevent an error from occuring. On the other hand, you can use the function mention on Solutions to SQL Injection Attack which uses die to generate a better SQL error message that can be both professional and at the same time log your errors. The function is shown below,

function sql_failure_handler($query, $error) {
	$msg = htmlspecialchars('Failed Query: {$query}<br>SQL Error: {$error}');
	error_log($msg, 3, '/home/site/logs/sql_error_log');
	if (defined(‘debug’)) {
		return $msg;
	}
	return 'An error occurs, please try again later.';
}

#query=test;DELETE FOM breakplease;
$query = 'SELECT * FROM user WHERE name ='. base64_decode($_GET['query']);
mysql_query('$query) or die(sql_failure_handler($query, mysql_error()));

Always filter user input

Remember on the articles Solutions to SQL Injection Attack and Solutions to Cross-Site Scripting (XSS) Attack which mention that filtering user input is very important as hackers will use any way to break your login system. The rule is to never TRUST your user input until every last verification gets through. You can use the following function in PHP for your filter assistance,

htmlentities()
strip_tags ()
utf8_decode ()
htmlspecialchars()
ctype_digit()
ctype_alnum()
stripslashes()
str_replace()

Be Innovative Not Informative

We must be innovative on the message we present to our users whenever an error or login fail occurs. Message such as 'invalid password' or 'invalid username' is bad practices that gives information to malicious user what they went wrong. Instead, provides something like 'Login Fail. Please try again' will be a much more appropriate approach.

USE LIMIT or WHERE 1

In SQL query, for any login attempt, always place a LIMIT 1 at the end of your SQL statement. If there is a chance where a successful SQL injection is performed, only one account is being compromised instead of all. On the other hand, using WHERE 1 can help prevent any additional SQL query from placing at the front of your where clause.

Check HTTP Referrer

The basic of every security check is to ensure that the HTTP referrer came from the form on your site. If the HTTP referrer is suspicious, reject the request immediately. Although, HTTP Referrer can be easily spoofed with JavaScript it is always good to have any form of protection on a login page. However, some firewalls or proxies strip this information out which will caused many of your users to be unable to login successfully. Hence, you might want to consider whether to implement such checking for your login system.

Nonce authentication

Another better way of authenticating than checking the HTTP Referrer is to use acryptographic nonce. A nonce is a number used once, and it is used for intention verification purposes. Think of it as a password for THAT particular form and only can be used once. It really depends on how you implement your Nonce between the client and server.

Use maxlength

It is definitely a great idea to only allow a maximum length of characters user can placed on an input box. This is like a restriction placing in front of malicious user to provoke their creativity in order to penetrate your system. However, you might not like this idea too as it minimize the number of combination for hackers to crack your login page. Personally i will place such restriction as my login page will never allow more than certain fail login.

$_POST ONLY

When dealing with any form data. The only answer is using $_POST. NO $_REQUEST or $_GET should be use as you are just making life easier for hacker and weaken your security. Although $_POST can still be used by hacker but it makes the job troublesome.

Sub String Not Trim

In a login page, it is best to secure ourselves. Hence, if a user made an error on their username or password, the system should not correct for them. If a user enters a username with leading or trailing space we are not going to trim it nicely for them before we check. On the other hand, we will sub string it out so that we are checking the maximum length that is being enforce on the text box.

MYSQL Accounts

It is important for any secure website to be cautious on the access given to MYSQL user account on the specific action. For login purposes, the only thing that the user allows to do is to retrieve data from MYSQL table. Hence, other actions such as delete, update, alter etc. should not be given to the login page. If a successful SQL Injection was launched on the site. Imagine the user updating your user account password to the one given. Our security measure will just kick us back to one. Hence, always be cautious on the access given to MYSQL user account.

Utilize IP

Always ensure that IP address is used together with session key after a user has logged into your portal. This can prevent Session attacks and at the same time ensure that the same person is viewing the content of your secure page. You can also use IP to ban certain users from trying to guess your login username or password upon certain tries. However, using IP may mean certain restrictions for certain companies or proxy users from accessing your website. Nonetheless, this can be solved by detecting their connection. You can use this script to detect whether they are behind proxy server

if (
      $_SERVER['HTTP_X_FORWARDED_FOR']
   || $_SERVER['HTTP_X_FORWARDED']
   || $_SERVER['HTTP_FORWARDED_FOR']
   || $_SERVER['HTTP_VIA']
   || in_array($_SERVER['REMOTE_PORT'], array(8080,80,6588,8000,3128,553,554))
   || @fsockopen($_SERVER['REMOTE_ADDR'], 80, $errno, $errstr, 30))
{
    exit('Proxy detected');
}

The above code should allows you to detect even anonymous proxy server.

*****Update 7 Oct 2009

I forgot to mention here that the above script will only be necessary if an IP address cannot be detected (Thanks Julius).

Utilize Cookies

I forgot to mention this important thing to you guys. There is also a need to tie cookie together with session and/or ip to prevent session hijack or cross-site request forgery (CSRF). The hacker might be able to hijack your session through different ways but cookies will still remind on your user client browser.

Cookies can also used for auto logout module by setting the expiry date of the cookie after 15 minutes and if the cookie doesn't exist, the user has been idle for 15 minutes. On the other hand, we can refresh this cookie every user activity. This is one of the many ways to implement auto logout functionality but this is not secure as the cookie can be stolen by hacker and prolong the duration of the cookie expiration time.

Lastly, we talk about locking user upon certain attempts but IP was difficult to be used. This can be solve by utilize cookie to set the number of tries performed by the user/browser. Using cookie is definitely insecure way of keeping track of user attempts but it also creates additional barriers for hackers to overcome. This should be used together with account lock functionality to prevent such weakness in your defense (this means cookie count and account attempts count should not be link together).

Auto Logged Out Mechanism

I forgot this one but one of the readers did not. Implementing an auto logged out mechanism onto your login system can really help prevent CSRF attacks. Since we can't control whether our user leave their account logged in while browsing or surfing the net, we can definitely cover their butt but having this mechanism up to prevent any CSRF or Session attacks. Since both attacks require the user to be logged in.

*****Update End

Lock upon certain fail attempt

This is something that most secure web pages should looked upon. A very good way of locking a user will be as follow,

1. n times fail attempt locked m minutes
2. n fail attempt due to 1. locked further m+30 minutes
3. n fail attempt due to 2. locked for the whole day

An example will be as follows:

• 3 times fail attempt locked 10 minutes
• 3 fail attempt due to 3 times fail attempt locked 10 minutes subsequence locked 10+30 minutes
• 3 fail attempt due to the above will result in whole day lock

You can lock a user based on IP or accounts. It will be better to lock them based on accounts IF proxy IP is unable to detect due to the fact that it is an anonymous proxy. IP should be used otherwise. This will prevent the user from guessing the correct username. On the other hand, if a username was guessed correct the same process can be applied and disabled the account by sending an email to the original author to reactive it. But the same message should be used. (not informative information!) If you are worry of blocking an entire proxy server or company employees, you can just go by account since breaking an account will required certain tries anyway.

SSL Encryption

No matter what you do on the above, without a secure line from the client to your server everything will be meaningless when it comes to packet sniffer which is also known as man in the middle attack. Especially for attacks such as Session Hijack. Password can be send directly into a hacker computer without the need to use brute force. The above mentioned methods definitely can stop newbies but not those that know their stuff. Without such encryption, getting your password won't be that difficult. Here's a video showing how easily it can be done without SSL encryption.

Summary

Any kind of system can still be compromised but the time and effort to compromised such system is another thing to be considered. The above mention methods are ways to make life difficult for hackers so that they will give up on penetrating your system. Hence, any little bit of security measure we can implement on our system is considered as a line of defense. There is never a bad thing by being paranoid in securing your web system. A website is like a man on an open field ready to be shoot at anytime! Do your website a favor. Wear a helmet. (not condom)