Encrypt session data in PHP

Zimuel writes; As promised in my last post I present an example of strong cryptography in PHP to secure session data.
This is a very simple implementation that can be used to improve the security of PHP applications especially in shared environments where different users have access to the same resources. As you know, the PHP session data are managed by default using temporary files. In shared environment a malicious user that is able to access to these temporary files can easly read the session data because they are stored in plaintext (data in a session file is theserialization of the array $_SESSION).
In theory, the session data should be stored in folders that are accessible only by the owner of the web site, but never say never (btw, you can manage the location of the session data using the session_save_path function or changing the session.save_path in the php.ini).

To secure the session data I used strong cryptography to encrypt the content using the mcrypt extension of PHP. I chosen the simmetric cipher AES (Rijandel-256) to encrypt the session data and the openssl_random_pseudo_bytes() function to generate a random key of 256 bit.
The idea is to use a cookie variable to store the key that will be used to encrypt the session data. In this way the key is stored only in the client (the browser) and only the client is able to decrypt the session data on the server. Each time we encrypt the session data we re-generate the IV vector in a random way using the mcrypt_create_iv() function. It is very important to generate a unique IV in each encryption. This best practice increase the security of the encryption algorithm.
It’s important to note that this implementation is not secure against session hijacking attack. If someone is able to capture the cookie variable of a client and have access to the temporary session files, in the server, he/she will be able to decrypt the session data. Our goal is to protect session data against attacks on shared environments.

The idea to encrypt the session data is not new, for instance Chris Shiflett proposed an implementation in his book “Essential PHP Security” (O’Reilly, 2006). Shiflett used a $_SERVER variable to store the key used to encrypt the session data. Kevin Schroeder, my colleague at Zend Technologies, implemented a very similar session encryption algorithm extending the Zend_Session class of Zend Framework (you can find it here). In my solution, I used some of the best practices related to strong cryptography to implement a secure session handler.

Below the source code of my implementation:

Full class @ Zimuel’s blog.

Bootstrapping Zend_Translate with a LangSelector Plugin

This entry is part 4 of 4 in the series Working with Zend_Translate and Poedit

As an update to the method of having everything related to Zend_Translate and Zend_Locale in the Bootstrap, here is an alternative using an Controller Plugin that does the grunt work of validating, selecting and updating the Zend_Locale, Zend_Registry & Zend_Session using Zend_Session_Namespace. And we are using poedit .po & .mo files as the source as usual.

Please comment as usual if you have a neater way of doing it 🙂


class Bootstrap extends Zend_Application_Bootstrap_Bootstrap {

protected function _initTranslate()
// Get current registry
$registry = Zend_Registry::getInstance();
* Set application wide source Locale
* This is usually your source string language;
* i.e. $this->translate('Hi I am an English String');
$locale = new Zend_Locale('en_US');

* Set up and load the translations (all of them!)
* resources.translate.options.disableNotices = true
* resources.translate.options.logUntranslated = true
$translate = new Zend_Translate('gettext',
'disableNotices' => true, // This is a very good idea!
'logUntranslated' => false, // Change this if you debug
* Both of these registry keys are magical and makes
* ZF 1.7+ do automagical things.
$registry->set('Zend_Locale', $locale);
$registry->set('Zend_Translate', $translate);
return $registry;

This little plugin will check every request for a lang paramenter and act on it.
It does not matter if you set the lang parameter using a custom route :lang/:controller/:action
or via a get/post ?lang= etc. one or all of them will work.


* @name App_Controller_Plugin_LangSelector
* @filesource library/App/Controller/Plugin/LangSelector.php
* @tutorial Instantiate in application.ini with;
* resources.frontController.plugins.LangSelector =
* "App_Controller_Plugin_LangSelector"
* @desc Takes the lang parameneter when set either via a
* route or get/post and switches Locale, This depends
* on the main initTranslate function in Bootstrap.php
* to set the initial Zend_Translate object.
* Inspiration from ZendCasts LangSelector.
class App_Controller_Plugin_LangSelector extends Zend_Controller_Plugin_Abstract
public function preDispatch(Zend_Controller_Request_Abstract $request)
$registry = Zend_Registry::getInstance();
// Get our translate object from registry.
$translate = $registry->get('Zend_Translate');
$currLocale = $translate->getLocale();
// Create Session block and save the locale
$session = new Zend_Session_Namespace('session');

$lang = $request->getParam('lang','');
// Register all your "approved" locales below.
switch($lang) {
case "sv":
$langLocale = 'sv_SE'; break;
case "fr":
$langLocale = 'fr_FR'; break;
case "en":
$langLocale = 'en_US'; break;
* Get a previously set locale from session or set
* the current application wide locale (set in
* Bootstrap)if not.
$langLocale = isset($session->lang) ? $session->lang : $currLocale;

$newLocale = new Zend_Locale();
$registry->set('Zend_Locale', $newLocale);

$session->lang = $langLocale;

// Save the modified translate back to registry
$registry->set('Zend_Translate', $translate);

Big thanks to Zend Cast for the inspiration!

Bootstrap Zend_Translate

This entry is part 2 of 4 in the series Working with Zend_Translate and Poedit

A recurring problem for site developers is implementing a solid way to create and maintain multilingual sites, this article series is my feeble attempt to guide you through how to quickly implement the Zend_Translate in an Zend Framework 1.9.x site.

The procedures and best practices for this is unfortunately like training a dog, everyone has a different way of doing it and an opinion, so the methods and code I show here are taken out of applications that are running in production so if you have a better way of doing it please feel free to comment!.

I usually use poedit a gettext editor which is available for most platforms to create my translation files, and after some initial configuration of the catalog paths so it can see your source files please see Part 1 of this article series.

The bootstrap below looks for the language specific gettext .mo files in /application/languages/ for example /application/languages/sv_SE.mo


protected function _initTranslate() {
// We use the Swedish locale as an example
$locale = new Zend_Locale('sv_SE');
Zend_Registry::set('Zend_Locale', $locale);

// Create Session block and save the locale
$session = new Zend_Session_Namespace('session');
$langLocale = isset($session->lang) ? $session->lang : $locale;

// Set up and load the translations (all of them!)
$translate = new Zend_Translate('gettext', APPLICATION_PATH . DIRECTORY_SEPARATOR .'languages', $langLocale,
array('disableNotices' => true));

//$translate->setLocale($langLocale); // Use this if you only want to load the translation matching current locale, experiment.

// Save it for later
$registry = Zend_Registry::getInstance();
$registry->set('Zend_Translate', $translate);

Now when you use statements like

translate('Contact Admin'); ?>
in your layout.phtml or view.phtml files it will be picked up by poedit and you will be presented with a string “Contact Admin” to translate, in my case i’ll just enter “Kontakta Administratören”.

There is some debate on what to put in the translate strings as identifiers, I personaly prefer the actual term to translate in a base language, in this case English instead of some convoluted “IDS0001” type strings.

Poedit will keep track of changes, i.e if I would change the “Contact Admin” to “Contact us” it will tell you on synchronization that “Contact Admin” disappeared and a new translation is required for “Contact us”. It’s quite easy to send those strings to your translators.

Thats it for today.