Return to Answer

The reason for this requirement is explained in section 3.2.4 of the original SRP paper.

If B is sent before A, then an attacker who has managed to obtain the password verifier v = g^x of another user (e.g., from the server storage), can successfully authenticate as this user without knowing their password-derived secret x. This works by sending a crafted A which cancels out the x term in the calculations of the shared secret S.

All calculations are modulo N:

1. Contrary to the standard protocol, the server first sends B = v + g^b to the attacker who masquerades as a legitimate client.
2. Knowing both v and B, the attacker can craft A as A = g^a * v^(-u), where u are the first 32 bits of SHA1(B). This A is what the attacker sends to the server.
3. According to the protocol, the server calculates the shared secret as S = (A * v^u)^b, which in this case results in S = (g^a * v^(-u) * v^u)^b = g^(ab). Note that the verifier v = g^x and therefore the secret x have been completely cancelled out due to the choice of A.
4. The attacker can calculate this shared secret with S = (B - v)^a = (v + g^b - v)^a = g^(ab).
5. Now the attacker is able to prove they know the session key K = SHA_Interleave(S).

This attack only works because the attacker knows B (and with it u) before they have to send their A. If the server follows the standard and demands A before revealing B, there's no way for the attacker to craft their A based on knowledge of B.

On a side note: SRP has been revised several times, and RFC 2945 describes the old version 3. The current version 6a is described in RFC 5054 in the context of TLS (it's referred to as version 6 in the RFC, but this is an error).

The reason for this requirement is explained in section 3.2.4 of the original SRP paper.

If B is sent before A, then an attacker who has managed to obtain the password verifier v = g^x of another user (e.g., through an SQL injection), can successfully authenticate as this user without knowing their password-derived secret x. This works by sending a crafted A which cancels out the x term in the calculations of the shared secret S.

All calculations are modulo N:

1. Contrary to the standard protocol, the server first sends B = v + g^b to the attacker who masquerades as a legitimate client.
2. Knowing both v and B, the attacker can craft A as A = g^a * v^(-u), where u are the first 32 bits of SHA1(B). This A is what the attacker sends to the server.
3. According to the protocol, the server calculates the shared secret as S = (A * v^u)^b, which in this case results in S = (g^a * v^(-u) * v^u)^b = g^(ab). Note that the verifier v = g^x and therefore the secret x have been completely cancelled out due to the choice of A.
4. The attacker can calculate this shared secret with S = (B - v)^a = (v + g^b - v)^a = g^(ab).
5. Now the attacker is able to prove they know the session key K = SHA_Interleave(S).

This attack only works because the attacker knows B (and with it u) before they have to send their A. If the server follows the standard and demands A before revealing B, there's no way for the attacker to craft their A based on knowledge of B.

On a side note: SRP has been revised several times, and RFC 2945 describes the old version 3. The current version 6a is described in RFC 5054 in the context of TLS (it's referred to as version 6 in the RFC, but this is an error).

The reason for this requirement is explained in section 3.2.4 of the original SRP paper.

If B is sent before A, then an attacker who has managed to obtain the password verifier v = g^x of another user (e.g., from the server storage), can successfully authenticate as this user without knowing their password-derived secret x. This works by sending a crafted A which cancels out the x term in the calculations of the shared secret S.

All calculations are modulo N:

1. Contrary to the standard protocol, the server first sends B = v + g^b to the attacker who masquerades as a legitimate client.
2. Knowing both v and B, the attacker can craft A as A = g^a * v^(-u), where u are the first 32 bits of SHA1(B). This A is what the attacker sends to the server.
3. The server calculates the shared secret as S = (A * v^u)^b = (g^a * v^(-u) * v^u)^b = g^(ab). Note that the verifier v = g^x and therefore the secret x have been completely cancelled out due to the choice of A.
4. The attacker can calculate the shared secret with S = (B - v)^a = (v + g^b - v)^a = g^(ab).
5. Now the attacker can prove they know the session key K = SHA_Interleave(S).

This attack only works because the attacker knows B (and with it u) before they have to send their A. If the server follows the standard and demands A before revealing B, there's no way for the attacker to craft their A based on knowledge of B.

Note that SRP has been revised several times. RFC 2945 describes the older version 3. The current version 6a is described in RFC 5054 in the context of TLS (it's referred to as version 6 in the RFC, but this is an error).

The reason for this requirement is explained in section 3.2.4 of the original SRP paper.

If B is sent before A, then an attacker who has managed to obtain the password verifier v = g^x of another user (e.g., from the server storage), can successfully authenticate as this user without knowing their password-derived secret x. This works by sending a crafted A which cancels out the x term in the calculations of the shared secret S.

All calculations are modulo N:

1. Contrary to the standard protocol, the server first sends B = v + g^b to the attacker who masquerades as a legitimate client.
2. Knowing both v and B, the attacker can craft A as A = g^a * v^(-u), where u are the first 32 bits of SHA1(B). This A is what the attacker sends to the server.
3. According to the protocol, the server calculates the shared secret as S = (A * v^u)^b, which in this case results in S = (g^a * v^(-u) * v^u)^b = g^(ab). Note that the verifier v = g^x and therefore the secret x have been completely cancelled out due to the choice of A.
4. The attacker can calculate this shared secret with S = (B - v)^a = (v + g^b - v)^a = g^(ab).
5. Now the attacker is able to prove they know the session key K = SHA_Interleave(S).

This attack only works because the attacker knows B (and with it u) before they have to send their A. If the server follows the standard and demands A before revealing B, there's no way for the attacker to craft their A based on knowledge of B.

On a side note: SRP has been revised several times, and RFC 2945 describes the old version 3. The current version 6a is described in RFC 5054 in the context of TLS (it's referred to as version 6 in the RFC, but this is an error).

The reason for this requirement is explained in section 3.2.4 of the original SRP paper.

If B is sent before A, then an attacker who has managed to obtain the password verifier v = g^x of another user (e.g., from the server storage), can successfully authenticate as this user without knowing their password-derived secret x. This works by sending a crafted A which cancels out the x term in the calculations of the shared secret S.

All calculations are modulo N:

1. Contrary to the standard protocol, the server first sends B = v + g^b to the client.
2. Knowing both v and B, the attacker can craft A as A = g^a * v^(-u), where u are the first 32 bits of SHA1(B). This A is what the attacker sends to the server.
3. The server calculates the shared secret as S = (A * v^u)^b = (g^a * v^(-u) * v^u)^b = g^(ab). Note that the verifier v = g^x and therefore the secret x have been completely cancelled out due to the choice of A.
4. The attacker can calculate the shared secret S with S = (B - v)^a = (v + g^b - v)^a = g^(ab).
5. Now the attacker can prove they know S.

This attack only works because the attacker knows B (and with it u) before they have to send their A. If the server follows the standard and demands A before revealing B, there's no way for the attacker to craft their A based on knowledge of B.

Note that SRP has been revised several times. RFC 2945 describes the older version 3. The current version 6a is described in RFC 5054 in the context of TLS (it's referred to as version 6 in the RFC, but this is an error).

The reason for this requirement is explained in section 3.2.4 of the original SRP paper.

If B is sent before A, then an attacker who has managed to obtain the password verifier v = g^x of another user (e.g., from the server storage), can successfully authenticate as this user without knowing their password-derived secret x. This works by sending a crafted A which cancels out the x term in the calculations of the shared secret S.

All calculations are modulo N:

1. Contrary to the standard protocol, the server first sends B = v + g^b to the attacker who masquerades as a legitimate client.
2. Knowing both v and B, the attacker can craft A as A = g^a * v^(-u), where u are the first 32 bits of SHA1(B). This A is what the attacker sends to the server.
3. The server calculates the shared secret as S = (A * v^u)^b = (g^a * v^(-u) * v^u)^b = g^(ab). Note that the verifier v = g^x and therefore the secret x have been completely cancelled out due to the choice of A.
4. The attacker can calculate the shared secret with S = (B - v)^a = (v + g^b - v)^a = g^(ab).
5. Now the attacker can prove they know the session key K = SHA_Interleave(S).

This attack only works because the attacker knows B (and with it u) before they have to send their A. If the server follows the standard and demands A before revealing B, there's no way for the attacker to craft their A based on knowledge of B.

Note that SRP has been revised several times. RFC 2945 describes the older version 3. The current version 6a is described in RFC 5054 in the context of TLS (it's referred to as version 6 in the RFC, but this is an error).