This happened on a sunday originally, right? Hence a small number of users logging in to the website. Pinpointing affected users could be as simple as finding the small number of accounts which were logged into from new IP addresses. Alternatively, perhaps the auth server was logging failed attempts, even though the bug resulted in failed attempts being treated as successful attempts. That would make it ridiculously trivial to find all of the accounts compromised - any account accessed with an incorrect password from a new IP address. The number of attackers doesn't matter.
Admittedly, I don't work for Dropbox, and am not aware of the details of how they identifying affected users. I'm just pointing out that it would be very easy to identify affected users with high accuracy and almost no chance of false negatives.
You don't think there were MANY accounts that logged in from new locations in that time frame? Think wireless networks...
I simply refuse to believe that with such a gigantic service they could determine that only X and Y were compromised by "one person" so accurately and so quickly--especially considering they haven't even implemented a build/deploy-time test suite that, among many other things, asserts that something like the auth system works actually works.
Your suggestion is pure speculation like you say, and, really, any application that logs something like "invalid auth" usually(!) immediately aborts the session (since that's the logical thing to do); it doesn't continue it...
Admittedly, I don't work for Dropbox, and am not aware of the details of how they identifying affected users. I'm just pointing out that it would be very easy to identify affected users with high accuracy and almost no chance of false negatives.