In the course of writing my little bnet emulation server, I came across something I didn't expect. The Client Token in AUTH_CHECK and LOGONRESPONSE2 are two separate values (though of course the server token is constant). I'm guessing every use of any hashing with Client Token uses a different value, which would explain why it's always sent as part of the same packet as the hash. I suppose this is more secure or something of the sort? Sorta seems less secure to me. I'd think only sending the client token once would make it less likely to be intercepted. Then again, I suppose the server doesn't want to store all those client tokens...
Now, tell me exactly why it would be less secure? so what if they intercept it?
Broken SHA isn't the most secure hashing algorithm as it is. Giving part of the contents of the hash seems... like a bad idea?
You do the math yourself. It's still a very tough cookie to brute force.
Quote from: Andy on September 11, 2008, 06:11 PM
Broken SHA isn't the most secure hashing algorithm as it is. Giving part of the contents of the hash seems... like a bad idea?
Sheesh.... A and B are transmitted over the wire as part of SRP (http://srp.stanford.edu/ndss.html). That guy at Stanford must be braindead. :P
The random tokens are sent over the wire to make it more complicated to duplicate the input or a value that makes the same result as the input. That's what they're there for. They make it tougher, not easier.
I suppose it depends what you're trying to protect, then... Hiding data versus preventing the spoofing of data, yes?
Quote from: Andy on September 12, 2008, 12:21 AM
I suppose it depends what you're trying to protect, then... Hiding data versus preventing the spoofing of data, yes?
You don't hide a secret when you hash it. All you can prove with a hash is that you had something that resulted in the same hash when you started.
If you say so.
The point of adding salting to a hash is to prevent computation attacks.
The client token prevents a malicious server from precomputing passwords and sending a known server token.