SRP man-in-the-middle

Question

This site suggests that Secure Remote Password protocol is secure when "Attackers can intercept, modify, and forge arbitrary messages between client and server."

However, from a quick reading of the Wikipedia page on SRP [1], it seems that an obvious shortcoming of the method is that the server cannot, in general, be trusted. Since organization-hacking and stealing of credentials is the problem that is being addressed by not storing passwords in plain-text, the client's password verifier and salt ($v$ and $s$ in the notation of [1]) cannot be assumed to be known only to the server. Therefore an attacker with knowledge of $v$ and $s$ (stolen from the server) could perform a man-in-the-middle on an SRP authentication, obtaining the symmetric key using the same procedure as the server. Using the known symmetric key, it seems that the attacker can now issue arbitrary requests to the server masquerading as the client.

I'm not a security expert, so I'm almost certainly missing something here. What's the catch?

Answer 1

The attack outlined in the question does not work, at least as is. Still, SRP6a is very vulnerable to leak of server data, which is not part of the threat model that it addresses.

An attacker Mallory with knowledge of $v$ and $s$ (stolen from the server) can indeed masquerade as the server to the client and establish a shared key with the client. However, without the password, Mallory can not masquerade as the client to the server and get to the point where the server uses a private key. Further, if Mallory attempts to hijack a connection previously established with the server by the legitimate client, that will fail because that connection uses another private key than the one shared between client and Mallory.

However, with $v$ and $s$ stolen from the server, and pure SRP6a, an adversary can find a weak password by a dictionary attack (trying likely passwords sequentially starting from most likely), and then impersonate the legitimate client to the server. Technological progress ("Moore's law") tends to make SRP6a proportionally less secure from that standpoint. The only way around (beside not letting $v$ and $s$ leak, or hoping users will magically start using strong passwords) is that SRP6a is modified yet again by using a slow key derivation function for passwords (also known as password hash, password-based key derivation function) such as PBKDF2, Bcrypt, Scrypt, Argon2, Balloon instead of a fast hash.

Bottom line: when using SRP6a, if $v$ and $s$ being stolen from the server is considered possible, then the client software must implement a properly parametrized slow key derivation function for passwords; with the choice of that function, parametrization, and where the salt comes from not defined by any standard that I am aware of, including RFC5054 or ISO/IEC 11770-4:2006 (did not check the latest version). Correspondingly, practice is overwhelmingly to ignore SRP and send the password as keyed-in within an https tunnel (with the problem that a bogus certificate or a variation of the correct domain name that pass user scrutiny glance will reveal the user's login/password to a competent attacker). That practice also solves the problem that typical browsers have no built-in SRP client support, and that bringing one thru https as Javascript is vulnerable to the aforementioned attacks of https.