EDS-based authentication

Already several topics addressed the problems of building a secure authentication mechanism for an insecure connection. Below is a discussion scheme using asymmetric cryptography. This approach will allow you to authenticate with the server, never giving the server a password, either during registration or during authentication. As always, there will be a demonstration and source codes. To whom this topic is interesting, please under the cat.

Previously, we have already considered several options:

• The solution with password encryption is the simplest and has a huge advantage - the introduction of such a scheme does not require re-registration of users. The security of this solution is not up to par, but it is still better than passwords transmitted in the clear.
• SRP-6 , which was also described, is a secure protocol. Of the shortcomings, perhaps, only a long dialogue with the server and the complexity of implementation.
  
• The Rutoken-based authentication described here is a very secure solution, but it is incorrect to compare it with purely software solutions. And it should be noted that not all users are willing to pay for an additional device.

The proposed authentication mechanism uses the same protocol as the Rutoken solution. The main difference is that all cryptographic operations are performed programmatically, and the private key is generated based on the password. Both solutions use elliptic curve cryptography (ECC). ECC is cryptographically stronger than RSA, which allows shorter keys to be used, and as a result, reduces performance requirements. So:

Check in.

• Client selects login and password ;
• Based on them, PrivateKey = SHA256 (login + password) ;
• Based on PrivateKey , PublicKey is formed;
• Login and PublicKey are sent to the server and stored in the database.

Authentication.

• Client enters login and password;
• Based on them, PrivateKey = SHA256 (login + password) ;
• The client receives a random number from the server ( RNDserver ) and generates its own random number ( RNDclient );
• Using PrivateKey, the client generates a Signature Signature (SHA256 (RNDserver + RNDclient)) and sends Login, RNDclient and EDS to the server;
• The server checks the accuracy of the EDS using the PublicKey client stored in the database.

Attached is a demonstration . In the preparation of the example, a library written by Stanford students was used. Special thanks to the good man Martynenko Alexander , who unfortunately does not have an invite to Habr, for the software implementation of generating a key pair and generating an EDS using the algorithm of GOST R 34.10-2001 in the attached example.

Of course, all these examples are just examples. For their "combat" use, you must first think carefully and pay more attention to various "trifles." However, the very existence of various secure authentication protocols leads to questions. Why are passwords still transmitted in clear? Why are the passwords stored in the database in the open form or in the form of hashes without salt? When communicating with some representatives of large online services about the security of their accounts, I have repeatedly heard the question - And where is our benefit? So nevertheless, is there a benefit in the security of your users?