3
$\begingroup$

Let's assume that attacker knows the verifier so now the attacker can commit a Man-in-the-Middle (MitM) attack:

  1. Client sends A to server;
  2. MitM takes it and sends B to client.

As the MitM knows the verifier it is also possible compute the secret key. So every message from client encrypted by that key is not safe. How to deal with this situation?

Improve this question
$\endgroup$
4
  • 1
    $\begingroup$ Your assumptions are not fully clear to me. Are "server" and "client" using SRP? Is "verifier" the data known by server relative to client and its SRP-protected password, or something else? What are "client sends A" and "sends B to client" relative to SRP? $\endgroup$
    – fgrieu ♦
    Mar 14, 2017 at 17:37
  • 1
    $\begingroup$ srp.stanford.edu/ndss.html#SECTION00032200000000000000 $\endgroup$
    – Tony
    Mar 14, 2017 at 17:40
  • $\begingroup$ Why downvote??? $\endgroup$
    – Tony
    Mar 14, 2017 at 21:11
  • $\begingroup$ @Tony Single downvotes happen, often they will not be explained. I would not worry overly much. Spending some more time on the grammar and spelling / making your question look more professional may help against those. $\endgroup$
    – Maarten Bodewes ♦
    Mar 15, 2017 at 12:44

1 Answer 1

Reset to default
3
$\begingroup$

As pointed by the question, in SRP an attacker knowing the verifier can impersonate the server. That's not against the security objectives of SRP.

To carry the attack, the attacker also needs to know the salt, but it is public and can be obtained from the server. With both verifier and salt, the attacker then behaves with respect to the client just as the server does.

The problem of authenticating the server can be solved by https and a server certificate, inasmuch as you trust certificates (certificates only checked by a common web browsers/OS should be only marginally trusted: governmental and other well-founded adversaries can easily obtain a forged certificate with any CN field they wish, and certificate chain, that pass this test). It is still reasonable to use SRP on top of https with a server certificate: at least, if the certificate is subverted, the password does not leak, and the user can't be impersonated to the server (the main goal of SRP), contrary to what would happen with the password sent over https.

Improve this answer
$\endgroup$
9
  • $\begingroup$ Well, if a CA would miss-issue a certificate and got caught, you'd have a proof of it (the bad certificate) and chances are the browsers would distrust it rather sooner than letter. $\endgroup$
    – SEJPM
    Mar 14, 2017 at 19:53
  • 1
    $\begingroup$ @SEJPM: "got caught" requires that a knowledgeable person is convinced there is fraud, examines the certificate chain in detail (the rogue CA could be anywhere in the chain), and stores it for later proof; that's improbable for a few frauds. Further, purchasing a fake cert for some website/company from a good CA requires no more than temporary access to either its DNS server, or a phone or fax line; thus it is not very hard to get a rogue certificate from a good CA, and thus a rogue CA can get along with knowingly issuing a rogue certificate by pretending being victim of a similar fraud. $\endgroup$
    – fgrieu ♦
    Mar 14, 2017 at 21:54
  • $\begingroup$ I think the important point here is that if you can steal the verifier you can also steal the keys for the certificate and you probably have owned the server anyway so MitM is not really interesting anymore. $\endgroup$
    – Elias
    Mar 14, 2017 at 22:06
  • $\begingroup$ @Elias: in theory, serious servers are supposed to store the private keys for their certificates in a HSM, where it can't be stolen (only abused) by pwning the server; that's supposed to make it significantly less difficult to steal verifier then it is to steal the keys of the certificate. Sure, the verifiers might be stored encrypted and used in a HSM doing SRP, but that's moving from best practice to fiction. $\endgroup$
    – fgrieu ♦
    Mar 14, 2017 at 22:12
  • 1
    $\begingroup$ I don't use http or https. And SRP protocol was chosen to avoid certificates and CA. But as I can see we can not do this. $\endgroup$
    – Tony
    Mar 15, 2017 at 9:02

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