PHP login steps

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.
https://www.experts-exchange.com/Web_Development/Web_Languages-Standards/PHP/A_2391-PHP-login-logout-and-easy-access-control.html

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!

Ray,
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?

// MAKE THE UNIQUE USER KEY
        $uuk = md5($uid . $pwd . rand());

Thank you again

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.

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

http://stackoverflow.com/questions/6864235/fake-a-post-via-php


<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">
</form>


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:

$sql = "SELECT * FROM USER WHERE EMAIL = ?";
$res=selectsqlp($sql,array($Email));


function selectsqlp($sql,$arr) {

      global  $dbpdo;
      try{
      $q = $dbpdo->prepare($sql);
      $q-> execute($arr);
      }catch (PDOException $e) {
      $e->getMessage();
      $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.

... 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.

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

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

---------------------------------------------

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==">
   </form>
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.