January 23, 2012 at 14:56Secure Authorization
Good day, dear Habrazhiteli!
Many of you who are involved in the development of websites, sooner or later thought about the security of data transmitted by the user on the server, in particular the security of password transmission.
More recently, when completing a graduation project (by the way, on the topic "Online Learning Management System"), and I thought about it. I came up with one idea to improve password security during authorization. The idea is not thorough and not thoroughly thought out, so I want to share it with knowledgeable people.
Theory
The main goal is to protect the password from being intercepted "on the way" to the server. On the server, the database will store the login, MD5 hash of the password and some string that the server will give the user in cookies for subsequent authentication. This simple model is just an example.
The essence of my idea is that from the web page to the server instead of a password, a password hash is transmitted. You will say that an attacker can intercept the hash and log into it. But no. The hash that will be transmitted will be kind of dynamic, i.e. will be different at different times.
How will it work?
I suggest sending the password to the server in the following form:
After filling out 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 line, and again takes MD5 from the received line. This value is substituted in the field instead of the password. Also in the login form you will have to insert a field of type hidden into which UNIX time will be inserted. After the script is executed, the data is sent to the server.
On the server side, a string is retrieved from the database by the specified login and it is checked whether MD5 is equal to the string (UNIX time + [password hash from the database]) that the server browser transmitted. If yes, then authorization was successful and a random string is sent to the user in cookies for subsequent authentication, it is also written to the database.
Underwater rocks
There are some drawbacks to this technology, so to speak.
1. The main one is time-related. It is on the user side and on the server side should be approximately the same (I do not know how much this is approximately, I suggest taking ± 60 seconds). At the same time, this will be one of the additional protection elements: 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 arrived.
2. And what will happen if an attacker, after receiving the data, immediately tries to log in? He will succeed, because those same ± 60 seconds might not have passed. To solve this problem, I propose in the form to introduce another field of type hidden in which the server will place the key (formed by the randonmo). This key can be encrypted together with time and password, transferred back to the server and there it will also be checked.
3. The third is also related to time. You ask, what should you do if suddenly a user has a set time on a computer that is radically 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, the 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 may come in the same request.
And it was impossible to make just an option with a key?
No. This is my idea. Its initial concept was using time checks when a request was generated. The thought of an open key came to my mind much later.
results
In one fell swoop, we get several levels of protection: the password is not transmitted in clear text, the time is checked, the public key is applied.
We have everything and have nothing. I had little time then, so I could not bring it all to life. There is only a thought-ready idea.
Dear Khabravchians, tell me, is it worth developing this idea? I now have some groundwork 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 subject, please write. Thanks in advance for your criticism.
Many of you who are involved in the development of websites, sooner or later thought about the security of data transmitted by the user on the server, in particular the security of password transmission.
More recently, when completing a graduation project (by the way, on the topic "Online Learning Management System"), and I thought about it. I came up with one idea to improve password security during authorization. The idea is not thorough and not thoroughly thought out, so I want to share it with knowledgeable people.
Theory
The main goal is to protect the password from being intercepted "on the way" to the server. On the server, the database will store the login, MD5 hash of the password and some string that the server will give the user in cookies for subsequent authentication. This simple model is just an example.
The essence of my idea is that from the web page to the server instead of a password, a password hash is transmitted. You will say that an attacker can intercept the hash and log into it. But no. The hash that will be transmitted will be kind of dynamic, i.e. will be different at different times.
How will it work?
I suggest sending the password to the server in the following form:
MD5(MD5(Пароль)+UNIX-timestamp)After filling out 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 line, and again takes MD5 from the received line. This value is substituted in the field instead of the password. Also in the login form you will have to insert a field of type hidden into which UNIX time will be inserted. After the script is executed, the data is sent to the server.
On the server side, a string is retrieved from the database by the specified login and it is checked whether MD5 is equal to the string (UNIX time + [password hash from the database]) that the server browser transmitted. If yes, then authorization was successful and a random string is sent to the user in cookies for subsequent authentication, it is also written to the database.
Underwater rocks
There are some drawbacks to this technology, so to speak.
1. The main one is time-related. It is on the user side and on the server side should be approximately the same (I do not know how much this is approximately, I suggest taking ± 60 seconds). At the same time, this will be one of the additional protection elements: 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 arrived.
2. And what will happen if an attacker, after receiving the data, immediately tries to log in? He will succeed, because those same ± 60 seconds might not have passed. To solve this problem, I propose in the form to introduce another field of type hidden in which the server will place the key (formed by the randonmo). This key can be encrypted together with time and password, transferred back to the server and there it will also be checked.
3. The third is also related to time. You ask, what should you do if suddenly a user has a set time on a computer that is radically 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, the 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 may come in the same request.
And it was impossible to make just an option with a key?
No. This is my idea. Its initial concept was using time checks when a request was generated. The thought of an open key came to my mind much later.
results
In one fell swoop, we get several levels of protection: the password is not transmitted in clear text, the time is checked, the public key is applied.
We have everything and have nothing. I had little time then, so I could not bring it all to life. There is only a thought-ready idea.
Dear Khabravchians, tell me, is it worth developing this idea? I now have some groundwork 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 subject, please write. Thanks in advance for your criticism.