This is one of the border cases where although one cannot definitively answer it with a clear, decided "No! This is how I could break it.", one still has to say "... but why do you want to do this if it is that easy to do it right?".
Can an attacker exploit
microtime being used as token? At least in theory, the answer must be: "Definitively, and easily". I haven't tried, so I couldn't tell for sure how hard it is, but it is certain that it is possible.
Can an attacker exploit
microtime fed into
mt_rand? Possibly, unlikely, almost certainly not. At least not with a compellingly high chance of success, and not without considerable work. Does that mean it's secure? No.
On the other hand, it doesn't really cost you anything to
a) use a token with more bits (32 really isn't a lot)
b) use a token that is unpredictable (strong random generator)
I would use a 64 bit token (128 if you are paranoid). Using a 128 bit token is of course much more secure against brute forcing, but since tokens have a limited lifetime of a few minutes and the amount of requests that can be sent over the network is limited, 64 bits should be just fine (and in case the user needs to type the key in, it means only half as much hassle for the user, also only using 64 bits will deplete the generator from entropy more slowly).
If your server has a gigabit uplink, it cannot possibly receive more than 1.1 million frames per second (assuming UDP and 8 bytes payload). If your tokens are valid for a "normal" amount of time, like e.g. 15 minutes, the chance of success of getting a hit while saturating the link during that time is 10-11. Also, apart from the diminuitive chance of success, if someone completely saturates the link for several minutes, this will not likely go undetected.
Setting up a huge botnet will be of no avail either. They can of course DoS you, but no matter what, no more frames can make it through the cable (physical limitation).
Compare that to a scenario where I might be guessing some correct token from another token that you have sent me or that I have eavesdropped with a chance of, say 1 in 100 (this should be feasible for a timer with the resolution of
microtime) simply by looking at the clock! Or compare it to a scenario where I can derive the state of your generator from 623 consecutive messages.
Even if I am rather unlikely to succeed at once, there's galaxies between this and a secure approach (and they both cost you the same).