Password protection for transmission over an open channel (part 1)

Using https for authentication has long been a good tone rule. However, the need to purchase a certificate leads to the fact that many owners of web-resources still use the public channel for authentication and your access passwords can be intercepted by an attacker who has access to the network in which you work. It should be noted that the use of https in general does not guarantee protection against interception of transmitted traffic. Today, there are solutions based on the use of special proxies and domain policies that allow you to successfully read https traffic in corporate networks. Next on how to still protect the password from interception.

How are things going now? The most typical situation is that the server stores the user password H (pwd) in the database and in the authentication process, having received the password from the user, calculates the hash and compares it with the standard. Storing the password hash in the database, instead of the password itself, allows you to protect yourself against theft of authentication data by an unscrupulous administrator or a third-party intruder. But despite this, every time you authenticate, the password is transmitted in the communication channel in the clear. And intercepting the password gives the attacker full access to the corresponding account. An authentication digest mechanism was developed to protect against password interception. I simplified the algorithm a bit for ease of understanding. At each session the server sends a random number Rnd to the client, the client sends H (Rnd + H (pwd)) in response. As a result, interception will not give anything to the attacker, but now there is a weak point - server database. Stored in the database password or password hash will allow you to recreate the client response required for authorization. The theft of such a database becomes a serious threat to the security of the authentication mechanism.

The following is an example of how you can protect a transmitted password from interception without creating an additional threat. In this small alterations will affect only your service and will not affect your users.

So:

1. The server stores in the database the client password hash H (pwd);
2. The client sends its Login to the server;
3. The server sends the client a random number Rnd encrypted on the client's H (pwd);
4. The client calculates a random number Rnd using its password, then encrypts its password pwd using a random number Rnd and sends it to the server;
5. The server decrypts the client password using a random number Rnd, calculates the password hash and compares it with the standard.

For those who are easier to understand by reading the code - examples . PHP server side. Client - Javascript. You can also see a demonstration . AES encryption built on Chrisa Veness libraries
Of course, this solution is not a panacea, and it only makes sense to use it when it is not possible to use https. However, the use of the described algorithm will protect the transmitted password from sniffing and MitM attacks.
')
part 2