On the CodeGeekz site there's a new post showing you how to use the Imagick extension and a custom library to crop images based on their entropy (keeping the "busiest" part of the image).

The need to resize and crop images in order to create thumbs, is a very common scenario for most websites. For example a blog like this one uses images in the content of the posts, images which at some point are used to create a thumb for the homepage. In most cases, the thumb's dimensions are not dynamic but are static throughout the website in order to better fit the template. This however creates a major problem when we try to automatically resize and crop our images in the desired dimensions.

He starts with an example of the normal kind of cropping based on a given height and width. He points out an issue with "smart cropping" and resizing the image with the cropping is done. Instead, he's made use of Imagick in his library to produce a better cropped image based on the parts of the image with the most entropy.

While not specifically related to PHP, this new post from Timoh looks at the idea of "aggressive password stretching" to help with a common problem in password-based systems - the poor choice of passwords from the application's users.

Practically speaking, "weak" means a user generated password will not contain enough guessing entropy to resist an adversary who managed to gain the user database dump, and who is able to run efficient offline attack against leaked hashes. Here comes in the need to make adversary's job harder, which is achieved by using the above-named algorithms.

He doesn't talk much about the actual password hashing itself, instead focusing on how the password stretching - the addition of more information not from the user (usually an automated source) to increase it password entropy. He goes through some of the math about how much extra work is required for an attacker with this method and some of the problems that can come with it. He talks about how much time should be spent in the hashing of the passwords and suggests that it's "a matter of finding a sweet spot between you and attacker's patience and the security gain" and not just about the security.

A bit more on the PHP-specific side, he briefly looks at the password_hash function and some of the defaults the more current frameworks use (hint: bcrypt all the things).

Proper password hashing is clearly not enough to make sure the password hashes are not weak. The other half of the job is a good password policy. No algorithm or setting will save passwords like "password" or "12345" etc. This is why we need to make sure the user's password will initially contain enough entropy itself.

On the Liip blog today Christian Stocker talks about a one-line installer that's been developed to get PHP 5.3 up and working on an OS X 10.6 platform without much hassle. The tool updates everything needed to get a bit more robust version of the language installed and ready for use.

Apple computers and OS X are quite common here at Liip (and local.ch) as developer machines. But while OS X comes with a not-too-old PHP installation, it nevertheless doesn't have everything we need (for example the infamous intl extension) and it's not that easily extendable with self-compiled extensions. [...] Our friends at local.ch took this very dissatisfying situation in their own hands, forked the build-entropy-php script from Marc Liyanage's great entropy work, extended and adjusted it to their (and our) needs.

If you'd like to try out the package on your own systems, you can find it and the full instructions for its use at http://php-osx.liip.ch/. He also points out the actual build part of the process (build-entropy-php) as well as the packager you'll need for it to grab the library updates it needs.

Seclists.org has posted an advisory titled "Weak RNG in PHP session ID generation leads to session hijacking." RNG stands for Random Number Generation, and the advisory is warning that not enough entropy is being used to seed the RNG; this, in turn, can lead to a reduced number of possible session IDs under certain specific conditions, thus making brute force session spoofing easier, if not bringing it into the realm of feasibility.

The threat is only marked at a "medium" level of severity, but it could still cause problems if you're not careful. There are specific conditions that have to be in place for it to be a problem including using the standard PHP session generation and that the app shares the information about remote users. To protect yourself you can either install Suhosin and don't use the result of set an external source for entropy to help randomize the session ID even more.