All of the PRNGs you listed are insecure. Anything dealing with security (sessions, tokens, secrets) requires a CSPRNG. Here are a list of suitable alternatives:
- mcrypt_create_iv() - Uses /dev/urandom on *NIX and the built-in crypto platform on Windows. Requires the 'mcrypt' extension.
- /dev/urandom - Requires a *NIX host.
- openssl_random_pseudo_bytes() - Requires the 'openssl' extension.
- http://barebonescms.com/documentation/csprng/ - A cross-platform solution that uses whatever is available plus a number of trusted remote web hosts that generate true random data.
As to your question regarding the paper, whatever algorithm you might come up with to generate a random string has probably been done before and the source code is likely available somewhere. If a PRNG is seeded with the current system clock in microsecond resolution, the search space is drastically reduced requiring only a few hundred thousand attempts. Combine that with maybe a few hundred common algorithms and you're looking at potentially mere seconds of CPU to reverse-engineer a token and synchronize with a remote system clock. After that, the application's security is hosed.
I guess the question is, will anyone care to hack your website at that level? Finding a SQL injection opportunity is generally a much easier route than trying to reverse-engineer a token scheme. Low-hanging fruit is more desirable to a hacker.