PHP login steps

Posted on 2013-09-28
Medium Priority
Last Modified: 2013-10-02
Hi everybody,

Can anybody just go over my codes for the login steps?

I have tried to make it secure, robust and up-to-date. Only put the necessary parts to make it easier to check so I don't need a debugging.
Just want to hear the comments and the parts which needs correction

I have also added the php.ini and htaccess if it is needed to check if something is weird.

Thank you very much!
Question by:myyis
  • 4
  • 3
LVL 111

Expert Comment

by:Ray Paseur
ID: 39530524
I'm not going to download and read thru six files (it's Saturday and I'm going to drink beer instead), but I can show you in one article how PHP client authentication is done.

If you follow those designs you will be on firm ground.

Couple of comments...  

Form tokens for security are completely worthless. Do not waste any time on these.

And lose this forever:

error_reporting (E_ALL ^ E_NOTICE);

Just choose error_reporting(E_ALL) and if your script reports errors, fix the code!

Author Comment

ID: 39534635
Thank you for you comment. I will split my question to get more attention.
I have read you articles and I can say that I see myself on the right way.

So I want to discuss with you only the login process.

1. About the token thing you say it is worthless.
What I am trying to do is forcing the user to go to the index page first if she wants to login. This prevents  an automated login attempt (sending email and psw data as URL parameters) targeting directly the login-process.php
Doesn't this help me for security?

2. In your article you create a unique key. Why do we need this. I did not get?

        $uuk = md5($uid . $pwd . rand());

Thank you again
LVL 111

Expert Comment

by:Ray Paseur
ID: 39535018
1. It is a law of HTTP that you must not change the data model on the basis of a GET-method request.  Let me try to explain that a little bit.

A GET-method request is made with URL parameters.  In PHP, these parameters are found in the $_GET array.  They may also be found in the $_REQUEST array, but using $_REQUEST is one of the important anti-patterns that should be avoided.  So your script should look into $_POST and use only the contents of $_POST when it changes the data model.  Adding a cookie to the client browser is like updating your data base -- it's the equivalent of changing the data model.  If you follow the guidance in the article about login, you will be able to password protect any page of your web site with a single line of code.

2. The Unique User Key is a data element that can be used to lookup a client's record in our data base of users.  It's there because the PHP session only lives for a relatively short period of time (like until the client closes the browser).  If you want to remember a client for a longer period of time, you need some kind of cookie that will have a longer life than the PHP session cookie.  The UUK provides that "hookup" between the client's browser and the server's data base.
Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions


Author Comment

ID: 39535117
Here there is an example to create a fake POST header.


<form action="http://yoursite.com/login.php" method="post">
<input type="text" name="username"  value="hahaha faked it!" />
<input type="text" name="password" value="hee hee you can't tell this is fake" />
<input type="submit">

1) As far as I see there is no security difference in practise between GET, POST or REQUEST. I have to check all type of user input. I do that with a PDO below:


function selectsqlp($sql,$arr) {

      global  $dbpdo;
      $q = $dbpdo->prepare($sql);
      $q-> execute($arr);
      }catch (PDOException $e) {
      $r = $q ->fetchAll();
      return $r[0];}

So for me Request or Post does not have a difference. What  you say about this?

2. If I don't use session tokens how will I avoid a fake POST? I did not see a precaution in the article you have sent.

Thank you.
LVL 111

Expert Comment

by:Ray Paseur
ID: 39535221
... there is no security difference in practise between GET, POST or REQUEST.
Ha!  Maybe that was "true" in 1995.  Today, an enlightened programmer would simply ignore the parts of the request that were unexpected.  Ignore $_GET, ignore $_REQUEST, look for acceptable information in $_POST.  You can avoid a fake POST request by sanitizing the contents of $_POST.  A form token is useless.  A CAPTCHA is somewhat useful.  A better approach is to accept only known good values for the request.  This is not something that is new or "rocket science."  It's part of the common knowledge of how to build web sites today.

Author Comment

ID: 39535790
The session token thing is suggested here, may be I am misinterpreting the suggestion below. That was what was trying to do.



General Recommendation: Synchronizer Token Pattern
When a Web application formulates a request (by generating a link or form that causes a request when submitted or clicked by the user), the application should include a hidden input parameter with a common name such as "CSRFToken". The value of this token must be randomly generated such that it cannot be guessed by an attacker. ...
  <form action="/transfer.do" method="post">
  <input type="hidden" name="CSRFToken" value="OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1ZDZjMTViMGYwMGEwOA==">
In general, developers need only generate this token once for the current session. After initial generation of this token, the value is stored in the session and is utilized for each subsequent request until the session expires. When a request is issued by the end-user, the server-side component must verify the existence and validity of the token in the request as compared to the token found in the session. If the token was not found within the request or the value provided does not match the value within the session, then the request should be aborted, token should be reset and the event logged as a potential CSRF attack in progress.
To further enhance the security of this proposed design, consider randomizing the CSRF token parameter name and or value for each request. Implementing this approach results in the generation of per-request tokens as opposed to per-session tokens. Note, however, that this may result in usability concerns. For example, the "Back" button browser capability is often hindered as the previous page may contain a token that is no longer valid. Interaction with this previous page will result in a CSRF false positive security event at the server.
LVL 111

Accepted Solution

Ray Paseur earned 2000 total points
ID: 39536331
I recognize the OWASP article; I read it many years ago.  Please check the date on the OWASP article.  We're all smarter than that by now.  The token will be presented to the client as a part of the form.  The attacker will simply read the form and send back all of the request variables including the token.  Don't waste a minute of your time on a form token.

In almost every instance you will be fine if you choose a design pattern like the one shown in this article.

If you want a little added assurance that the client is a human being, a CAPTCHA test is the correct thing to use.  It can be very, very easy for you and for your clients.

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

It’s a season to be thankful, and we’re thankful for users like you who engage on site, solve technology problems, and network with others in the industry. What tech are we most thankful for? Keep reading.
The title says it all. Writing any type of PHP Application or API code that provides high throughput, while under a heavy load, seems to be an arcane art form (Black Magic). This article aims to provide some general guidelines for producing this typ…
Explain concepts important to validation of email addresses with regular expressions. Applies to most languages/tools that uses regular expressions. Consider email address RFCs: Look at HTML5 form input element (with type=email) regex pattern: T…
The viewer will learn how to create and use a small PHP class to apply a watermark to an image. This video shows the viewer the setup for the PHP watermark as well as important coding language. Continue to Part 2 to learn the core code used in creat…

627 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question