PHP login steps

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!
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Ray PaseurCommented:
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!
myyisAuthor Commented:
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
Ray PaseurCommented:
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.
JavaScript Best Practices

Save hours in development time and avoid common mistakes by learning the best practices to use for JavaScript.

myyisAuthor Commented:
Here there is an example to create a fake POST header.

<form action="" 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.
Ray PaseurCommented:
... 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.
myyisAuthor Commented:
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="/" 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.
Ray PaseurCommented:
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.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.