For CSRF tokens, mt_rand() is ok-ish but openssl_random_pseudo_bytes() is a lot better

You can use a CSRF token in URLs where, for example, requests that should be made using POST are being done using GET. Personally, I’d fix the underlying problem of using GET for state changes but that may not always be feasible in legacy apps.

Blocking on openssl_pseudo_random_bytes() was an issue prior to PHP 5.3.4. It may also be slow on Windows since the lack of /dev/urandom source leaves us with two other options to generate entropy which are not as fast.

mcrypt_create_iv() can be used as an alternative if you pass MCRYPT_DEV_URANDOM as an option. Otherwise it uses the blocking /dev/random source.

CSRF token should be unguessable. The token is the secret being kept from attackers. Thus a random 32 byte string is perfect. You can improve that (a little) by making tokens form specific (i.e. one token per unique form) since it limits the impact of having any one token disclosed. However, this into improbable territory though worth doing in the event that the improbable does happen (e.g. attacker gains access to browser history and reads a CSRF token from a past GET request).

Since the token is itself the secret, hashing it has no impact whatsoever. It just makes the hash the secret that needs keeping. Hashing is nearly always false security. What does this mean?

1. You don’t need to include session ID. That also increases the risk of implementation errors leaking session IDs.
2. You don’t need a server secret (i.e. salt) because hashing adds no security other than to obscure the session ID being used. See how this is adding complexity over just using a simple random string?
3. Hidden values are optional in forms so that would only impose an extra salting factor some of the time.
4. Other attempts of avoiding strong random tokens, e.g. uniqid(), are known to produce predictable values (or at least values easier to pin to a specific brute forcible range) since uniqid’s are generated using the server time (linear) and any extra entropy (set 2nd param to TRUE) is generated using an internal linear congruential generator which is widely panned as being predictable.

The core of the issue here is simple – why NOT just use a random string? Answer: There is no reason not to. It’s easily superior to all other methods.

Missing the point of CSRF tokens. It prevents an attacker from making the user’s browser submit a form automatically (e.g. XSS on another website or a phishing website). In those cases, the attacker does not have access to the user’s session ID for the target site. You can defeat CSRF protections on the target site by attacking it in other ways. For example – perform a Man-In-The-Middle attack on their connection, use an XSS vulnerability (any site) to perform a Man-In-The-Browser attack, exploit an XSS vulnerability on the target site (request form, get token, reuse token to submit form), or perform session hijacking to steal the session ID and masquerade as the user.

CSRF is a low level attack – it defends against one specific vector. Auto form submissions on visited sites other than the target site.

$_SESSION is a local server storage so not sure why you distrust it. The token must be known by both the server and the client. Session data on the client is presumed secure (short of a server breakin) and including in a return form from the client is secure (short of MiTM, MiTB and local XSS). In other words, CSRF tokens are only defeatable using a higher level attack.

Again, random string is random string. Hash is random string (need salt) + sensitive data (must be protected). You’re adding an ingredient for zero gain and more risk. More risk === bad.