In a new post to his blog today Jordi Boggiano talks about a task that can trip up some developers when they're trying to secure parts of their site or just create one-time use tokens - making unpredictable hashes.

If you [override the default session handlers], unless you want to entrust PHP's core to do it, one thing you will have to take care of is generating unique session ids to send as a cookie to your users, allowing the session to persist. Other common use cases for such unique hashes is to generate CSRF tokens to insert in forms or URLs, and finally authentication tokens for email validation or such.

He talks about how we, as humans, aren't very good at figuring out true randomness and that hashing the information only adds to the problem. He mentions how some of the random functions in PHP aren't all that random and that there's a better way to really generate good values. He's come up with a solution (his "generateUniqueId" function) that tries to generate entropy from OpenSSL or from the COM extension or from the "/dev/urandom" on unix-based systems. It's then hashed and sent back out the other side for easy use.

In his latest post Paul Reinheimer looks at cross-site request forgeries and, despite the best efforts of the PHP security community, how developers still just miss the point in protecting their own code.

So, cross site request forgeries are a pretty common topic these days; they're in almost every security talk, book, site etc. This is okay; they're important [...] Most of the sites, and all of the books I've read demonstrate things correctly, but when it comes to actual implementation, time and time again, I see code that's just wrong.

He looks at two of the "essentials" when it comes to protecting you and your application - comparison (not taking other values of variables into account) and the unpredictable token (not making tokens, like md5 hashes of information, random enough).