User Authentication and PHP Security

So far we have covered security vulnerabilities that involve form data, databases and file systems. In this article we are going to look at authentication and the security issues around it. We will also look at some of the most common attacks in this field.


So what is authentication all about? Authentication is the process by which a user’s identification is proven. This is usually done by checking the user’s password and username. This typically takes place in a login form. Therefore, when a user is logged in, he or she will be authenticated. After a user is authenticated, he or she will have access to a particular part of a web site or application (or possibly an entire web site or application). If we take the example of a blog, only the administrator will have access to the administration part of a blog, while a normal user will only be able to add comments on a particular topic. This method of allowing different users access to certain areas and denying others the same access is called authorization or access control.  

Authentication Methods

There are two primary ways in which users are authenticated:

  1. Normal log-in/register HTML form:

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "
    <form action="" method="POST">
        <p>Username: <input type="text" name="username" /></p>
        <p>Password: <input type="password"
    name="password" /></p>
        <p><input type="submit" /></p>

  2. HTTP Authentication

    HTTP authentication presents a user with a pop up box that requires a username and password to gain access. Some of the benefits of HTTP authentication include:

    • Very little PHP code required.
    • Entered username and password remembered without the need to use PHP to send cookies or establish sessions.
    • Clean interface that will not interfere with your page design.
    Now for some of the bad things about HTTP authentication, and probably part of the reason why it is not used as much as other forms of authentication:

    • Limits usability.
    • Inability to establish user groups or specify access levels.
    • Inability to set access levels.

{mospagebreak title=Security Vulnerabilities}

A predominant cause of access control vulnerabilities is carelessness given to the sections of a web application that are used the least. Administrative features and access control are often an afterthought, and they are written with an authorized user in mind, without considering what an attacker might try to do. An authorized user is trusted more than an anonymous user, but if your administrative features are available via a public URL, they are an inviting target to an attacker. In these cases, negligence is your primary foe.

As with security, access control needs to be integrated into your design. It is not something to be bolted onto an existing application. Although possible, this approach is very error-prone, and errors in your access control are necessarily security vulnerabilities.

Common Attacks

In this section we will be looking at some of the most common attacks used within the authentication and authorization field. The first type of attack is the brute force attack.

What is a brute force attack? A brute force attack is an attack in which all available options are exhausted with no intelligence regarding which options are more likely. This is more formally known as an enumeration attack because the attack enumerates through all possibilities.

In terms of access control,  brute force attacks typically involve an attacker trying to log in with a very large number of attempts. In most cases, known valid usernames are used, and the password is the only thing being guessed. This can go on and on until the attacker gets to the right password for a particular user name. Of course, the most obvious way to stop this kind of attack is to limit the number of times a user can try to log on or to limit the number of failures at login, but it would be even better to distinguish between a legitimate user and a attacker.

A typical login form would look something like this:

<form action="" method="POST">   
   <p>Username: <input type="text" name="username" /></p>
   <p>Password: <input type="password" name="password" /></p>
   <p><input type="submit" /></p>

What this form will do when submitted is send two very important pieces of information over to the login script (, the username and password. We already discussed how easy it is for an attacker to trick the login script into accepting a username and password that they themselves send, instead of the form. All that an attacker needs to do is write a script that will repeatedly send a password to the login script.

{mospagebreak title=Brute force attack continued}

Here’s a script that will repeatedly send a password to the login script, setting up the attack. 

    $username = ‘johndoe’;
    $password = ‘guess’;
    $content = "username=$username&password=$password";
    $content_length = strlen($content);

    $http_request = ”;
    $http_response = ”;

    $http_request .= "POST /login.php HTTP/1.1rn";
    $http_request .= "Host: noabeb.comrn";
    $http_request .= "Content-Type: application/x-www-form-urlencodedrn";
    $http_request .= "Content-Length: $content_lengthrn";
    $http_request .= "Connection: closern";
    $http_request .= "rn";
    $http_request .= $content;

    if ($handle = fsockopen(‘’, 80))
      fputs($handle, $http_request);

      while (!feof($handle))
        $http_response .= fgets($handle, 1024);


       /* Check Response */
      /* your error message here */


With such a script, an attacker can add a simple loop to continue trying different passwords, and $http_response can be checked after each attempt. When a change in $http_response is observed, the authentication credentials are expected to be valid. As I stated before, a good way to prevent or stop this kind of attack is to limit the number of failures at login. You can also put a timing limit at login  and suspend a user account if a user does not enter the correct login credentials in a given time period. The HTTP requests used in a brute force attack are pretty much the same every time, except for the password.

{mospagebreak title=Password Sniffing}

Although not specific to access control, when an attacker can sniff (observe) traffic between your users and your application, being mindful of data exposure becomes increasingly important, particularly regarding authentication credentials. To sniff out a password, an attacker would use a password sniffer to watch traffic between two or more computers. There are a lot of free password sniffers available on the Internet that will do the job just fine. This is made particularly easy by developers who use plain text when authenticating their users.

Some form of encryption will make it difficult for attackers to read passwords. So, using SSL is an effective way to protect the contents of both HTTP requests and their corresponding responses from exposure. Any request for a resource that uses the https scheme is protected against password sniffing. It is a best practice to always use SSL for sending authentication credentials, and you might consider also using SSL for all requests that contain a session identifier because this helps protect your users against session hijacking.

To protect a user’s authentication credentials from exposure, use an https scheme for the URL in the form’s action attribute as follows:

<form action="" method="POST">
  <p>Username: <input type="text" name="username" /></p>
  <p>Password: <input type="password" name="password" /></p>
  <p><input type="submit" /></p>

Although this is all that is required to protect a user’s authentication credentials from exposure, you should also protect the HTML form itself with SSL. There is no technical reason to do so, but users feel more comfortable providing authentication credentials when they see that the form is protected with SSL.

The last type of attack that we are going to look at is called a replay attack. A replay attack, sometimes called a presentation attack, is any attack that involves the attacker replaying data sent previously by a legitimate user in order to gain access or other privileges granted to that user. To prevent replay attacks, you want to make it very difficult for an attacker to capture any data that can be used to gain access to a protected resource. This primarily requires that you focus on avoiding the following:

  • The use of any data that provides permanent access to a protected resource.
  • The exposure of any data that provides access to a protected resource (even when the data provides only temporary access).

So, to effectively prevent relay attacks, minimize data exposure and also make sure that clear text transmission of usernames and passwords is avoided.


In this article we focused on user authentication and authorization. And we also looked at various attacks that relate to this category and ways to prevent or make it difficult for the attacker to achieve their aims. 

[gp-comments width="770" linklove="off" ]

chat sex hikayeleri Ensest hikaye