Ok, it seems that I've had a misunderstanding of what makes the Warcraft III login so different that at one time only BNLS was the only public way of logging in via Warcraft III. This was before the release of code such as iago's, JBLS (which used iago's code from what I've heard), and BNCSUtil (Relatively new).
I need some clarification please.
This thing called "SRP", which from what I already know, it is a hashing algorithm that is not used in previous clients and is what made BNLS so heavily dependant upon a fairly long time ago.
So, what I need to know is what role or roles does the "SRP" have in the Warcraft III Login? Does it only do handle the password and username hashing? Or does it also handle the hashing of the Warcraft III game files such as "war3.exe", "storm.dll", and "game.dll"? If it does not involve the local hashing of the Warcraft III game files, then is the same method of hashing Starcraft and other older client's game files used for Warcraft III game files?
What I previously thought was that SRP had something to do with the hashing of Warcraft III games files. I believe I am mistaken.
Please clarify for me. Thanks.
SRP stands for Secure Remote Passwords. It's an algorithm that was developed at stanford (http://srp.stanford.edu). It is a secure way to log into remote sites. Passwords are never sent over the wire in any way that could possibly be used to bruteforce them, and the server also confirms that it knows the password so not only are you authenticating to the server, the server is also authenticating to you.
In the War3 login, SRP is only used for encrypting the password.
http://www.javaop.com/~iago/SRP.html
Should be very helpful. I explain the packets is pretty gory detail.
If you have questions about it, I recommend posting them on http://www.x86labs.org/forum. I read that forum far more frequently than this one.
Quote from: iago on November 02, 2005, 10:56 PM
SRP stands for Secure Remote Passwords. It's an algorithm that was developed at stanford (http://srp.stanford.edu). It is a secure way to log into remote sites. Passwords are never sent over the wire in any way that could possibly be used to bruteforce them, and the server also confirms that it knows the password so not only are you authenticating to the server, the server is also authenticating to you.
Not only are passwords never sent over the wire, but passwords aren't actually stored on the server, either. Rather, a randomly-generated
salt value (which is like a seed) is stored as well as a password-based
verifier. The server has no need to store your password server-side, because all server-side authentication calculations are done with respect to the salt and verifier, and all client-side calculations are done with respect to the salt and public keys. :)
Ok, so what is used to locally hash Warcraft III game files then? The same method that is used to hash Starcraft game files?
Quote from: Sorc.Polgara on November 02, 2005, 11:14 PM
Ok, so what is used to locally hash Warcraft III game files then? The same method that is used to hash Starcraft game files?
Yes, as I recall, the same CheckRevision and broken SHA-1 hash are used in both.
Quote from: MyndFyre on November 03, 2005, 12:24 AM
Quote from: Sorc.Polgara on November 02, 2005, 11:14 PM
Ok, so what is used to locally hash Warcraft III game files then? The same method that is used to hash Starcraft game files?
Yes, as I recall, the same CheckRevision and broken SHA-1 hash are used in both.
Last I checked War III didn't use the brokrn SHA-1 atall.
Quote from: l)ragon on November 03, 2005, 10:22 PM
Quote from: MyndFyre on November 03, 2005, 12:24 AM
Quote from: Sorc.Polgara on November 02, 2005, 11:14 PM
Ok, so what is used to locally hash Warcraft III game files then? The same method that is used to hash Starcraft game files?
Yes, as I recall, the same CheckRevision and broken SHA-1 hash are used in both.
Last I checked War III didn't use the brokrn SHA-1 atall.
It uses standard SHA-1 in SRP, but not in the revision check.
[update]Hrm, after going through my code for MBNCSUtil apparently I am mistaken. CheckRevision doesn't use hashing at all, and the CD key hash code specifically has a standard SHA 1 provider. My mistake.