Weakness of SRP after server compromise From SRP section 3:


  The host stores user passwords as triplets of the form

{ &lt;username&gt;, &lt;password verifier&gt;, &lt;salt&gt; }

  
  Password entries are generated as follows:

&lt;salt&gt; = random()
x = SHA(&lt;salt&gt; | SHA(&lt;username&gt; | ":" | &lt;raw password&gt;))
&lt;password verifier&gt; = v = g^x % N

  
  Where g and N are agreed upon in advance.


They claim resistance against server compromise, but if an attacker gains access to the password verifier v, how much work is required per guess, to perform an offline brute force dictionary attack?

If I'm not mistaken, the work required for each password guess is two iterations of SHA, and then raising a single large exponent, and computing a single large modulo-division. This is not comparable to pbkdf2, bcrypt, scrypt, or similar, and probably shouldn't be considered a strong enough rate-limiter to protect a low entropy password.
From the Security Considerations -section of the RFC:


  Even
     if the host's password database were publicly revealed, the attacker
     would still need an expensive dictionary search to obtain any
     passwords. The exponential computation required to validate a guess
     in this case is much more time-consuming than the hash currently used
     by most UNIX systems. Hosts are still advised, though, to try their
     best to keep their password files secure.


So not much security is claimed in the case of password compromise. A dictionary search is possible, just deemed expensive, which it arguably was back then.

The "hash currently used" presumably means DES-crypt (bcrypt was new and as yet rare), which uses 25 iterations of slightly modified DES with only 56 bits of the password used. You can see how even two iterations of SHA-1 followed by a modular exponentiation could be better.