SRP-6: authentication without sending a password

As promised in the next topic , where the bike was told, I post the description of the SRP RFC2945 algorithm - the method of registering and authenticating users in a secure way over an insecure channel. That's just in the process of preparing the article, I discovered a more recent version of the protocol, SRP-6 , along with the implementation, and therefore decided to throw away my archaic developments on SRP-3, and just give references to the implementation of the new version.

The Secure Remote Password (SRP) protocol describes the establishment of a secure connection using a login and password pair for authentication, in which the password is used only during the registration and authentication phase and only on the client side. Due to the use of a scheme close to Diffie-Hellman, SRP provides secure user password authentication without the need to transfer this password, and even having a complete exchange record over the channel, we do not receive sufficient information to authenticate this user. Also, if the server is compromised and the entire database of logins from the server side flows “to the people”, the attacker will not be able to authenticate any of the users.x

So, the general scheme of user authentication using abbreviated SRP exchanges is as follows:

Selected for work "security field":
H = , . N = " " = 2*q+1 , q . g = N => 0 < X < N x , g^x % N = X. k = -. SRP-6a H(N, g); SRP-6 3
Upon registration, the client calculates the following:
s = random_string() x = H(s, p) v = g^x % N
And it sends three fields to the server:
I = username s = salt v = password verifier
With the right choice of g and N , the transfer of this data is quite safe - from them it is computationally difficult to obtain p.
Security is provided by the complexity of the discrete logarithm operation — obtaining x from v=g^x%N knowing v, g, N
Due to this, even if the user base (hi, Sony!) Is merged from the server, it will be impossible to get passwords, or to introduce yourself as a user.
However, it should be noted that if the user base is merged, then the protocol ceases to be protected from the attacker's representation by the _server_. That is, this method does not guarantee the client that the server is who he claims to be. However, the Man-In-The-Middle attack remains impossible - the attacker cannot (computationally difficult) get the K session key shared with the server.
User:
I = username a = random() A = g^a % N
A pair of login I and computed A sent to the server.
The server should check and make sure that A! = 0.
The server gets two numbers from its zagashnikov that correspond to the login:
s = ,
v = ,
It then generates a random number b , and calculates
B=(k*v + g^b % N) % N
A pair of salt s and calculated B sent to the client.
The client must check at this point that B != 0 .
Both sides compute the scrambler:
u = H(A, B) .
If u == 0, the connection is interrupted.
The client enters his password p , on the basis of which the common session key is calculated:
x = H(s, p) S = ((B - k*(g^x % N)) ^ (a + u*x)) % N K = H(S)
For its part, the server also calculates the common session key:
S = ((A*(v^u % N)) ^ b) % N K = H(S)
From this point on, if the client and the server both ___ know each other, there is an identical K number in both.
To prove to each other that they themselves are evil Pinocchio, a second round of exchange takes place.
The client generates a confirmation:
M = H( H(N) XOR H(g), H(I), s, A, B, K)
and sends to the server.
The server itself calculates M using its copy of K, and checks the equality. If they are equal, then the client has exactly the same K, and, therefore, the client is who he claims to be. If not equal - the connection is interrupted, WITHOUT sending to client R.
If they are equal, then to prove to the client now that he is not a camel, he sends back his confirmation to him:
R = H( A, M, K )
The client similarly calculates R in itself using the K calculated in itself, and compares it with that received from the server.

As a result, the authentication process requires 2 requests to the server and the presence of any software client on the user side. Once again I pay attention, on first of all protection from server side. The server gives as little information as possible, producing first checks at home. Therefore, an attacker who has s and v may present himself as a server, but cannot be an intermediary .

To implement the login, you can use the classic login form + password, onSubmit which is authenticated.
If there is no javascript on the client side, the form will be sent “as is”, which will transmit the password via an insecure channel, but will allow you to authenticate even from “stupid” clients (by simulating all the actions of the “user” on the server).
In the case of the presence of JS, authentication is implemented by sending two special forms using AJAX techniques, performing calculations between them.
')
However, if the site is not required to work without JS (for example, a fallback is not possible at all, too complicated, we don’t drag on the time and effort of developers), it seems to me more reasonable to implement such a scheme: the fields are not in shape at all, after from the login field, the password field is blocked for a while, and the ajax spinner is drawn next to it. After receiving the salt for the user from the server, the password field is unlocked and you can enter the password there.
The sense in separation is necessary to give JS time for calculations. Still, there is quite a lot of mathematics with large numbers. When I investigated this question on SRP-3 using SHA1 (about five years ago), using 512bit keys turned out to be too slow - up to 30 seconds to calculate to confirm the password. At the same time, the entire browser UI [especially IE6;)] is blocked for the duration of the calculation. The solution could be calculations using a continuation (starting the calculation in slices via setTimeout (), keeping the context between calls) or taking calculations in flash / java. And java is preferable in terms of computation speed, and flash in terms of the likelihood of accessibility by the user.

The important point is that the server can respond with salt to any username given to it, in order not to give information about the existence of the specified user in its database, but then the salt for non-existent users should be calculated using an algorithm based on username, and this algorithm should be saved in secret, or to be unrepeatable without any secret information on the server side. Simply put, it is necessary that the salt based on the username cannot be distinguished from the completely random salt of real users.

Another very important to understand that the algorithm does not protect against phishing. A fake website can easily produce an identical-looking page, which will also have login and password fields, up to simulation simulation, calculating, for example, the sum of a series of numbers from 1 to 1e12 through a one-liner , actually sending the password “as is” to the attacker's server . That is why it seems to me that using a signed Java authenticator is more attractive - when faking, it will be necessary to simulate the signature on the authorizer's Java applet ... That, in general, using human laziness and inattention is still possible.

Ready-made implementations of SRP on JS can be found at the links:

SRP JavaScript Demo implementation of both sides on JS, for research "what's going on." Uses SHA1, which, of course, cannot be used in living systems.
SRP-JS on GoogleCode with Django backend
Javascript Crypto Library

SRP-6: authentication without sending a password

More articles: