Secure Remote Password protocol


The Secure Remote Password protocol is an augmented password-authenticated key agreement protocol, specifically designed to work around existing patents.
Like all PAKE protocols, an eavesdropper or man in the middle cannot obtain enough information to be able to brute force guess a password without further interactions with the parties for each guess. Furthermore, being an augmented PAKE protocol, the server does not store password-equivalent data. This means that an attacker who steals the server data cannot masquerade as the client unless they first perform a brute force search for the password.
In layman's terms, during SRP authentication, one party demonstrates to another party that they know the password, without sending the password itself nor any other information from which the password can be derived. The password never leaves the client and is unknown to the server.
Furthermore, the server also needs to know about the password in order to instigate the secure connection. This means that the server also authenticates itself to the client, without reliance on the user parsing complex URLs. This prevents Phishing.

Overview

The SRP protocol has a number of desirable properties: it allows a user to authenticate themselves to a server, it is resistant to dictionary attacks mounted by an eavesdropper, and it does not require a trusted third party. It effectively conveys a zero-knowledge password proof from the user to the server. In revision 6 of the protocol only one password can be guessed per connection attempt. One of the interesting properties of the protocol is that even if one or two of the cryptographic primitives it uses are attacked, it is still secure. The SRP protocol has been revised several times, and is currently at revision 6a.
The SRP protocol creates a large private key shared between the two parties in a manner similar to Diffie–Hellman key exchange based on the client side having the user password and the server side having a cryptographic verifier derived from the password. The shared public key is derived from two random numbers, one generated by the client, and the other generated by the server, which are unique to the login attempt. In cases where encrypted communications as well as authentication are required, the SRP protocol is more secure than the alternative SSH protocol and faster than using Diffie–Hellman key exchange with signed messages. It is also independent of third parties, unlike Kerberos. The SRP protocol, version 3 is described in RFC 2945. SRP version 6 is also used for strong password authentication in SSL/TLS and other standards such as EAP and SAML, and is being standardized in IEEE P1363 and ISO/IEC 11770-4.

Protocol

The following notation is used in this description of the protocol, version 6:
All other variables are defined in terms of these.
First, to establish a password p with server Steve, client Carol picks a small random salt s, and computes x = H, v = g. Steve stores v and s, indexed by, as Carol's password verifier and salt. Carol must not share x with anybody, and must safely erase it at this step, because it is equivalent to the plaintext password p. This step is completed before the system is used as part of the user registration with Steve. Note that the salt s is shared and exchanged to negotiate a session key later so the value could be chosen by either side but is done by Carol so that she can register, s and v in a single registration request. The transmission and authentication of the registration request is not covered in SRP.
Then to perform a proof of password at a later date the following exchange protocol occurs:
  1. Carol → Steve: generate random value a; send and A = g
  2. Steve → Carol: generate random value b; send s and B = kv + g
  3. Both: u = H
  4. Carol: SCarol = = = =
  5. Carol: KCarol = H
  6. Steve: SSteve = = = = =
  7. Steve: KSteve = H = KCarol
Now the two parties have a shared, strong session key K. To complete authentication, they need to prove to each other that their keys match. One possible way is as follows:
  1. Carol → Steve: M1 = H. Steve verifies M1.
  2. Steve → Carol: M2 = H. Carol verifies M2.
This method requires guessing more of the shared state to be successful in impersonation than just the key. While most of the additional state is public, private information could safely be added to the inputs to the hash function, like the server private key.
Alternatively, in a password-only proof the calculation of K can be skipped and the shared S proven with:
  1. Carol → Steve: M1 = H. Steve verifies M1.
  2. Steve → Carol: M2 = H. Carol verifies M2.
When using SRP to negotiate a shared key K which will be immediately used after the negotiation the verification steps of M1 and M2 may be skipped. The server will reject the very first request from the client which it cannot decrypt.
The two parties also employ the following safeguards:
  1. Carol will abort if she receives B = 0 or u = 0.
  2. Steve will abort if he receives A = 0.
  3. Carol must show her proof of K first. If Steve detects that Carol's proof is incorrect, he must abort without showing his own proof of K

    Implementation example in Python


  1. An example SRP authentication
  2. WARNING: Do not use for real cryptographic purposes beyond testing.
  3. WARNING: This below code misses important safeguards. It does not check A, B, and U are not zero.
  4. based on http://srp.stanford.edu/design.html
import hashlib
import random
def global_print -> None:
x = lambda s: .format
print) for name in names))
  1. Note: str converts as is, str will convert to ""
def H -> int:
"""A one-way hash function."""
a = ':'.join
return int
def cryptrand:
return random.SystemRandom.getrandbits % N
  1. A large safe prime
  2. All arithmetic is done modulo N
N = 00:c0:37:c3:75:88:b4:32:98:87:e6:1c:2d:a3:32:
4b:1b:a4:b8:1a:63:f9:74:8f:ed:2d:8a:41:0c:2f:
c2:1b:12:32:f0:d3:bf:a0:24:27:6c:fd:88:44:81:
97:aa:e4:86:a6:3b:fc:a7:b8:bf:77:54:df:b3:27:
c7:20:1f:6f:d1:7f:d7:fd:74:15:8b:d3:1c:e7:72:
c9:f5:f8:ab:58:45:48:a9:9a:75:9b:5a:2c:05:32:
16:2b:7b:62:18:e8:f1:42:bc:e2:c3:0d:77:84:68:
9a:48:3e:09:5e:70:16:18:43:79:13:a8:c3:9c:3d:
d0:d4:ca:3c:50:0b:88:5f:e3
N = int).replace
g = 2 # A generator modulo N
k = H # Multiplier parameter
print
global_print
print
  1. The server must first generate the password verifier
I = "person" # Username
p = "password1234" # Password
s = cryptrand # Salt for the user
x = H # Private key
v = pow # Password verifier
global_print
print
a = cryptrand
A = pow
global_print # client->server
print
b = cryptrand
B = % N
global_print # server->client
print
u = H # Random scrambling parameter
global_print
print
x = H
S_c = pow
K_c = H
global_print
print
S_s = pow
K_s = H
global_print
print
M_c = H ^ H, H
global_print
  1. client->server ; server verifies M_c
print
M_s = H
global_print
  1. server->client ; client verifies M_s

Outputs

Implementations