The idea of Shoppimon is simple – we want to provide Web monitoring and availability analysis which will be useable by, and useful to “normal” people – not only the tech guy, the programmer or the IT specialist, but the site owner, the business owner or even the marketing guy – in other words the real stake holder.

Shoppimon focuses on synthetic monitoring – it simulates real users going through the store and logs their “experience” – any errors encountered, overall time to complete certain actions, etc. – as such it complements real-user monitoring that products like Zend Server provide). In comparison to existing synthetic Web monitoring services, we want Shoppimon to be a snatch to get started with, an inexpensive solution that would be useful to even the smallest commercial site owners, and most important using it should not require one to be a tech savvy person.

Shoppimon is focusing on Magento – a popular PHP / Zend Framework based eCommerce solution. Magento has proved to be a popular eCommerce solution and has grown a rich ecosystem of developers and service providers around it, and has a rich community of users. But as most PHP programmers know, managing Magento’s availability and performance isn’t easy. It’s a heavy application, one of the heaviest PHP apps ever built, and the codebase is somewhat complex. Our goal is to help Magento store owners find (and fix) problems in their stores, and show them how their store compares to others.

This is why we decided to focus Shoppimon on Magento and provide objective scientific data (which we present in an easy-to-digest way) that would help Magento store owners (and in turn their developers and hosting providers) to enjoy smooth sailing.

Technically, Shoppimon is pretty interesting (hey, otherwise I wouldn’t have done it) – it has parts written in different programming languages. It is entirely based on Cloud technologies. The front-end runs on Zend Framework 2.0 (it is possibly the first commercial app to be out there running on ZF 2.0) and on Zend Server. The backend parts mix PHP, Java and Python (a long story…) and uses some very interesting technology to simulate real shoppers browsing around on the Magento sites we test.

In the next few weeks I’ll probably be posting more about how stuff work at Shoppimon under the hood. Stay tuned!

So, the topic in question is “what is the right way to store user passwords in my DB”. To be clear, I am talking specifically about the passwords users will use to log in to your application, not some 3rd party password you need to store for whatever reason. This is something almost any application out there requires – unless you interface with some external authentication mechanism (OAuth, openId, your office LDAP or Kerberos server), there’s a very high chance you’ll need to authenticate users against a self-stored user name and password.

In order to figure out what is the best solution, let’s start by going over the problems we might face if we simply take the naive approach and store passwords in their original, clear text form:

• If our database gets hacked (for example if we are exposed to an SQL injection attack through some 3rd party app we have installed on our server), passwords could get stolen. Clear-text passwords could easily be used to hijack our users’ accounts. In many cases, even if we ignore the risk of a hacked database – a clear-text password can be stolen by a disgruntled worker with access to the DB.
• Moreover, users tend to use the same passwords for all sorts of different services. If I know someone’s password to one service, chances are I can use the same password or a similar one to impersonate that user in other sites as well. Most users do not consider the fact (but you should!) that when they type in a password for your silly site with funny kitten pictures, there’s a good chance they are entrusting the password to their bank or PayPal account in your hands.

Given the points above, it is our responsibility as web developers to ensure that nobody, not even us, could get a clear-text version of the user’s password. So what’s the right way to do that?

Best solution: avoid the problem all together

The best way is, of course, not to store passwords at all. If functional and business terms allow, you should consider using some other authentication mechanism like OAuth or OpenID – basically let someone else worry about storing sensitive data. Many users have Google or Facebook profiles, and you can find several examples of pretty big websites that simply let users authenticate through these providers instead of through their own identity management service. This is an elegant solution, but clearly it does not work in all cases. If you still need to store passwords, read on.

Password Hashing

One aspect of passwords is that really, you have no use for their actual value. A password can be anything, and as long as the user repeats the same initial password when asked to sign in, you do not care what the password’s textual value is. This is important, because it means we don’t need to store the original value of the password: it is safe to store a product of the password, and as long as we know how to reproduce this product from a typed-in password, we can compare the products and not the password itself.

Sounds confusing? Here is a simple example: assume that instead of passwords, our site uses numbers to authenticate users. Each user has to provide a user name and a random number as a password. Before we store this “password” in our DB, we pass it through this simple mathematical function:

    f(x) = x * 5

So if a user types in “4709″ as a password, we multiply that number by 5 and store the value “23545″ in our DB. When the user attempts to sign in again, we pass the value typed in as password through the same function. If we get “23545″ as the product of the typed in password passed through our function, we know the user typed in the right password.

This is good, because now the value stored in our DB is not the actual password, but an obscure value (well, sort of). If someone steals our DB, they can type in “23545″ into the sign-in form all day – but that’s not the right password (remember, we multiply whatever is typed in by 5 before comparing it!).

Unfortunately, things are not that easy. First, it’s enough for someone to know that we multiply numbers by 5 to obfuscate them, and they can easily reverse engineer passwords by dividing the data stored in the DB by 5 – our function is reversible. Second, a smart enough hacker looking at our list of stored password values would probably notice that all of them are multiples of 5 – so even without knowing what we do in advance, reverse engineering our “security” method is quite easy.

As it turns out, the approach is right but the function we are using is too simple. What we need is a function that:

• Is irreversible, or at least is impossible to reverse in the real world. In other words, even if one knows both the result and the function used, computing the input value will be impossible or impractical.
• Is indeed a function in the mathematical sense – that is given the same input value, only a single outcome is possible, and the same outcome is always produced for the same input. For example, a computer function which multiplies the input value by a random number is no good for us.
• Produces a distinct, single value for each input value – or at least provides a very low risk of producing the same result for two input values. This is important because we want to make sure that only one typed-in password matches the obscured value stored in the DB.

Of course, most of us are not mathematicians – so you’d be happy to know that  such functions exist, and are usually referred to as “hash functions”. Hash functions use used extensively by programmers for all sorts of uses, and cryptography is most definitely one of them. A few popular and useful cryptographic-grade hash functions are MD5, SHA-1 and SHA-2. We will not go into the mathematical definitions of these functions (I have very little knowledge of how these functions actually work!) – it’s enough to say pretty much every popular programming language  out there has at least one implementation of these functions.

As an example, the MD5 function produces a 128-bit “hash value” for an input value provided to it. The hash is always 128 bit long, regardless of the input size. It will always produce the same hash value for the same input. The most successful known collision attack (that is an attack producing the same hash value for a modified input value) on MD5 took about 2 million execution attempts which makes it quite bad for validating SSL certificates (which it used to be used for), but still sort of Ok (although not great) for password hashing.

To compute an MD5 hash value in PHP, you can do the following:

    php > echo md5("my name is Inigo Montoya");
    d9937edae7d26a399d41dda16f137e42

As you can see the MD5 value of the string “my name is Inigo Montoya” is “d9937edae7d26a399d41dda16f137e42″ (this is in fact a hexadecimal representation of the MD5 value, which is a 128 bit number – this is the standard way to present hash values of various functions). On the other hand:

    php > echo md5("my name is Indigo Montoya");
    ae7cd5e68c73f9f44df66030cc9d1c06

Even a slight change in the input text produces a completely different MD5 hash.

It’s time to stop using MD5 for cryptographic purposes

While MD5 was the de-facto standard for storing hashed passwords for some time, it is now becoming clear that it may not be suitable for cryptographic purposes (it is definitely suitable for other things). In 2009 it was shown that producing collisions for MD5 can be done within seconds or minutes on commodity hardware – this does not mean it is easy to reverse engineer password values stored in your DB as MD5 hash values, but it does mean that if a highly skilled hacker wants to specifically target your site, they have a better chance of succeeding in doing so. In addition, it is safe to assume additional vulnerabilities will be detected in the future.

Unless you are somehow limited (not if you’re a PHP developer!), switching to stronger hash functions such as SHA-1 or SHA-256 is highly recommended.

Throughout the rest of this article I will use SHA-1 in examples. SHA-1 is not collisions free, but so far the best known theoretical collision attack on SHA-1 took 2 to the power of 51 attempts to perform (that’s a number with 16 digits!), and until now nobody has been able to show an actual successful attempt to do so. SHA-1 produces a 160-bit digest values, and can be computed in PHP like so:

    php > echo sha1("my name is Inigo Montoya");
    b208946a9c3c4b26a4d6bb87c3f630f996146ee

So, I should just store the password hash in the DB?

Well, yes and no.

Yes – because that’s the first step. By storing a SHA-1 hashed version of the password in your DB you ensure nobody can compute the password by simply stealing your users DB table data. When a user types in their password, you compare the stored hash to the SHA-1 hash of the typed in string, and if they match, you grant access. Simple and effective.

But wait… that’s still not good enough.

Stupid but Effective: Dictionary Attacks

All hash functions are vulnerable to a type of attack sometimes referred to as rainbow attacks or dictionary attacks.

These attacks take advantage of the fact that in most cases, humans are humans – and the passwords they use are of limited size (how many people can you think of that use 12 or even 10 character long passwords?) and are composed of a limited set of characters (remember that even power users that use punctuation, numbers and mixed-case characters in their passwords are still confined to the ~75 characters or so on their keyboards).

Dictionary attacks are stupid but effective: the idea is to create a dictionary (basically a big key -> value table) of predictable passwords (dictionary words, expected combinations of key strokes, all permutations of what’s on your keyboard up to 8 characters long) and their MD5 or SHA-1 values. Once such a table exists (creating it may take several hours on commodity hardware, but this is a one-time effort), you can search for an original password using it’s hash value.

A dictionary attack allows me to reverse-engineer the original password from it’s hash value not by smart computation (which, given a good hash function, is impossible or impractical), but through a simple query to a ready-made “dictionary” mapping hash values to original strings.

But it’s even easier than that: nowdays there are services that offer such dictionary lookup in their existing databases. It’s not even required to do the work of building the dictionary.

One good solution to dictionary attacks is forcing your users to mix punctuation, upper and lower-case characters and numbers in their at-least 12 character long passwords. However, we all know that in many cases this means expecting too much from your users.

The practical solution to dictionary attacks is quite simple, and is called salting.

Just Add Salt

Salting is a simple yet effective method to improve the security of stored passwords and prevent dictionary attacks. The idea is that instead of expecting a long, random password from the user, you take whatever password the user provides and add additional random noise (referred to as “salt”) to it yourself. You store that random noise next to the password, and use it to compute the hash when checking passwords.

Once a long enough and random enough salt is added, comparing hash values stored in your DB to a dictionary becomes very hard: an attacker will need to build an entire database of hash values for each different salt + password combination, effectively requiring the creation of a table with hundreds of billions of records to crack a single password.

Make sure a different random salt is added to each password: otherwise a single DB of salted hash values can be created for your application – it won’t be useful for other apps, but if someone wants to target your app they can definitely achieve their goals.

As an example, let’s assume a user who’s password is ‘inigo2001′. Here is how this user’s password will be stored in the DB without salting:

 +-------------------+------------------------------------------+
 | user              | password_hash                            |
 +-------------------+------------------------------------------+
 | inigo@montoya.com | e40900c950cc6011297b2b392b42c29688b33ac7 |
 +-------------------+------------------------------------------+

An attacker with a good dictionary can figure out that the password_hash value is in fact the SHA-1 digest of “inigo2001″. However, if we add salt:

 +-------------------+------------------------------------------+------------------------------+
 | user              | password_hash                            | password_salt                |
 +-------------------+------------------------------------------+------------------------------+
 | inigo@montoya.com | fe66f3eb9c0afc8c935dc9f3f26dbea68d48ccc1 | 9ljYI+xMaVOSloDwt9ahzTpqMHA= |
 +-------------------+------------------------------------------+------------------------------+

Guessing that password_hash is the SHA-1 digest of “indigo20019ljYI+xMaVOSloDwt9ahzTpqMHA=” is quite hard – one would need to build a huge dictionary just to figure out this one password, assuming they also have insight into our code and have figured out that we have concatenated the password_salt value after the original password value and passed that through SHA-1.

Note that the password_salt value in this case is a base-64 encoded string of 20 random bytes – using a random enough and long enough salt is important, otherwise there’s a good chance your password + salt value happens to already exist in the attacker’s DB.

Example Time

To summarize things, here is an actual example of a few PHP functions that store user information in the DB in a secure manner and verify passwords against that stored information.

Our users table in the database is assumed to look something like:

mysql> DESCRIBE users;
+---------------+---------------------+------+-----+---------+----------------+
| Field         | Type                | Null | Key | Default | Extra          |
+---------------+---------------------+------+-----+---------+----------------+
| id            | int(10) unsigned    | NO   | PRI | NULL    | auto_increment |
| email         | varchar(50)         | NO   | UNI | NULL    |                |
| password      | char(40)            | NO   |     | NULL    |                |
| password_salt | binary(16)          | YES  |     | NULL    |                |
+---------------+---------------------+------+-----+---------+----------------+

The password field is a 40 byte long CHAR (SHA-1 hashes in hexadecimal representation are always 40 byte long). The password_salt field is a 16 byte BINARY field – it will contain some random bytes with no particular encoding so it shouldn’t be a CHAR or VARCHAR field.

As new users register, the following functions are used to set the user’s password in the DB:

class User
{
  /**
   * This will contain a hashed version of the user's password
   *
   * @var string
   */
  protected $password = null;

  /**
   * This will contain the salt value used to add noise to the password hash
   *
   * @var string
   */
  protected $password_salt = null;

  /**
   * Set the user's password
   *
   * @param string $password
   */
  public function setPassword($password)
  {
    // Test that password is at least 6 characters mixing letters and digits
    if (! preg_match('/^.*(?=.{6,})(?=.*[a-z])(?=.*[A-Z])(?=.*\d).*$/')) {
        throw new \ErrorException("Password is not strong enough");
    }

    $this->password_salt = $this->generateRandomSalt();
    $this->password = sha1($password . $this->password_salt);
  }

  /**
   * Generate a random salt value, 16 bytes long
   *
   * This relies on OpenSSL being available. If it is not available, any
   * cryptographic-grade random string generation function would work. On
   * UNIX machines, you can just read 16 bytes from /dev/urandom.
   *
   * @return string
   */
  protected function generateRandomSalt()
  {
    return openssl_random_pseudo_bytes(16);
  }
}

To check a given password, we add the following function to the same class (assume that the protected values are populated from values fetched from the DB):

  /**
   * Check if password is correct
   *
   * @param  string $password
   * @return boolean
   */
  public function checkPassword($password)
  {
    $hashed = sha1($password . $this->password_salt);
    return ($hashed === $this->password);
  }

As you can see, this class (assuming a working database access layer) will do the work of properly salting and hashing passwords before saving them, and of comparing given clear-text passwords to a salted, hashed value stored in the DB. This practically ensures stealing passwords from you is near impossible.

What’s next?

I hope that this article pointed out some good practices in storing passwords in the DB. It is important to remember that while your site may not be very interesting to hack into, hacking into your users’ accounts could be a first step towards identity theft or the hijacking of accounts on another site holding much more sensitive data. Implementing the measures described here would mean you are at least treating your users’ password with the right care.

There are additional aspects to password security which you should look into: using proper security on the transport channel when asking for passwords (HTTPS with a valid certificate), requiring strong enough passwords from your users, avoiding session fixation attacks (session_regenerate_id at login) and more. I also did not touch procedures of replacing lost passwords, which are also a common weak point vulnerable for phishing attacks. There is quite a lot of material to read out there on these topics, and if I see an interest is raised I might cover some of them myself in the future.

Go with the Flow: PHP’s Userspace Streams API

Almost every PHP application out there needs to read data from files or write data to files – or things that look like files but are not quite files – these unstructured blobs of data are commonly referred to as “streams”. Stream functions allow a scalable, portable and memory efficient way to handle data, and pretty much any PHP developer out there knows how to read data from or write data to a steam. The best part is that you don’t have to be an extension author in order to provide access to any data source as if it was just a regular file. PHP’s userspace streams API allows you do to exactly that, and this article will show you how.

If you’re a subscriber, feel free to read the article and send me your feedback. If not, go ahead an buy the issue

First, know that I was lucky: for this method to properly work, you need a few things:

• The machine must be EBS based
• You need to be able to afford a couple of minutes of downtime
• You need to be able to withstand the effects of restarting the machine – for example, if you do not have an Elastic IP address associated with the machine, its public address will change. In some situations this is not acceptable.

After trying some different approaches, what worked for me was to do the following:

1. Generate a new keypair for yourself, and import the public key to your EC2 account
2. Start a new, clean, cheap machine (this will only be needed to do very simple things, so I recommend using a tiny machine) in the same availability zone as the affected machine
3. Stop the affected machine (do not terminate, STOP it – this is only possible with EBS machines)
4. Detach the root device from the affected machine (by default attached as /dev/sda1)
5. Attach the detached device to the new clean machine
6. SSH into the clean machine and mount the affected machine’s root filesystem somewhere (e.g. in /mnt/fs)
7. Now you can edit /mnt/fs/root/.ssh/authorized_keys (or on official Ubuntu machines /home/ubuntu/.ssh/authorized_keys) and add your new public key to it
8. Unmount the volume and terminate the clean machine – you no longer need it
9. Re-attach the root device to the affected machine (which should be stopped) – ensure to attach it as the same device it was before (e.g. /dev/sda1)
10. Re-start your old machine – you should now be able to use your new key!

Another approach which could work but I gave up on after a couple of attempts (I think it really depends on the init scripts in the machine you are using), is to stop the machine and change the User Data of it to a shell script that sets a new public key in the right place, then start it again.

And really, you should backup your keys!

This is a rant against the too-common term “NoSQL”. In my opinion, “NoSQL” is an example of layman terminology which does not properly describe the concepts which in most cases it aims to describe, and should not be used by professionals which are technical enough to understand the true meaning of these concepts.

“NoSQL” databases are all about the data model – in most cases, the term is used to describe any kind of storage engine (or database) in which data is stored in non-relational manner: object storage, document storage, key-value storage etc. Indeed, the term is more about what the database is not that about what it is.

Relational data is data that can be described as a table – in contrast to what some think, the term “relational database” has nothing to do with the ability to define and enforce relationships between data in different tables. If this was the case, MySQL using the MyISAM storage engine would not be a relational database. The term “relation” is a mathematical term, which existed before the creation of relational databases and is used to describe a relationship between two finite data sets, which can be described in a tabular manner (and I am not a mathematician, not even close – so I apologize in advance for this likely inaccurate description).

But, SQL has nothing to do with this – SQL is the language used to send commands to the database, and nothing more. It is true that there is an almost 1-to-1 correlation between database engines that store data in a relational manner and database engines that use SQL as a query language, but saying that relational databases are SQL databases is like saying that  (and assume it’s 1984 again) the Russian language should be abolished when in fact we want to say that communism is an unfitting economic system. It’s a poor way to describe your intentions, and it makes you sound like an ignorant moron.

There are many client libraries and wrappers that allow you to query a relational database such as MySQL and Oracle without writing any SQL code yourself. This doesn’t make them NoSQL databases. Some popular non-relational databases, such as Amazon SimpleDB and the Google App Engine Data Store provide query languages that are quite similar to SQL. This doesn’t make them SQL databases.SQL is just a language, and it is a good one for what it’s supposed to do (putting aside all sorts of discrepancies between vendor-specific SQL implementations). SQL is not what NoSQL databases are NOT about.

So, next time when you want to use a term that describes all databases that do not store data in a tabular manner, use the term “non-relational” or if you really like acronyms, “NonRDBMS”, and not “NoSQL”. Or even better – use a term that describes what your preferred solution is, not what it is not. After all, when you say “non-relational storage engine”, you are probably not referring to your file system, right?

All in all I like Bitbucket (although I have to admit on most aspects they seem to fall behind GitHub), but not so much using Mercurial – for all sorts of reasons it felt quirky and less polished than Git, which honestly I have much more experience with.

So following Bitbucket’s big announcement on Git support, I’ve decided to migrate my repositories from Hg to Git, while keeping them on Bitbucket and maintaining repository history. I’m happy to say it was relatively a piece of cake to successfully achieve. Here is what I did:

Step 1: Set up your repositories

First, I renamed my old Hg repository through Mercurial’s web interface, to something like “MyProject” to “MyProject Hg”. This changes the repository URL, but since I wasn’t planning on using it anymore that doesn’t really matters – plus you can always rename back if things go bad.

Then, I created a new Git repository with the name of the previous repository, e.g. “MyProject”. Again, that can be easily done from Bitbucket’s Web interface.

Step 2: Install the Mercurial hggit plugin

The hggit plugin allows your Mercurial command line tool hg to talk to git repositories – that is push and pull from Git. Installing it is easy, as it is probably available from your package manager. On Mac, if you use Macports, you can run:

  $ sudo port install py26-hggit

While on Ubuntu, run:

  $ sudo aptitude install mercurial-git

Then, make sure to load the plugin by adding the following lines to your ~/.hgrc file:

  [extensions]
  hggit=

Congratulations: Your hg command now speaks Git!

Step 3: Push your code into your Git repository

To push your code into your new Git repository, you basically need to run two commands:

First, create a Mercurial bookmark that references master to your default branch. This will help Git create the right refs later on:

  $ cd ~/myproject-hg-repo/
  $ hg bookmark -r default master

Next, simply push your code into the newly created Git repository:

  $ hg push git+ssh://git@bitbucket.org:shaharevron/myproject.git

Of course, make sure to change the repository URL to the URL of your new Git repository. To make sure hg understands you’re referring to a Git repository, if using SSH add the git+ssh:// prefix to the URL. This should push your entire repository to the new Git repository, and within a few seconds up to a few minutes (depending on how big your repository is), you should be able to see all your old commits in the new Git repo.

Step 4: Switch your local repository to use Git

Now that your new Git repo is up at Bitbucket, you’ll need to switch to using Git locally. There are two paths you can take here: the safe one, is to simply git clone your code to a new working directory and work from there. It’s safe, and will work well. However, if you’re a cowboy like me, and are too lazy to create a new IDE project on a different directory, you can in fact simply switch to working with Git on the same directory (but I still seriously recommend you ensure Bitbucket really does have your code as backup…).

Here is how to do it. From the local repository directory, run:

  $ git init
  $ git remote add origin git@bitbucket.org:shaharevron/myproject.git
  $ git pull origin master
  $ git reset --hard HEAD

Again, replace the repository URL with your own. This will “merge” everything in your Git repo into the local working directory. You will need to create a new .gitignore file if needed – and can now simply delete the .hg directory, as it is no longer needed. You can now happily use Git with your Bitbucket code.

While there shouldn’t be any problems, I also recommend keeping your old Hg repository around on Bitbucket for a few days, just to make sure nothing blows up – and delete it from Bitbucket’s web interface once you’re sure everything works well.

This was not an easy decision for me, as Zend has been for more than 6 years not only my employer but also my school, my workshop and a little bit of home as well. This sounds like bullshit – but since I started there as a first-level support engineer and am leaving as a co-Product Manager for the company’s flagship product, I think it’s fair to say I gained as much as I contributed.

However, it’s time to move on for me. I’m looking into doing my own things at my own time, and being my own boss. I want more free time to experiment, play and pursue my hobbies and silly ideas.

In recent years the company took some directions I was not 100% happy with, and being responsible for realizing some of these ideas, it was hard for me to stay at my role. I started thinking what I want to do next – and was offered a couple of very tempting roles within Zend – but then I realized that really, I want to make a bigger change.

And here I am.

For the last couple of months I have reduced my role at Zend to a 2-day consulting position, and will continue to consult Zend on a part-time basis for at least a few weeks.In the rest of my time, I plan to think, read, paddle, rest, blog more and work on some ideas I have. I plan to keep contributing to the PHP community, and specifically to Zend Framework 2.0.

Will I chicken out in 3 months and decide to get a real job again? Maybe… but I plan to make the most of my time until then.

Once I’ll make sure everything works well in the new home, I’ll post some news – so stay tuned!

As a little test, I’ve implemented a little Game of Life thing using HTML 5 Canvas, which you can see in action here: http://arr.gr/playground/life/ (view source to see the code behind it).

The algorithm is not very smart so it’s kind of slow and CPU intensive, but still fun to watch. It works nicely on Firefox 4.0, and latest Chrome and Safari versions, and a bit slow on Firefox 3.6. I did not test with any IE version but I do not expect it to work in IE 6 or 7, maybe 8 and probably 9.

I think Game of Life by itself is worth at least an entire post regardless of this HTML5 implementation, especially because I’m a big fan of things that bring CS and philosophy together, so I may write about it at a later point, but for now I suggest you let it run for a while (a few hundreds of generations) and see what you get

Presentation was pretty good, although I had to hurry up in the end and skip some of the last slides.

The slides are now up in Slideshare, and can be downloaded or viewed on-line.