Password protection during transmission over an open channel (part 1)
Using https for authentication has long been a good practice. However, the need to purchase a certificate leads to the fact that many web-resource owners still use an open channel for authentication and your access passwords can be intercepted by an attacker who has access to the network where you work. It should be noted that the use of https in general does not guarantee protection against the 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 on corporate networks. Further on how to protect the password from interception.
How are things now? The most typical situation is that the server stores the user password H (pwd) in the hash database and, during the authentication process, having received the password from the user, calculates the hash and compares it with the standard. Storing the password hash value in the database, instead of the password itself, allows you to protect yourself from theft of authentication data by an unscrupulous administrator or third-party violator. But despite this, each time during authentication, the password is transmitted in the clear channel on the communication channel. And intercepting the password gives the attacker full access to the corresponding account. To protect against password interception, an authentication digest mechanism was invented.. I simplified the algorithm a bit for ease of understanding. At each session, the server sends a random number of Rnd to the client, the client sends back H (Rnd + H (pwd)). As a result, interception will not give an attacker anything, but now there is a weak point - the server database. The password or password hash stored in the database will allow you to recreate the client’s response necessary for authorization. Theft of such a database becomes a serious threat to the security of the authentication mechanism.
The following is an example of how to protect the transmitted password from being intercepted without creating an additional threat. At the same time, small alterations will affect only your service and will not affect your users.
So:
For those who find it easier to understand, reading the code are examples . Server side in PHP. Client - Javascript. You can also watch the demo . AES encryption is built on Chrisa Veness libraries .
Of course, this solution is not a panacea, and it makes sense to use it only when there is no way to use https. However, using the described algorithm will protect the transmitted password from sniffing and MitM attacks.
part 2
How are things now? The most typical situation is that the server stores the user password H (pwd) in the hash database and, during the authentication process, having received the password from the user, calculates the hash and compares it with the standard. Storing the password hash value in the database, instead of the password itself, allows you to protect yourself from theft of authentication data by an unscrupulous administrator or third-party violator. But despite this, each time during authentication, the password is transmitted in the clear channel on the communication channel. And intercepting the password gives the attacker full access to the corresponding account. To protect against password interception, an authentication digest mechanism was invented.. I simplified the algorithm a bit for ease of understanding. At each session, the server sends a random number of Rnd to the client, the client sends back H (Rnd + H (pwd)). As a result, interception will not give an attacker anything, but now there is a weak point - the server database. The password or password hash stored in the database will allow you to recreate the client’s response necessary for authorization. Theft of such a database becomes a serious threat to the security of the authentication mechanism.
The following is an example of how to protect the transmitted password from being intercepted without creating an additional threat. At the same time, small alterations will affect only your service and will not affect your users.
So:
- The server stores the password hash of the client H (pwd) in the database;
- The client sends its Login to the server;
- The server sends the client a random Rnd number encrypted on the client's H (pwd);
- The client calculates a random Rnd number with its password, then encrypts its pwd password with a random Rnd number and sends it to the server;
- The server decrypts the client password using a random number Rnd, calculates the password hash and compares it with the standard.
For those who find it easier to understand, reading the code are examples . Server side in PHP. Client - Javascript. You can also watch the demo . AES encryption is built on Chrisa Veness libraries .
Of course, this solution is not a panacea, and it makes sense to use it only when there is no way to use https. However, using the described algorithm will protect the transmitted password from sniffing and MitM attacks.
part 2