New on the SitePoint "Web Tech" blog today is a post by Craig Anderson about friendlier passwords.

One aspect of web applications which is almost always overlooked when it comes to accessibility is how easy any randomly generated string might be to read. If you're lucky enough to have near perfect vision and have no learning or cognitive disabilities such as dyslexia, you mightn't suffer from any problems reading randomly generated strings, but for many users distinguishing between zero and upper-case Os, ones and lower-case Ls, and even the letters b and d can be difficult.

He includes a simple little PHP script that pulls letters and numbers from a pre-defined "friendly" array that can be read more easily by those with some sort of visual issue. Obviously, the results would be less secure than some other methods (only so many to go around) but its still a wide enough range for most common uses (around 17 million passwords).

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).

Rob Allen has posted this look at using hooks inside of action helpers (a follow-up from his previous article on action helpers):

Hooks are a feature of action helpers that allow you to automatically run code at certain points in the dispatch cycle. Specially, there are two hook functions available for action helpers: preDispatch and postDispatch. These allow you to ensure that some functionality is always run for each request.

He creates a simple action helper that grabs a random quote from an array and drops it into a property of the helper. By defining a preDispatch method inside of the helper, the HelperBroker knows to pull the method in an execute it immediate before the rest of the actions are executed. A calls to addHelper with the hooks defined is all it takes to glue it together with the execution.

Stefan Esser has released a new update (really two, but one is the latest) to his Suhosin patch for PHP - version 0.9.27.

The previous update (0.9.26) updated the utility with an improved randomness fixing a few issues with an ini setting and the uploadprogress extension as well as adding in a few new settings and updates to the randomizing functions that come included in PHP.

The 0.9.27 update (the most current) updates the patch with a lazy loading change that allows it to work correctly on systems that have it disabled by default (causing the previous patch to not work).

You can grab this latest release, 0.9.27, from the suhosin website.

Stefan Esser points out a problem with the mt_rand and rand methods in PHP that makes them not quite random enough for cryptographic uses.

PHP comes with two random number generators named rand() and mt_rand(). The first is just a wrapper around the libc rand() function and the second one is an implementation of the Mersenne Twister pseudo random number generator. Both of these algorithms are seeded by a single 32 bit dword when they are first used in a process or one of the seeding functions srand() or mt_srand() is called.

He looks at how its currently implemented, some examples of bad methods to get "random" numbers, how shared resources are a problem and an example of a cross-application attack (the application in more than once place using the same method for getting random numbers).

In the comments he recommends either grabbing from /dev/random (if you're on a unix-based system) or making the creation of your numbers a bit more complex to include things the outside world wouldn't know.

On his blog, Jonathan Street has posted some "random thoughts" on generating random (or not so random) strings in PHP.

Humans are astoundingly bad at being random and I just slapped the keyboard a few times until I felt I had the required 16 characters. Writing some code to produce a fairly random string is incredibly easy. I've easily done it a dozen times or more. Though only because it is easier to re-write it than to find where I put the last one

He gives two examples that work, but aren't the best possibilities for making truly random strings - one using mt_rand to select a random character from a string and the other using the same idea but instead using the char() function to replace the string of characters.

His other examples include the use of the uniqid function with the more_entropy setting enabled and an md5 or sha1 hash (for which he gives positives and negtives).

DevShed has posted the next (and last) part of their series on image generation with PHP, creating a class to handle most of the work for you and implement the graphics functionality (GD) PHP has built in. This time, they take things a step further and use the class they've created so far to make CAPTCHA images for a site.

In this last article of the series I'm going to show you how to couple this class with a simple randomizer mechanism to implement a basic yet effective application that will be capable of outputting on the browser different random strings, which will be previously embedded into a predefined image stream.

They start with their previous version of the class and work off of it, extending its functionality to add a multi-call ability and to hook into a RandomGenerator class to create the string.

Gareth Heyes has posted about a new plugin he's created , spam protection for his WordPress blog - SpamBam.

The latest plugin uses my PHP/JS randomisation techniques to create a key and protect against spam. I've took this bold move to see what affect it has and if the blog spammers will get round it because it no longer uses javascript cookies.

His plugin includes features including a lack of cookie use, delay on spammers (slows spam scripts) and doesn't use CAPTCHAs. You can also check out this section on Gareth's blog for the latest on the plugin.

Michael Kimsal points out a small utility to create information he found himself needing over and over - information that looks like, but is not, personal details.

I put together a small utility to generate random user data several months back. I realized yesterday that I hadn't released the source code - I thought I had. This generates plausible names, addresses, phone numbers and social security numbers. The phone number area codes don't generally match up with the address, but the addresses are accurate in that the city/state/zip all match. The addresses are currently US-based only. The code will also generate SQL statements for you to insert directly in to your database if selected.

You can download the PHP code for yourself or just use his copy to generate some sample information when you need it.

On the FuzzyOpinions blog, there's a basic tutorial that walks you through the creation of a CAPTCHA system to use how you'd like on your site. They target it towards the most common use - blocking unwanted comments to a site from spambots.

Although you might not know it by the name, a captcha is one of those little boxes you see, more and more lately, that ask you to type in a random code to verify that you are a human being and not a robot. There are many different varieties, but the basic idea is an image that is obscured slightly but readable by a human and used as a passcode for secure entry to a system or task.

The method is a simple combination of random text, a custom image, some of the PHP graphics functions, and a little addition to your HTML form (and PHP session) to get things up and running.