Secure Login
Good day, dear Habrazhiteli!
Many of you who develop web sites, sooner or later, thought about the security of the data that the user sends on the server, in particular the security of sending passwords.
Quite recently, while doing a graduation project (by the way, on the topic “Online Learning Management System”), I thought about it. I came up with one idea to improve password security during authorization. The idea is not thorough and not fully thought out, so I want to share it with knowledgeable people.
Theory
')
The main goal is to protect the password from interception “on the way” to the server. On the server in the database will be stored login, MD5 password hash and a certain string, which the server will give to the user in cookies for subsequent authentication. This is the simplest model for example only.
The essence of my idea is that a certain password hash is transmitted from a web page to the server instead of a password. You will say that an attacker can intercept the hash and authorize on it. And no. The hash that will be transmitted will be a kind of dynamic, i.e. will be different at different times.
How will this work?
I suggest to send a password to the server in this form:
After filling in the login form on the page, the user clicks the “Login” button, after which Javascript takes the MD5 hash from the password, adds the current UNIX time to this string, and from the resulting string again takes the MD5. This value is substituted in the field instead of the password. Also, in the login form you will have to insert a hidden field into which UNIX time will be inserted. After executing the script, the data is sent to the server.
On the server side, from the database, a row is received at the specified login and it is checked whether MD5 is equal to the string (UNIX time + [password hash from the base]) to the string that the server browser transferred. If yes, then the authorization was successful and in cookies a random random string is sent to the user for subsequent authentication, which is also recorded in the database.
Underwater rocks
There are some drawbacks to this technology.
1. The main one is associated with time. It should be about the same on the user side and on the server side (I don’t know how much it’s about, I suggest taking ± 60 seconds). At the same time, this will be one of the additional security features: by intercepting the data once, the attacker will not be able to log in later, since the server will check the time when the request came.
2. And what will happen if an attacker, having received the data, immediately tries to log in? He will succeed, because those ± 60 seconds could not pass. To solve the problem, I propose in the form to enter another field of the hidden type in which the server will place the key (generated randomly). This key can be encrypted with the time and password, transferred back to the server and it will also be checked there.
3. The third is also associated with time. You ask what to do if all of a sudden the user has a set time on the computer, which is completely different from the time on the server? “I don't know,” I will tell you. Although there is one idea for the future: before sending data to the server, a web page can be an AJAX request to the server to find out the time, and then send the data. By the way, the same random key can come in the same query.
And it was impossible to make a simple version with a key?
No you can not. This is my idea. Its initial concept was using time checking when a request was generated. The idea of ​​an open key came into my head much later.
results
In one fell swoop, we get several levels of protection: the password is not transmitted in the clear, the time is checked, the public key is applied.
We have everything and we have nothing. I had little time then, so I could not bring all this to life. There is only an idea ready to think.
Dear Habravchane, tell me whether to develop this idea? I now have some developments in this regard. If you like my idea, in the next article I will publish the results of my work. If anyone has any suggestions on this, please write. Thanks in advance for your criticism.
Many of you who develop web sites, sooner or later, thought about the security of the data that the user sends on the server, in particular the security of sending passwords.
Quite recently, while doing a graduation project (by the way, on the topic “Online Learning Management System”), I thought about it. I came up with one idea to improve password security during authorization. The idea is not thorough and not fully thought out, so I want to share it with knowledgeable people.
Theory
')
The main goal is to protect the password from interception “on the way” to the server. On the server in the database will be stored login, MD5 password hash and a certain string, which the server will give to the user in cookies for subsequent authentication. This is the simplest model for example only.
The essence of my idea is that a certain password hash is transmitted from a web page to the server instead of a password. You will say that an attacker can intercept the hash and authorize on it. And no. The hash that will be transmitted will be a kind of dynamic, i.e. will be different at different times.
How will this work?
I suggest to send a password to the server in this form:
MD5(MD5()+UNIX-timestamp)After filling in the login form on the page, the user clicks the “Login” button, after which Javascript takes the MD5 hash from the password, adds the current UNIX time to this string, and from the resulting string again takes the MD5. This value is substituted in the field instead of the password. Also, in the login form you will have to insert a hidden field into which UNIX time will be inserted. After executing the script, the data is sent to the server.
On the server side, from the database, a row is received at the specified login and it is checked whether MD5 is equal to the string (UNIX time + [password hash from the base]) to the string that the server browser transferred. If yes, then the authorization was successful and in cookies a random random string is sent to the user for subsequent authentication, which is also recorded in the database.
Underwater rocks
There are some drawbacks to this technology.
1. The main one is associated with time. It should be about the same on the user side and on the server side (I don’t know how much it’s about, I suggest taking ± 60 seconds). At the same time, this will be one of the additional security features: by intercepting the data once, the attacker will not be able to log in later, since the server will check the time when the request came.
2. And what will happen if an attacker, having received the data, immediately tries to log in? He will succeed, because those ± 60 seconds could not pass. To solve the problem, I propose in the form to enter another field of the hidden type in which the server will place the key (generated randomly). This key can be encrypted with the time and password, transferred back to the server and it will also be checked there.
3. The third is also associated with time. You ask what to do if all of a sudden the user has a set time on the computer, which is completely different from the time on the server? “I don't know,” I will tell you. Although there is one idea for the future: before sending data to the server, a web page can be an AJAX request to the server to find out the time, and then send the data. By the way, the same random key can come in the same query.
And it was impossible to make a simple version with a key?
No you can not. This is my idea. Its initial concept was using time checking when a request was generated. The idea of ​​an open key came into my head much later.
results
In one fell swoop, we get several levels of protection: the password is not transmitted in the clear, the time is checked, the public key is applied.
We have everything and we have nothing. I had little time then, so I could not bring all this to life. There is only an idea ready to think.
Dear Habravchane, tell me whether to develop this idea? I now have some developments in this regard. If you like my idea, in the next article I will publish the results of my work. If anyone has any suggestions on this, please write. Thanks in advance for your criticism.
Source: https://habr.com/ru/post/136809/
All Articles