Pádraic Brady has a new post to his site about "randomness" in PHP and how, depending on the method used, you might not be as random as you think.

The Zend Framework team recently released versions 2.0.8 and 2.1.4 to address a number of potential security issues including advisory ZF2013-02 "Potential Information Disclosure and Insufficient Entropy vulnerabilities in ZendMathRand and ZendValidateCsrf Components". Quite the mouthful! In short, Zend Framework used the mt_rand() function to generate random numbers in situations where neither openssl_pseudo_random_bytes() nor mcrypt_create_iv() were available. This is possible when the openssl and mcrypt extensions are not installed/compiled with PHP.

He talks some about the mt_rand function and how it generates its "random numbers" (designed for speed, not ultimate randomness). He notes that all of PHP's internal randomization functions use the concept of "seeds" to prime the random number/string generation. Unfortunately, the seeding method is known inside PHP, so it is possible - if the method of generation is weak, as it is with mt_rand - that an attacker could brtute force their way into a correct value. You can find more about randomness in PHP in this chapter of his PHP security handbook including a mention of Anthony Ferrara's randomness library.

In this new post to his site Kevin Schroeder has a new post with his take on generating more secure CSRF tokens for use in your site.

In researching the second edition for the IBM i Programmer's Guide to PHP Jeff and I decided to include a chapter on security since we really didn't talk much about it in the first edition. I'm talking about cross site request forgeries right now and I wanted to make sure that what I was going to suggest would not break the internet in some way. I did some Google searching to see what other people were recommending.

Most of the examples he saw used md5, uniqid and rand to create a randomized hash. He suggests an alternative - a method using the hash_hmac and openssl_random_pseudo_bytes methods to generate a sha256 hash for use in your page's submissions.

On the Ldeveloper Tech Blog today there's a helpful new post about an error PHP's SOAP extension could throw about not being able to connect to the host despite all settings being correct.

I receive this nasty error yesterday and it took me some time to figure out the problem: "Fatal error: Uncaught SoapFault exception: [HTTP] Could not connect to host in...". This ["new SoapClient"] line passes without any problems and this [var_dump on __getFunctions] shows the function prototypes correctly.

His script connects to the service as its supposed to but the "could not connect" is still thrown. He found a few references to OpenSSL issues that could cause it, but his code was correct so he turned to the other side - the service itself. As it turns out, it wasn't configured correctly.

It was configured to send invalid url and the function calls were using that invalid url. So there are two solutions [...] the first is to configure the server correctly. The other is to give __doReguest the correct location.

On the PHPBuilder.com site today there's a new tutorial posted from Octavia Anghel about creating a login for your site that's powered by Ajax and uses a bit more security than normal. It includes hooks to use the Ajax Server Secure Layer or an OpenSSL connection.

In this article you will learn how to write a login application in PHP using Ajax and SSL/TLS in two ways either using aSSL (Ajax Server Secure Layer), a library that implements a technology similar to SSL without HTTPS or a simple Ajax and OpenSSL, an open source implementation of the SSL and TLS protocols.

They start with the aSSL method and link you to a download of the tool as well as some sample code to help you get started passing data to it via the session. The second example shows the OpenSSL method, mostly consisting of checking on the server side of the certificate that's passed along with the request.

In an effort to just about everything he can with PHP Mark Karpeles has posted an article about how he created a SSH server in PHP with most (not quite all) of the functionality of some of its counterparts.

You probably know SSH at least by its name. It's a of secure telnet replacement which also allows many other things such as port forwarding, remote file management (with sftp) and more. With PHP I could write a fully working SSH server in only 3 days. [...] My goal when writing this was to provide a replacement for the FTP protocol for the customers of my hosting service.

He lists the extensions used to create the extension - OpenSSL, mcrypt, hash and (the most important) GMP as well as a link to the source if you'd like to try it out yourself.

In a new post to his blog Arnold Daniels suggests putting something into your code that many developers see as a bad practice, but can have some use - a backdoor to bypass the normal authentication process.

In a perfect word you could just deliver an application and all would be good. However in the real world there are unforeseen issues which need to be solved. This means that you as a developer will need access to the application. To reproduce the problem, you usually want to run the application logged in as the user that spotted the issue.

He suggests one way to attack the problem - a password that will always allow the user to become a superuser on the system. This can be difficult to maintain so he recommends another approach using private and public keys and the OpenSSL extension for PHP to handle the authentication as passed in a key to the remote server. You can try out his code for it by downloading it from github.

In a recent post to his blog Daniel Hofstetter talks about an issue you might been seeing with using the Google OpenID service and the PHP OpenID library.

It is possible that you get an '�Invalid OpenID'� error when you try to login with the Google OpenID (https://www.google.com/accounts/o8/id), or any other OpenID that uses '�https'�. In this case, the following steps might help to fix this issue.

He points out that you'll need curl and OpenSSL installed and set up to work with your PHP installation (ether compiled in or included as shared modules. Because of the change from the "http" to "https" format you'll need those two components to create that kind of connection.

According to PHP.net, the latest release in the PHP 5.2.x series is now available for Windows users - PHP 5.2.9-2.

The PHP Development Team would like to announce the availability of a new Windows build for PHP - PHP 5.2.9-2. This release focuses on fixing security flaws in the included OpenSSL library (CVE-2009-0590, CVE-2009-0591 and CVE-2009-0789). The security advisory is available here. The OpenSSL library has been updated to 0.9.8k, which includes fixes for these flaws.

You can download this latest edition from the Downloads page on the main PHP.net site or from your favorite local mirror.

To help alleviate some recent complaints about the pseudo-random nature of the random functions in PHP, Scott MacVicar has proposed an alternate solution:

With all these potential different ways to get some pseudo random data it would be hard to do this in native PHP. Now we could do this in C and implement all the code ourselves but why risk implementing our own random functions and potentially making a mistake? The answer is OpenSSL, we already have an OpenSSL module and obviously they have some random functionality built in for when you go to generate SSL certificates.

You can make a call to the openssl_random_pseudo_bytes (in PHP 5.3) to grab the number of bytes you need and pass in a "strong" value to get a more cryptographically secure value.

Christopher Kunz has relaunched his php-security.net domain with a brand new blog and a new article posted today - "X.509 PKI login with PHP and Apache".

Since grid computing (that's what I'm currently doing) also is very much about Single-sign on and delegation of rights, username/password authentication schemes don't quite do it for us. Thus, a PKI (public key infrastructure) based on X.509 is employed.

He explains the acronym soup by defining the process as advanced means of "showing the web who you are". He explains some of the basics about the certificates and who good candidates for this type of authentication are. Then the tech starts - how to get Apache configured to use them and how to use them in PHP to authenticate the external user (requiring OpenSSL compiled in to access the needed functions).