Limited Pool of Challenge/Response Tuples

Presently, the Battle.net servers contain a fairly limited pool of possible challenge/response pairs for the version check and authentication system. Observations suggest that most products have a pool of around one thousand values that can be sent to clients. This has been used against Battle.net in the past, which was countered by an increase to 20000 possible values for several Battle.net products. Even with 20000 possible values, though, it is still possible to capture a large number of logon attempts over time and build a lookup table of possible values. This is an attractive option for an attacker, as he or she need only perform passive analysis over a period of time in order to construct a database capable of logging on to Battle.net with a fairly high success rate. Given the relative infrequency of updates to the pool of version check values (typically once per patch), this is considered to be a fairly viable method for an attacker to bypass the version check and authentication system.

This limitation could easily be addressed by Blizzard, however, such as through the implementation of one or more of the below suggestions:

1. Periodically rotate the set of possible version check values so as to ensure that a database of challenge/response pairs would quickly expire and need to be rebuilt. Combined with a large pool of possible values, this approach would greatly reduce the practicality of this attack. Unfortunately, the author suspects that this would require manual intervention each time the pools were to be rotated by the part of Blizzard in the current Battle.net server implementation.
2. Implement dynamic generation of pool values at runtime on each Battle.net server. This would require the server to have access to the requisite client binaries, but is not expected to be a major challenge (especially since the author suspects that Battle.net is powered by Windows already, which would allow the existing Lockdown module code to be cleaned up and repackaged for use on the server as well). This could be implemented as a pool of possible values that is simply stirred every so often; new challenge/response values need not necessarily be generated on each logon attempt (and doing so would have undesirable performance implications in any case).