Your account is now even more secure with the embedded Secure Remote Password (SRP) protocol.
Geens & SRP
The zero-knowledge proof SRP protocol ensures a strong, advanced level of security combined with the right amount of flexibility and user convenience. We did not have reinvent the wheel. Embedding the open SRP protocol standard makes it possible with your account to securely use low-entropy passwords.
What changes for you
As from now the way you log in with your email account is more secure but has changed a little.
Previously, you could log in with your email and provide any password of the various accounts linked to that email and access the full list of all your linked accounts.
Now, after the RSP update, you are prompted to select one main account to be linked with your email and use only this account password for logging in with this email.
For example: you have 3 linked accounts to your email.
[email protected] Linked to user1#group1 (password: user1), user2#group2 (password: user2) and user3#group3 (password: user3)
Enter your email and Any password of a linked account |
Enter email and only Main account password |
About SRP
Password – a string of characters used for authenticating a user on a computer system.
For example, you have an account on your computer that requires you to log in. To successfully get access, you must provide a valid username and password combination, often referred to as login. While usernames are generally public information, passwords are private. Taking into account that the password is private to the user, it becomes increasingly harder for the software systems to securely authenticate their users and process the sensitive password in a secure and correct way. One of the most common used approaches is ‘password hashing’.
Hashed passwords offer a good trade-off between simplicity and security. However, for highly sensitive information transactions and secure data storage platform, it has some drawbacks.
- A trusted server is needed to securely process & store the hashed passwords.
- An attacker with a large password dictionary and a hacked database use automated software to determine the user’s password.
- An attacker can eavesdrop (MITM attack) communication between client and server and so can acquire the password.
For Geens we need a strong Zero-knowledge proof (without transferring password) system that simultaneously authenticates on both client and server. Here comes the implementation called Secure Remote Password (SRP).
Secure Remote Password (SRP)
SRP is a secure augmented password-authenticated key agreement (PAKE) protocol that solves the problem of exchanging secrets securely over an untrusted network.
It is a zero-knowledge proof protocol, where the server doesn’t have to store password equivalent information (hashed version), and clients can securely authenticate to the server. And an eavesdropper or man-in-the-middle cannot obtain any meaningful information to perform an attack. SRP offers great benefits such as:
- Can authenticate without needing to send the password over the network.
- Resists from both active & passive attacks, such as MITM or brute-force dictionary attacks.
- Proves the identity of the server & client to each other and makes sure no imposter party is involved.
- Additionally offers a secure session encryption key, so the client & server can transmit encrypted data providing higher security on top of TLS.
SRP contains many layers and mathematical derivations. But in simple terms, it consists of three steps: registration, authentication, and verification.
SRP Registration
This is the first step in the process, in which the client transmits certain information for future authentication. so during signup, the client will:
- generates a random salt ⁽ⁱ⁾
- the client passes the username, password, and salt to a mathematical function (KDF) ⁽ⁱ⁾ to derive x
- then it generates something called a verifier ⁽ⁱ⁾, using the derived x and an SRP group ⁽ⁱ⁾ (more on this later).
Then it sends the verifier, salt, and the SRP group along with the username to the server and the server will store the verifier and salt for the user.
| Client(username, verifier, salt) → Server stores (verifier, salt) for user |
⁽ⁱ⁾ Used terms: Salt — a random string used during computation of the verifier. KDF — a key derivation function that will transform the password into a very large number eg: PBKDF etc. SRP group — consists of one large prime number & a generator. you can choose between several groups eg: 1024 bit, 2048 bit, etc. Verifier — this is the random string generated out of x, and it’s not the hashed version of the password, also it cannot be effectively used to guess the password.
SRP Authentication
This is the interesting & confusing part, in order to prove that the user knows their password, the client & server exchange non-sensitive information to generate a key independently and use it for verification.
Client-side:
- The clients make a request to the server to get the salt & SRP group for the given username
- then it passes the username, password, salt to the KDF to derive x (same as during registration)
- it also generates a one-time ephemeral value a (private) and its counterpart A (public) using SRP group, were private a is kept in-memory and its public value A is sent to the server
Server-Side:
The server while sending the salt back to the user,
- generates one-time ephemeral value b (private) its counter-part B (public) using the SRP group, stores the private value b in temporary storage, and sends the public value B to the client.
| Client(username) → Server returns (salt, SRP group, B) |
It’s rather complicated and to explain in simple terms its:
- The password never leaves the PC.
- Instead, the client & server exchanges A & B.
- So, a client with (x, a, B) and the server with (verifier, b, A) using different calculations, can calculate the same value, which is used as the session encryption key (trust the math).
SRP Verification
This is part of the authentication. In the previous step we have created the same session encryption key in both client & server-side without exchanging any sensitive information. But we have not yet verified that both sides have derived the same value (which is what we want out of all this fancy math). The verification flow looks like this:
- The client encrypts a message using the session encryption key and sends it to the server.
- The server decrypts the message and verifies it, if not verified, the authentication process fails.
- If verified successfully, the server encrypts a message using its session encryption key and sends it back to the client.
- The client decrypts the message and verifies it.
Thus the client & server both successfully verified that the user’s password is identical and legit. Now both sides use the session encryption key as the symmetric encryption key to exchange encrypted messages.
Learn More about SRP
SRP protocol consists of many calculations, back-and-forth communication between client & server, and complex terms to understand. Since its an open protocol here is more information: