Two-factor SMS authorization with young ladies and preference
This is a story about how a bike with a large number of wheels of irregular shape was built for the elementary field “enter the code from the SMS”. I invite you to criticize the universal module for two-factor authentication.
Once the chief asked to tie two-factor authentication to a single web service. Users have long logged in with a username and password, and it was required to add confirmation of logging in via SMS. No suitable ready-made solution was found on the network, it means you have to do it yourself. What is there to do, everything will be in the evening! In general, after three days the login form requested a mobile number and required to enter a code from the SMS. SMS was sent through the API of one of the numerous SMS providers for little money.
')
Soon the solution was transferred with the help of a file to another PHP web admin. After a couple of weeks, many complaints began to come in that text messages come with a huge delay, or do not come at all. We decided to change the sending gateway. Naturally, on both services. It did not help for a long time, it became clear that a backup sending channel was needed. So spent another day or two. Then in a few months on one of the services, the attacker clicked on all the money that was in the account with the SMS provider. I had to complicate the system a little more and duplicate the solution. The next failure occurred when mobile operators passed to the new rules for SMS sending regarding the content of the sender field. At the same time, it was discovered by chance that two colleagues in the office did not receive SMS for entering the bank-clients of two different very large banks. Then it became clear - it’s enough to endure, the world needs a universal solution for two-factor SMS authorization!
It was decided to make a super universal and reliable module of two-factor authorization by SMS, which is easy to embed on any site, and sell it by subscription! Long live the startup!
For portability and security, it was decided everything that can be put on the SMS sending server and in JavaScript, so that there is as little code as possible on the site server. After thoughtful reflections, this was the architecture.
It is implied that the site server, before connecting two-factor authentication, only checks the login and password. After connecting, check the login, password and approval from the authorization server via SMS. At the same time, the SMS authorization server will store the IDs of the site users and their phones, and logins and passwords will not be known to him.
The request from the site to the authorization server goes through the user's browser. The site server is completely abstracted from the concept of SMS and receives only approval from the authorization server. The site server sets a cookie with a confirmation request by SMS. JavaScript detects this cookie and initiates interaction with the AJAX sms sending server. The message about the successful verification of SMS is transmitted to the site server also using cookies. The site performs the authorization when the correct username, password and cookie are sent to it with confirmation from the authorization server via SMS.
Requests between site servers and authorization pass through the user's browser. So that he could not substitute them, we will sign each request with a key that both servers know but does not know the browser. Also, set the expiration date of the packet of data transmitted between servers. After such restrictions, the maximum that can be done after the browser is completely compromised is to intercept the login, password and approval from the authorization server. This will allow you to simultaneously enter the attacked site from another computer. It is assumed that the attacker in this case will go easier, and just take the session!
If the authorization server is compromised, then the attacker will recognize the users' phone numbers and will be able to fake the answers from the authorization server. However, to access the accounts on the site is not enough, you need to know the logins and passwords that are not on the authorization server.
The browser and the authorization server communicate via AJAX via https, intercepting their data is problematic. If the authorization form on the site also works on HTTPS, then it is difficult to attack here, otherwise two-factor authentication does not help from a simpler theft of the session.
In sum, this approach to the organization of two-factor authorization, although it looks confusing, but gives the impression of being very safe.
Actually you can watch and download it at magiclogin.ru .
Currently, the two-factor SMS authorization module is up to working condition and works on several sites.
If you have any suggestions on functionality, please write in the comments.
Problem
Once the chief asked to tie two-factor authentication to a single web service. Users have long logged in with a username and password, and it was required to add confirmation of logging in via SMS. No suitable ready-made solution was found on the network, it means you have to do it yourself. What is there to do, everything will be in the evening! In general, after three days the login form requested a mobile number and required to enter a code from the SMS. SMS was sent through the API of one of the numerous SMS providers for little money.
')
Soon the solution was transferred with the help of a file to another PHP web admin. After a couple of weeks, many complaints began to come in that text messages come with a huge delay, or do not come at all. We decided to change the sending gateway. Naturally, on both services. It did not help for a long time, it became clear that a backup sending channel was needed. So spent another day or two. Then in a few months on one of the services, the attacker clicked on all the money that was in the account with the SMS provider. I had to complicate the system a little more and duplicate the solution. The next failure occurred when mobile operators passed to the new rules for SMS sending regarding the content of the sender field. At the same time, it was discovered by chance that two colleagues in the office did not receive SMS for entering the bank-clients of two different very large banks. Then it became clear - it’s enough to endure, the world needs a universal solution for two-factor SMS authorization!
Formulation of the problem
It was decided to make a super universal and reliable module of two-factor authorization by SMS, which is easy to embed on any site, and sell it by subscription! Long live the startup!
For portability and security, it was decided everything that can be put on the SMS sending server and in JavaScript, so that there is as little code as possible on the site server. After thoughtful reflections, this was the architecture.
It is implied that the site server, before connecting two-factor authentication, only checks the login and password. After connecting, check the login, password and approval from the authorization server via SMS. At the same time, the SMS authorization server will store the IDs of the site users and their phones, and logins and passwords will not be known to him.
The request from the site to the authorization server goes through the user's browser. The site server is completely abstracted from the concept of SMS and receives only approval from the authorization server. The site server sets a cookie with a confirmation request by SMS. JavaScript detects this cookie and initiates interaction with the AJAX sms sending server. The message about the successful verification of SMS is transmitted to the site server also using cookies. The site performs the authorization when the correct username, password and cookie are sent to it with confirmation from the authorization server via SMS.
Security
Requests between site servers and authorization pass through the user's browser. So that he could not substitute them, we will sign each request with a key that both servers know but does not know the browser. Also, set the expiration date of the packet of data transmitted between servers. After such restrictions, the maximum that can be done after the browser is completely compromised is to intercept the login, password and approval from the authorization server. This will allow you to simultaneously enter the attacked site from another computer. It is assumed that the attacker in this case will go easier, and just take the session!
If the authorization server is compromised, then the attacker will recognize the users' phone numbers and will be able to fake the answers from the authorization server. However, to access the accounts on the site is not enough, you need to know the logins and passwords that are not on the authorization server.
The browser and the authorization server communicate via AJAX via https, intercepting their data is problematic. If the authorization form on the site also works on HTTPS, then it is difficult to attack here, otherwise two-factor authentication does not help from a simpler theft of the session.
In sum, this approach to the organization of two-factor authorization, although it looks confusing, but gives the impression of being very safe.
What is done
Actually you can watch and download it at magiclogin.ru .
Currently, the two-factor SMS authorization module is up to working condition and works on several sites.
- Written PHP class for installation on the site server, there is a detailed installation instructions.
- The “Enter code from SMS” interface is implemented in the form of a modal window that is generated from JavaScript.
- Support for IE 7+, modern Chrome, Firefox, Opera, Safari, Android.
- The user can change the phone number.
- You can allow users to opt out of two-factor authentication.
- There is admin panel for viewing statistics and payment.
Immediate plans
- Make plugins for the main engines in PHP.
- I'd like to make a class for a site server in C #, Java, Python.
- Make a color scheme constructor modal window.
If you have any suggestions on functionality, please write in the comments.
Source: https://habr.com/ru/post/223341/
All Articles