6
$\begingroup$

I don't understand why TLS SRP (or SRP in general) includes the user name in verifier calculation, given that user name is basically public.

From spec RFC 5054 $x$, which is then used to calculate verifier, is calculated as follows:

x = SHA1(s | SHA1(I | ":" | P))

I thought about removing 'I' to facilitate changing of user names(verifier won't have to be recalculated). Then $x$ will be:

x = SHA1(s | SHA1(P))

However I'm not sure if it will have any negative impact on the protocol. Will that change decrease security?

Improve this question
$\endgroup$
6
  • 2
    $\begingroup$ The server can choose the salt, so it can start a multi-target attack by giving all users the same salt. $\endgroup$
    – CodesInChaos
    Jun 7, 2013 at 11:30
  • $\begingroup$ Not sure what you mean? Salt should be randomly generated, if it is not then it is implementation fault. $\endgroup$
    – nefarel
    Jun 7, 2013 at 14:55
  • 2
    $\begingroup$ Yes, salt should be randomly generated, but what if the server is malicious? It doesn't have to play by the rules. In this case the server can mount the multi-target attack spoken of. $\endgroup$
    – mikeazo
    Jun 7, 2013 at 16:18
  • $\begingroup$ @CodesInChaos Where do you see that the server chooses the salt? I suppose whoever chooses the salt also does the calculation of the verifier, so this entity already knows (or could know) the input of that calculation.) $\endgroup$
    – Paŭlo Ebermann
    Jun 9, 2013 at 16:36
  • $\begingroup$ Implementations I have studied have the client choose the salt. Having the client send it risk a weak random generator on the client. Modern browsers have window.crypto secure random so letting the client choose the salt seems the right approach. $\endgroup$
    – simbo1905
    Jun 4, 2014 at 14:15

1 Answer 1

Reset to default
9
$\begingroup$

One of the design goals of SRP is that it should be a zero-knowledge authentication protocol. This is to say, even the legitimate server should not be able to learn anything about the user's password (other than what it could learn using a generic brute force attack on the verifier).

SRP also assumes that the user may not be able to remember anything except their username and password. In particular, even though the user may choose the salt when they first compute their verifier, that salt is stored on the server and is sent back to the user by the server whenever the user wants to authenticate.

If the username was not included in the verifier calculation, a malicious or compromised server could try to learn whether user Alice had the same password as user Bob by sending Bob's salt to Alice when she tries to authenticate and seeing if the authentication (using Bob's verifier) still succeeds. Including the username in the verifier prevents this potential information leak.

Admittedly, this is a fairly minor leak, and probably not of much concern in practice. Still, it does violate the intended zero-knowledge property of SRP.

Ps. While looking at the SRP documentation to see if it says anything about this, I noticed something curious: the original 1998 paper defining SRP-3 doesn't seem to say anything about the username being included in the verifier calculation. Indeed, the protocol specification in section 3.2.2 simply says that:

"To establish a password $P$ with Steve, Carol picks a random salt $s$, and computes: $$x = H(s, P)$$ $$v = g^x$$

However, the SRP-6 paper starts off with:

"The original protocol, sometimes referred to as "SRP-3" for historical reasons and specified in [4], operates in a group defined by a large safe prime $p$ and a primitive root $g$. Reviewing briefly, the server computes its verifier value $v$ for a user identity $I$ as follows: $$x = H(s, I, P)$$ $$v = g^x$$

The reference "[4]" in the SRP-6 paper is not actually to the earlier paper, but to RFC 2945, which claims to describe the same protocol as the SRP-3 paper but does include the username in the calculation. So apparently this change was quietly made at some point between the publication of the SRP-3 paper in 1998 and its standardization as RFC 2945 in 2000.

Improve this answer
$\endgroup$
4
  • $\begingroup$ I am struggling to see how the minor leak works. Server sends bad 's', client then sends 'A' which incorporates random 'a' so no leak, client next sends 'M1' which incorporates random 'a'. So how can server sending a bad 's' learn of 'P' unless two clients chose the same 'a' for different logins where 'a' is a secure random number chosen by the client? $\endgroup$
    – simbo1905
    Jun 4, 2014 at 15:00
  • $\begingroup$ @simbo1905: The compromised server wants to know if Alice and Bob have the same password. So, when Alice tries to log in, the server looks up Bob's authentication data $(s_{\rm Bob}, v_{\rm Bob})$ and sends Alice $s=s_{\rm Bob}$ and (in SRP-6) $B=3v_{\rm Bob}+g^b$, gets back $M_1$ and verifies that it equals $H(A,B,S)$, $S=(Av_{\rm Bob}^u)^b$. If it does, Alice has just successfully authenticated herself as Bob, which (with overwhelming likelihood) means they must have the same password $P$ and identifier $I$. Assigning each user a separate $I$ (typically, their username) plugs this hole. $\endgroup$
    – Ilmari Karonen
    Jun 4, 2014 at 20:45
  • 2
    $\begingroup$ Why is (username + separator + password) additionaly hashed before adding salt? Would not x = SHA1(s | I | ":" | P) be enough? $\endgroup$
    – nefarel
    Oct 10, 2014 at 9:28
  • 1
    $\begingroup$ @nefarel: Dunno. I might mutter something about Merkle-Damgård length extension attacks, or about provable reducibility to the PRF-ness of the SHA1 compression function, but honestly I have no real idea. It looks sort of like a clumsy imitation of HMAC, but since the folks who designed SRP are pretty smart cryptographers, presumably it's a clever imitation of HMAC, I just don't know exactly how or why. That might make an interesting question in itself. $\endgroup$
    – Ilmari Karonen
    Oct 10, 2014 at 10:01

Your Answer

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

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