What's happening in our world

Today we updated loaders for OSX, Linux and Windows (main platforms that we support). Loaders for other supported platforms will be updated during the next major update or please contact us and we can update them sooner. 

 

This update fixes some issues with traits in PHP 5.4, 5.5 and 5.6 and as a result it fixes issues with Laravel 5 encoded files. As for Laravel, you may encode all the *.php files in the app, config, database etc folders. It's no reason to encode any vendor files as they are open source. Also do NOT encode resources and particularly views as they are not pure PHP regardless then have *.php file extensions too. 

 

If you are not sure how to install loaders or which one to choose, please use our online and free loader assistant

 

Security should always be in the forefront of any PHP developer's mind. With data breaches becoming a daily occurrence, and the cost of such data breaches often reaching into the millions of dollars (not to mention the PR disaster), developers absolutely must follow strict best practices to ensure that their code is not the vector from which such breaches occur. While it seems almost impossible to secure any system entirely, there are some essential concepts that developers must wrap their heads around in order to ensure as best they can that their applications are secure.

 

It's sad, but almost axiomatic - the user is responsible for a large number of security breaches. Whether they're a malicious user intent on breaking into your system or a hapless end user who uses the same password for every single website they have an account with, the user simply cannot be trusted from a security point of view. With that in mind, any good developer would implement a password hashing system to help prevent a malicious user from causing some serious harm - but considering the number of services, typically mobile, that transmit passwords as plain text, it bears mentioning.

 

In previous versions of PHP, password hashing was fairly simply to do badly, but far more difficult to do well. Hashing via MD5 or SHA1 were better than nothing, but adding a salt (a piece of data that prevents hackers from simply looking up an output string in a massive table to find the corresponding plain text) was an extra step that many developers skipped - and even those who took the time to include one couldn't completely preclude the possibility of a crack.

Fortunately, in the latest release of PHP, the long-awaited version 5.5, the language developers have finally implemented a far more secure method of natively hashing passwords, in the refreshingly simple password_hash() function. Instead of generating a 32 character hash, the string has been extended to 60 characters, and includes a cryptographic salt by default. However it also includes a new factor known as 'cost', which manages to even further obfuscate the passwords - and all wrapped up in a neat little function that's simple to implement. With any luck, as more and more developers begin to upgrade to version 5.5, we'll see a marked reduction in this sort of security breach.