Authorization form with sending an encrypted password
In this article, I decided to post my idea of authorization on the site using PHP.
Of course, if the authorization occurs on SSL, the risks that the password will be intercepted using a sniffer become void. But still, this type of authorization is not used everywhere. One type of protection is the content of the password in the form of a hash. But after all, during authorization, the password is sent to the POST request to the server and there is a chance to catch it. Upon reflection, I decided to try to implement an authorization scheme in which the password would not be sent to the server in the form in which it is. And not even his MD5 hash. The plans had something like the ms-chap algorithm.
Namely:
1) When visiting a site, an unauthorized user in the cookie is given a unique id.
2) If the user decides to log in, when the password is filled, a hash is generated based on the md5 hash of his password and the id issued by the server.
3) After authorization attempt, regardless of its results, id is overwritten.
What do we get in the end? With each authorization attempt, a new hash is generated which is different from the previous one and there is no sense in catching it.
')
So let's start:
Since the article did not imply a ready-made code, but focused more on the algorithm and logic, only those bass moments on which the implementation of this logic is based are indicated. The essence here is more in the algorithm and the environment each builds in its own way.
So in the root of the site the user is assigned a "salt" which is generated at the very beginning, as well as after each authorization attempt.
Further in the form of login:
How to get a constantly changing password, we figured out, it remains to figure out what to do with it.
After submitting the form we get into the function of checking the login and password. Here, too, the taste and color markers are different. In my case, instead of the form, the authorization function is called after the results of which the page is simply updated and if the authorization was successful, then we get into our workspace. If the result is unsuccessful, then we again look at the entry form.
UPD: The article assumed not the code itself, but an algorithm which everyone sees in their own way. And not for the holivar divorce on the topic “a hole was formed and it’s not plowing at all” and the brackets are crooked. But since all the comments rested precisely on this, the cat had to be removed which was primitive and implied actions on non-instructions.
Of course, if the authorization occurs on SSL, the risks that the password will be intercepted using a sniffer become void. But still, this type of authorization is not used everywhere. One type of protection is the content of the password in the form of a hash. But after all, during authorization, the password is sent to the POST request to the server and there is a chance to catch it. Upon reflection, I decided to try to implement an authorization scheme in which the password would not be sent to the server in the form in which it is. And not even his MD5 hash. The plans had something like the ms-chap algorithm.
Namely:
1) When visiting a site, an unauthorized user in the cookie is given a unique id.
2) If the user decides to log in, when the password is filled, a hash is generated based on the md5 hash of his password and the id issued by the server.
3) After authorization attempt, regardless of its results, id is overwritten.
What do we get in the end? With each authorization attempt, a new hash is generated which is different from the previous one and there is no sense in catching it.
')
So let's start:
Since the article did not imply a ready-made code, but focused more on the algorithm and logic, only those bass moments on which the implementation of this logic is based are indicated. The essence here is more in the algorithm and the environment each builds in its own way.
So in the root of the site the user is assigned a "salt" which is generated at the very beginning, as well as after each authorization attempt.
session_start(); // id if(!isset($_SESSION['uniq'])||$_SESSION['uniq']=='') { $_SESSION['uniq']=uniqid(); } ?> Further in the form of login:
<form action="" method="post"> // <input type="email" placeholder="E-mail" name="login"> // <input id="pass" type="password" placeholder="" > // <input id="hidpass" type="hidden" name="password" value="" > // <button type="submit" ></button> </form> // <script> $(function () { $("#pass").on("input",function(e){ // MD5 id var pass=CryptoJS.MD5($('#pass').val())+'<?php echo $_SESSION['uniq']?>'; var md5pass=CryptoJS.MD5(pass); $('#hidpass').val(md5pass.toString()); }); }); </script> How to get a constantly changing password, we figured out, it remains to figure out what to do with it.
After submitting the form we get into the function of checking the login and password. Here, too, the taste and color markers are different. In my case, instead of the form, the authorization function is called after the results of which the page is simply updated and if the authorization was successful, then we get into our workspace. If the result is unsuccessful, then we again look at the entry form.
function CheckLogin($login,$md5pass) { // $pass="MD5 " ; // id $pass.=$_SESSION['uniq']; // $pass=md5($pass); // id unset($_SESSION['uniq']); // if(strcmp($md5pass,$pass)==0) { echo " . "; $_SESSION['id']=session_id(); } // ....... } UPD: The article assumed not the code itself, but an algorithm which everyone sees in their own way. And not for the holivar divorce on the topic “a hole was formed and it’s not plowing at all” and the brackets are crooked. But since all the comments rested precisely on this, the cat had to be removed which was primitive and implied actions on non-instructions.
Source: https://habr.com/ru/post/334388/
All Articles