On the Delicious Brains site there's a new tutorial posted for the WordPress users out there sharing a case study of the performance impact of WP Offload S3 on the average page load time.

One of the great things about working at Delicious Brains is working on products that I use and love outside of work. I was a WP Migrate DB Pro customer well before joining the team and still use it daily on personal sites and side projects. However, I’ve not often had the need to use our other plugin, WP Offload S3 to offload site media files to Amazon S3.

The post starts with some of the background on why the author chose the WP Offload plugin in the first place and what features it provided. The tutorial then walks you through the installation process and how to have assets served up by Cloudfront correctly. It also includes some things you should consider when figuring out if this setup is for you. It then wraps up with some benchmarks of the results post-implementation, seeing a decrease of almost a second off of the previous page load time.

The Paragon Initiative has a post showing you how to prevent timing attacks when comparing strings using a double HMAC method. Essentially this method replaces timing safe comparison methods (non-native) using a constant key in the HMAC generation.

One of the common cryptographic side-channels that developers should be aware of is how long a specific operation, such as a string comparison, takes to complete. Thus, they are called timing attacks. [...] Timing attacks are possible because string comparison (usually implemented internally via memcmp()) is optimized. [...] These concerns have led many security to propose a Double HMAC strategy instead of writing a constant time comparison loop where one is not already provided (e.g. PHP before 5.6.0).

He points out that while the has_equals approach can be effective in preventing this kind of issue, if you're not running PHP 5.6 you're a bit out of luck. There are polyfill functions that mimic it but he suggests another option - the double HMAC. He includes an example of the code to perform this kind of evaluation, using the same constant key value in the HMAC generation for both input strings. He then refactors this and shows how to use a more randomized key making use of the native CSPRNG functions coming in PHP 7 (ployfill available for this too).

Pádraic Brady has a new post to his site talking about the recently announced (but actually relatively old) issue with PHP hash comparison, the "magic hash" issues.

A while back, I noticed a flurry of activity around a somewhat obvious outcome of PHP’s type juggling antics. As the snowball gathered pace and grew, it’s being more widely reported as a vulnerability dubbed “Magic Hashes”. What is this mysterious potential vulnerability in PHP applications? The vulnerability is a straightforward outcome of PHP’s type juggling antics.

He talks about the == (double equals) versus === (triple equals), how they differ and how the use of the triple equals basically negates this issue. The problem comes back around to PHP's type juggling and how it assumes equality based on the data given. He includes some specific examples showing places the issue can happen even when comparing two variables of the same type. He also makes a mention of another issue that can come in separate from this called timing attacks and how to prevent them as well.

In his latest post Anthony Ferrara talks about a tricky subject in PHP - timing attacks. A timing attack has to do with vulnerabilities that can come up because of the differences in time it takes to perform cryptographic operations (like hashing or encrypting).

An interesting pull request has been opened against PHP to make bin2hex() constant time. This has lead to some interesting discussion on the mailing list (which even got me to reply :-X). There has been pretty good coverage over remote timing attacks in PHP, but they talk about string comparison. I'd like to talk about other types of timing attacks.

He starts with a definition of what a remote timing attack is and provides an example of a simple script showing the delay that's key to the attack. His script deals with string location but it gives you an idea of how the attack works and where the danger lies. He points out that even remotely attackers could determine the times to perform operations (down to the nanosecond) and use this to their advantage. He points out that both == and === are vulnerable to this type of attack because of how the comparison happens. He gives two options (one an internal function) to help protect your application and briefly covers a few other types of timing attacks: index lookup, cache-timing and branch-based timing attacks.

In a new post to his blog Padraic Brady takes a look at remote timing attacks that happen on a nanosecond scale and whether or not we, as application developers, should take them seriously. Timing attacks involve gleaning information off of systems based on the response and execution time.

I’ve been following the progress of Remote Timing Attacks with a lot of interest over the years, during which time there has been an obvious trend in improving the technique. The most recent reported cases of Remote Timing Attack vulnerabilities, for example, were against the OpenID and OAuth protocols when it was reported in July 2010 that numerous open source implementations of these protocols did not prevent the disclosure of timing information that could enable a Remote Timing Attack. It is important to note that, as with many potential attacks, the protocols themselves contain no vulnerability. This is strictly a potential vulnerability contingent on the method of implementation.

He starts off by defining timing attacks in a bit more detail, including an example of how an attacker could determine the validity of a username based on the response time of how its handled. He continues on talking about how important the nanosecond is to attacks like this (might as well be minutes) and how things like the C function memcmp can be used to catch these tiny time differences. There's plenty more detail in between, but he finishes the post off with a look at what you can do to help prevent this type of attack from being useful on your applications.