1
$\begingroup$

Assume use of SRP over an otherwise insecure unauthenticated channel where

  • the user running the client side has chosen a password,
  • the user only uses that password with a trusted SRP client software, and with the intention to login to the legitimate server (then communicate securely with that server using the SRP-negotiated session key),
  • there was no attack at enrollment time,
  • the server keeps the enrollment data confidential,
  • the password is good enough that odds are negligible that it could be guessed in a thousand attempts, and neither the server nor user would tolerate that many unsuccessful login attempts.

Does that protect the user from logging to another server?


Motivation: see that question.

So far, I have determined that such protection is not in SRP's advertised features:

It solves the problem of authenticating clients to servers securely, in cases where the user of the client software must memorize a small secret (like a password) and carries no other secret information, and where the server carries a verifier for each user, which allows it to authenticate the client but which, if compromised, would not allow the attacker to impersonate the client. In addition, SRP exchanges a cryptographically-strong secret as a byproduct of successful authentication, which enables the two parties to communicate securely.

$\endgroup$

2 Answers 2

3
$\begingroup$

Yes (and it is an explicit goal of SRP; perhaps not as advertised as such)

The only attack that SRP allows is for the faux server to take a guess at the password, and then attempt to allow the client to login based on that guess (and if the client thinks he succeeds, the guess was correct).

Given that we assume that the password was strong enough to make that unlikely, you're safe.

$\endgroup$
2
  • $\begingroup$ I think I vaguely understand why that holds. But I fail to find any reference that it is an explicit goal, nor a proof. The closest I found are (A) "the protocol should prevent the intruder from gaining access to the host" but in that, host is not clearly encompassing the client; (B) claims that SRP is a superset of other password-based protocols where indeed both sides are authenticated. $\endgroup$
    – fgrieu
    May 18, 2018 at 13:42
  • $\begingroup$ @fgrieu One reference to this is in the TLS-SRP RFC regarding the premaster secret. tools.ietf.org/html/rfc5054#section-2.6 $\endgroup$
    – Myria
    May 17, 2019 at 20:21
0
$\begingroup$

The SRP protocol as defined in the RFC documents only authenticates the client to the server. However, you can add a role reversed SRP exchange before or after the SRP protocol exchange where the client role is taken by the server, and the server role is taken by the client with a server secret z and public verifier Z for x and v to authenticate the server to the client.

$\endgroup$
2
  • 1
    $\begingroup$ In the RFC, security against server impersonation comes from the fact that a fake server would not know the value "v" and thus would fail to calculate the correct "premaster secret". Further communication would then fail due to the server using bad MACs and being unable to decrypt further client messages. See tools.ietf.org/html/rfc5054#section-2.6 $\endgroup$
    – Myria
    May 17, 2019 at 20:19
  • $\begingroup$ As long as the secrets remain secret this is correct. If a client verifier v is exposed, impersonating the real server is possible against that client. Authenticating the server to the client with secret z and public verifier Z protects all the clients with compromised verifiers from bogus servers.. This safety holds through loss of the server's list of client verifiers v. The server's verifier Z is a public item already. Only the server's secret z remains as a choke point. $\endgroup$
    – malbrain
    May 18, 2019 at 22:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.