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?

$\endgroup$

closed as unclear what you're asking by D.W., e-sushi Mar 18 '17 at 15:47

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 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 '17 at 17:37
  • 1
    $\begingroup$ srp.stanford.edu/ndss.html#SECTION00032200000000000000 $\endgroup$ – Tony Mar 14 '17 at 17:40
  • $\begingroup$ Why downvote??? $\endgroup$ – Tony Mar 14 '17 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 '17 at 12:44
4
$\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.

$\endgroup$
  • $\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 '17 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 '17 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 '17 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 '17 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 '17 at 9:02

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