Secure login in PHP

Posted on December 13, 2007 Categories: Search

post author

Written by: Jan

Jan is an eccentric Slovakian SEO wizard. When he's not researching search, optimising sites, building inbound links, or working on content creation, he's a part-time professor, teaching PHP to his students at university.

The problem’s description

Asking a user for his password through any HTML form creates a potential vulnerability within the web application. Since the script has to compare the data provided by the user with the data stored in the database, the login and password must be sent to the server somehow. In theory, it would be possible for a hacker to listen to such a communication bridge.

Sponsored links

The solution

There are a few methods of encryption which help the developer keep the application secure. However, the encryption must be done on the client side. This is why the md5 (or anything similar) function can’t be called from the PHP script. Basically, PHP scripts are running on the server side and what’s interpreted on the server must have been sent to it via packets. Bear in mind that using encrypted passwords in the database helps to increase the security level as well, though it doesn’t solve the problem with login forms.

In fact, there are only really two ways to secure a login form. Firstly, we can use JavaScript to encrypt the password (and preferably any other information provided by the user) before the data from the user’s PC is sent to the server. Although it seems to be good idea, it doesn’t work effectively under every web browser. Some browsers simply encrypt required fields twice.

So the only way how to ensure safe logging in is via SSL. Remember that SSL doesn’t guarantee 100% security, and it must be used correctly in order to maintain security. First of all, the form containing the login and password fields must be sent through a URL which starts with https://. Sometimes people are lazy to use the HTTP protocol, even though they claim that the login will be secured with SSL.

Secondly, every form must point to a https page as well. There is no point using SSL for login purposes only. Say that your login is secured, but your financial information is available through the ordinary HTTP protocol. Your communication bridge is still vulnerable.

Once these two basic requirements are met, you should ensure that every cookie which is stored on the user’s PC was created as available for SSL only. The secured cookie is defined as 1 and the unsecured cookie is defined as 0. Here is the example:

setcookie(”TestCookie”, $value, time()+3600, $path, $domain_name, 1);

The advantage of secured cookies is that they can only be read by scripts which are opened via HTTPS.

The last important point refers to scripts and forms which are called within the page (accessed from HTTPS) from the HTTP protocol. Some JavaScripts and forms may point to HTTP pages: for example, if you’re using Google Analytics, there are two versions of the tracking code. The first is designed for HTTP pages and the second one is designed for usage with HTTPS. Moreover, people may get warning messages if you’re using, for example, Google Analytics for HTTP on HTTPs URLs. This can be turned off, but many people don’t know how to do so.

Bear in mind that if your site is available via both HTTP and HTTPS protocols, you should always redirect the logged-in user from HTTP to HTTPS, and ordinary visitors should be redirected from HTTPS to HTTP pages. Some exceptions may exist, of course.

Apart from SSL, passwords should be the “password” type, not the “text” type. For example:

<input name=”login” type=”text” />

<input name=”passwd” type=”password” />

Using the include function, variables and access

The include function can be used, but every secured page should be available as a standalone script. The include function is one way to make things easier. There is one important aspect of keeping the PHP files secure: say that someone knows the names of your scripts. Now they can be called directly from web browser window. In order to prevent hacks this way, simply compare some variable which is defined in the beginning of public scripts.

Here’s just one example: The index.php file required the secure.php file.

index.php’s content:

<?

$security_string = “some string”;

?>

secure.php’s content:

<?

if($security_string==”)
exit();

?>

Follow us:

Leave a Reply

Archive

July 2010

June 2010

May 2010

April 2010

March 2010

February 2010

January 2010

December 2009

November 2009

May 2009

April 2009

March 2009

February 2009

January 2009

December 2008

November 2008

October 2008

September 2008

July 2008

June 2008

March 2008

February 2008

January 2008

December 2007

November 2007

October 2007

About Us

A team of nerds, creatives and strategy ninjas based in central London, building websites, social networks, widgets and social media apps.

We have a portfolio that is good enough to make a male peacock blush, and some killer outside-the-box products...in a box.
Ask us a Question

Blog posts