Passing a password over an open channel (part 2)

In the first part of the article, a situation was discussed where, for some reason, we cannot use https to protect the traffic. At the same time, the password transmitted in clear text becomes easy prey for fraudsters. The method proposed in the article made it possible to get rid of the threat of intercepting a password or stealing a database of password hashes, but was powerless against an intruder who also owns and controls traffic. The method proposed below is safer but more difficult.


One of the advantages of the authentication algorithm described in the first part of the article was the ability to integrate it into already existing services transparently to the user. This solution does not allow to do this, since the password database is not stored in the server database, but the RSA keys. The choice of asymmetric cryptography is due to the ability to store in the database information (public key), the disclosure of which does not threaten the password. The most common key size today is RSA 1024 bit. Remember this key and enter it manually unrealistic. To avoid this, the private key is also stored on the server, but in encrypted form. The encryption key is generated based on the user's password. This is of course a “crutch”, but when using a password as a secret, this “crutch” is inevitable.

The registration process is as follows:

1. The client chooses his login and password;
2. The client generates an RSA key pair. The public key e, n and the private key d, n ;
3. The private key d, N is encrypted with AES using the key k based on the password;
4. The client sends to the server, and the server saves the login, the public key e, N and the private key d, N encrypted in the key k .

')
The authentication process is as follows:

1. The client sends a login to the server;
2. The server sends to the client a random number RND encrypted with the public key e, N and the encrypted private key of the client d, N ;
3. The client enters a password, thereby forming the key k and decrypting his private key d, N ;
4. Using the d, N key , the client decrypts the RND and sends hash (RND) to the server;
5. The server compares the received hash with the hash (RND) generated on the server.

Demonstration and source codes are attached again. The sample preparation used the AES Chrisa Veness library, the RSA jCryption library, and the RSA library written by Stanford students.

Hopefully, another, already more “beautiful” solution, I will describe in the next article.
UPD: As promised - habrahabr.ru/blogs/web_security/120990