I've been looking through RFC 2945 on the SRP authentication method (the one described in that article is SRP-3), and I'm not quite catching on to what he says.  First:

[quote]
        <salt> = random()
        x = SHA(<salt> | SHA(<username> | ":" | <raw password>))
        <password verifier> = v = g^x % N
[/quote]

He never defines g or N.  I realize N is the modulo root for the function by which all modulo operations take place, but what is g?  [edit: I see it says "g should be a generator modulo N (see [SRP] for details), which means that for any X where 0 < X < N, there exists a value x for which g^x % N == X."  Is this coded into the client?]

Then he says:
[quote]
  Authentication is generally initiated by the client.

      Client                            Host
    --------                          ------
      U = <username>              -->
                                    <--    s = <salt from passwd file>
[/quote]
I don't see inside of the documentation of the BNLS protocol spec anywhere where Battle.net transmits its salt to the client (as the only communication required to Battle.net is 0x50 and 0x51 before logon is attempted); after CD key verification is complete via X-SHA-1, the client can procede to log on using 0x53.  Does that mean that Battle.net uses the same salt for every client?

They then establish that they have the same key; this is part of the function of BNLS_LOGONPROOF (correct?) -- the client should abort the connection, according to the RFC, if B % N is 0.

Ultimately, I get the impression that the Battle.net auth scheme is something along the lines of:

[code]
        Client                            Host
      --------                          ------
        U, A                        -->
                                    <--    s, B
        H(H(N) XOR H(g) | H(U) | s | A | B | K)
                                    -->
                                    <--    H(A | M | K)
[/code]

Any help or clarification here from those of you experienced in this area?  I feel lost in adapting the SRP RFC to the actual thing.

I haven't had a chance to look too deeply into what Warcraft 3 is doing, but at first glance it looks like Blizzard is using a "modified" SRP implementation.  I don't know how strictly I should read that "SHA(<salt> | SHA(<username> | ":" | <raw password>))" line, but I haven't found that code in Warcraft 3 yet, though I have found similar.  Perhaps finding a SRP implementation in another program to use as reference would help?

[quote author=MyndFyre link=topic=9919.msg92549#msg92549 date=1103157101]
I've been looking through RFC 2945 on the SRP authentication method (the one described in that article is SRP-3), and I'm not quite catching on to what he says.  First:

[quote]
        <salt> = random()
        x = SHA(<salt> | SHA(<username> | ":" | <raw password>))
        <password verifier> = v = g^x % N
[/quote]

He never defines g or N.  I realize N is the modulo root for the function by which all modulo operations take place, but what is g?  [edit: I see it says "g should be a generator modulo N (see [SRP] for details), which means that for any X where 0 < X < N, there exists a value x for which g^x % N == X."  Is this coded into the client?
[/quote]

Yes, it's coded into the client.

g = {47}
N = {0x87, 0xc7, 0x23, 0x85, 0x65, 0xf6, 0x16, 0x12, 0xd9, 0x12, 0x32, 0xc7, 0x78, 0x6c, 0x97, 0x7e, 0x55, 0xb5, 0x92, 0xa0, 0x8c, 0xb6, 0x86, 0x21, 0x03, 0x18, 0x99, 0x61, 0x8b, 0x1a, 0xff, 0xf8}

...according to iago's SRP.java.

[quote]
Then he says:
[quote]
  Authentication is generally initiated by the client.

      Client                            Host
    --------                          ------
      U = <username>              -->
                                    <--    s = <salt from passwd file>
[/quote]
I don't see inside of the documentation of the BNLS protocol spec anywhere where Battle.net transmits its salt to the client (as the only communication required to Battle.net is 0x50 and 0x51 before logon is attempted); after CD key verification is complete via X-SHA-1, the client can procede to log on using 0x53.  Does that mean that Battle.net uses the same salt for every client?
[/quote]

The BNLS spec doesn't really define anything about the protocol other then telling us how many dwords are in the packet.  I'm pretty sure this is how it's defined:

[code]
S->C SID_AUTH_ACCOUNTLOGON
(DWORD)  Status
(DWORD[8]) s - Salt
(DWORD[8]) B - server public key
[/code]

[quote]
They then establish that they have the same key; this is part of the function of BNLS_LOGONPROOF (correct?) -- the client should abort the connection, according to the RFC, if B % N is 0.

Ultimately, I get the impression that the Battle.net auth scheme is something along the lines of:

[code]
        Client                            Host
      --------                          ------
        U, A                        -->
                                    <--    s, B
        H(H(N) XOR H(g) | H(U) | s | A | B | K)
                                    -->
                                    <--    H(A | M | K)
[/code]

Any help or clarification here from those of you experienced in this area?  I feel lost in adapting the SRP RFC to the actual thing.
[/quote]

You scheme looks correct.  I'd take a look at iago's code for more information and this webpage.  I'd like to see a nice text developed about Battle.net use of SRP with samples and such.  Perhaps we can do that in this thread?

[quote author=EpicOfTimeWasted link=topic=9919.msg92553#msg92553 date=1103162132]
I haven't had a chance to look too deeply into what Warcraft 3 is doing, but at first glance it looks like Blizzard is using a "modified" SRP implementation.  I don't know how strictly I should read that "SHA(<salt> | SHA(<username> | ":" | <raw password>))" line, but I haven't found that code in Warcraft 3 yet, though I have found similar.  Perhaps finding a SRP implementation in another program to use as reference would help?
[/quote]

The war3 version looks like this:
[code]        username = username.toUpperCase();
        password = password.toUpperCase();
        MessageDigest mdx = MessageDigest.getInstance("sha-1");
        mdx.update(username.getBytes());
        mdx.update(":".getBytes());
        mdx.update(password.getBytes());
        byte []hash = mdx.digest();

        mdx = MessageDigest.getInstance("sha-1");
        mdx.update(salt);
        mdx.update(hash);
        hash = mdx.digest();

        return new BigInteger(1, reverseArray(hash, SHA_DIGESTSIZE));
[/code]

The white paper at http://srp.stanford.edu was quite good for giving a high level overview.  If you can understand that, you are already most of the way there.

Ok, apparently I'm quite wrong about my modified SRP theory then.  I had only gotten so far as to see the strupr()s and some odd little hashing functions, but nothing that looked like sha1(username . ":" . password);  Guess I'll have to look a bit closer.  Thanks, though.

I recall somebody saying something about War3's algorithm being similar to SRPv3 (where the current is v6).  But I can't confirm or deny that.

What Blizzard uses is quite similar to SRP, I think there was only one function that didnt make sense.

[quote author=iago link=topic=9919.msg92604#msg92604 date=1103222934]
I recall somebody saying something about War3's algorithm being similar to SRPv3 (where the current is v6).  But I can't confirm or deny that.

What Blizzard uses is quite similar to SRP, I think there was only one function that didnt make sense.
[/quote]

Do you remember what?  I remember Skywing saying something about this, but he didn't elaborate.  I was looking through the RFC link above and it looks exactly like Battle.net implementation.  The only thing I noticed it didn't follow is the host doesn't disconnect if A % N = 0, which could be  security vulnerability; but nothing I was able to exploit.  It looks to check that in SID_AUTH_ACCOUNTLOGONPROOF and not SID_AUTH_ACCOUNTLOGON.

I checked with Skywing, and he confirmed that BNLS doesn't actually use your password during the first time you send it.  The data is only used in the second packet (the logon proof one, with data you send to BNCS in 0x54).

There is a bug though, he said, that causes the server to fail to authenticate some sessions randomly where they would be correct.

[quote author=MyndFyre link=topic=9919.msg92999#msg92999 date=1103530788]
I checked with Skywing, and he confirmed that BNLS doesn't actually use your password during the first time you send it.  The data is only used in the second packet (the logon proof one, with data you send to BNCS in 0x54).

There is a bug though, he said, that causes the server to fail to authenticate some sessions randomly where they would be correct.
[/quote]

Ahh, yes this is expected since SID_AUTH_ACCOUNTLOGON is a random public key and username.  Did he elaborate on the bug?  If not, anyone else know anything about this or perhaps Skywing himself can?

[quote author=dxoigmn link=topic=9919.msg93000#msg93000 date=1103533150][quote author=MyndFyre link=topic=9919.msg92999#msg92999 date=1103530788]I checked with Skywing, and he confirmed that BNLS doesn't actually use your password during the first time you send it.  The data is only used in the second packet (the logon proof one, with data you send to BNCS in 0x54).

There is a bug though, he said, that causes the server to fail to authenticate some sessions randomly where they would be correct.[/quote]Ahh, yes this is expected since SID_AUTH_ACCOUNTLOGON is a random public key and username.  Did he elaborate on the bug?  If not, anyone else know anything about this or perhaps Skywing himself can?[/quote]

There's a buffer mismanagement bug in the BNCS code that causes it sometimes to get the wrong result, and then it punishes you when you send an answer that's actually correct, since you two don't match.  There's been some discussion of having BNLS attempt to warn you of an impending BNCS bug, since the client (which in this case means BNLS since it's the one doing the NLS work) can detect that the bug will occur, but by the time it's detectable, it's too late to change the parameters.

They do indeed use SRP-3 and a slightly modified out-of-the-box implementation available on the site.