3
$\begingroup$

In RFC6628 section 2.2, they say:

w = The password remembered by the user.
W = The password verifier registered in the server. W = g^w mod p, where g and p are agreed upon in advance.

They claim resistance against server compromise. But if an attacker gains access to the password verifier W, how much work is the attacker required to do per password guess, in order to conduct an offline brute force dictionary attack?

If I'm not mistaken, the answer to this question is: The work required for each password guess is to raise a single large exponent, and compute a single large modulo-division. This is not comparable to pbkdf2, bcrypt, scrypt, or similar, and probably should not be considered a strong enough rate-limiter to protect a low entropy password against server compromise.

$\endgroup$
5
  • $\begingroup$ I don't think protection against server compromise is really in the threat model of SRP. Sure, the protocol as written provides some nontrivial protection but in practice you'd augment this with an additional layer of password hashing. $\endgroup$
    – pg1989
    Oct 11, 2015 at 19:21
  • $\begingroup$ RFC6628 is not SRP. They specifically mention SRP, and say they're better than SRP, and say they're designed to be resistant to server compromise, and describe it in section "3.5. Resistance to Server Compromise" $\endgroup$ Oct 11, 2015 at 19:52
  • $\begingroup$ As I see it, the same thing can be done here: simply use a password hash on $w$ before computing the verifier. Is there any reason this cannot be done? $\endgroup$
    – pg1989
    Oct 11, 2015 at 20:18
  • $\begingroup$ @pg1989, I guess you won't accept a "but the standard tells me to use the plain password"? $\endgroup$
    – SEJPM
    Oct 11, 2015 at 20:30
  • $\begingroup$ I agree, that is problematic. $\endgroup$
    – pg1989
    Oct 11, 2015 at 20:45

1 Answer 1

2
$\begingroup$

Yes, the protocol in RFC6628 (and SRP) is vulnerable to brute force password search in the event of server compromise. As Thomas Pornin puts it: for all password-based authentication protocols, what the server knows must allow for offline dictionary attacks, since an attacker who could get a complete snapshot of the server could simulate a client and a server on his own machines, and see when the simulated server accepts the password provided by the simulated client. This is rather unavoidable; thus, it is not a vulnerability of RFC6628/SRP specifically, but rather a vulnerability of authenticating clients with passwords.

That fact is acknowledged by a creative definition of resistance to server compromise:

An augmented PAKE protocol is said to provide resistance to server compromise in the sense that the attacker cannot impersonate the user without performing off-line dictionary attacks on the password verifier.

The only thing I can think of to improve on that is replacing the password on the server side by a conventional entropy-stretched (purposely slow) hash (such as scrypt) of the password, with salt set to username and serverid, computed on client side at each use. So we have that entropy-stretching hash as the last line of defense in case of server compromise. That would require trusted and reasonably efficient code implemented on the client side, which is hard to get with the current browser architecture.

Update: There's room to add such entropy-stretching in RFC6628. As an option, RFC6628 allows for use of a so-called effective password which is $w'=H'(\text{0x00}\|U\|S\|w)$ (where $H'$ is a hash function; $U$ is the user's identity; $S$ is the server's identity; $w$ is the password remembered by the user, after normalization per RFC4013), then used to compute $W=g^{w'}\bmod p$. So if we use that effective password option, and use an entropy-stretching hash for $H'$ (that is: a slow one, at least for input starting in $\text{0x00}$), we have some serious protection. A brute force password search would require one evaluation of $H'$ per $U\|S\|w$ tested, and some extra work involving modular arithmetic to test against $W$.

Without the effective password option, the amount of work to test a password in an off-line password search attack following server compromise can be down to near one modular multiplication: we can express most passwords $w_j$ that we want to test as $w_i+\delta$ with $\delta$ in a small set, implying that $W_j=W_i\cdot\Delta\bmod p$, with $\Delta=g^\delta\bmod p$ precomputed.

$\endgroup$
2
  • 2
    $\begingroup$ We can add that for all password-based authentication protocols, what the server knows must allow for offline dictionary attacks, since an attacker who could get a complete snapshot of the server could simulate a client and a server on his own machines, and see when the simulated server is content with the password provided by the simulated client. This is rather unavoidable; thus, it is not a vulnerability of SRP specifically, but rather a vulnerability of authenticating clients with passwords. $\endgroup$ Oct 11, 2015 at 21:07
  • $\begingroup$ I'm pretty sure we're all in agreement, that the password verifier in augmented pake does not offer sufficient protection against brute force of low entropy secrets, and the correct behavior is to apply rate-limiter at the client before sending expensive hash to server. But the question asks how much work per guess. So if you want to rephrase your answer, I'll give you credit. $\endgroup$ Oct 11, 2015 at 23:25

Your Answer

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

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