Author | Message | Time |
---|---|---|
Barabajagal | 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... | September 11, 2008, 10:35 PM |
BreW | Now, tell me exactly why it would be less secure? so what if they intercept it? | September 11, 2008, 10:55 PM |
Barabajagal | 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? | September 11, 2008, 11:11 PM |
BreW | You do the math yourself. It's still a very tough cookie to brute force. | September 11, 2008, 11:29 PM |
Myndfyr | [quote author=Andy link=topic=17654.msg179791#msg179791 date=1221174702] 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? [/quote] Sheesh.... A and B are transmitted over the wire as part of SRP. 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. | September 12, 2008, 12:25 AM |
Barabajagal | I suppose it depends what you're trying to protect, then... Hiding data versus preventing the spoofing of data, yes? | September 12, 2008, 5:21 AM |
Myndfyr | [quote author=Andy link=topic=17654.msg179797#msg179797 date=1221196882] I suppose it depends what you're trying to protect, then... Hiding data versus preventing the spoofing of data, yes? [/quote] 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. | September 12, 2008, 5:24 AM |
Barabajagal | If you say so. | September 12, 2008, 5:54 AM |
iago | 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. | September 12, 2008, 1:07 PM |