Storing Passwords in Databases

In the last few weeks/months there have been a couple high-profile computer breaches in the news. One was at Plenty of Fish, an online dating website. The second was at HBGary, a computer security company (ah, the irony).

Plenty of Fish made a major security mistake. They stored passwords in their database in plain text. This means, if you had access to their database (legitimately or through a SQL injection vulnerability) you could see anyone's password. And this is typically a big security no, no. Passwords should always be hashed before being stored in a database.

Hashing is a one-way encryption that prevents a password (or any character string) from being un-encrypted. So, when a user logs in, you hash their entered password and compare it against the hashed password in the database. If they match, the password is the same. It is simple AND safe.

Two particular hashes are quite popular. SHA1 and MD5. Although they are beginning to be a bit dated now and, if I remember correctly, MD5 has been shown to have some vulnerabilities. Some of the more recent hashes are SHA256 and SHA512. (Use the hash function to implement them in PHP.)

Over at HBGary, the "security" firm, they actually did use hashes to store passwords. They used the common MD5 hashing algorithm. The problem with their implementation, is that they added nothing to the password before hashing it. This is an issue because people have created massive online collections of auto-generated hashes from between 1 and 12 characters (typically). So, if you have a hash, and you're a hacker, you look up the hash in this table and (if it is a normal-sized password) it will likely be found.

The best way to make this look-up table irrelevant is to add a set of constant, known characters to the password before the hashing takes place. This technique, called adding "salt" to the password, will create an extra long password, that will never show up in a look-up table. Why? Because it would take more than a lifetime to compute look-up tables that long. Hashing is an expensive operation, in terms of CPU cycles, and the longer the original text, the longer it takes to compute.

If you are building a website, and you have passwords to store, remember: salt & hash. Mmmm, sounds tasty!

Hash Changing, detecting the Back button in JavaScript

If you use gmail and you are a web developer, you have probably noticed that they use hash or anchor links (e.g., "example.html#hash") to make your browser's back button very effective. These hash or anchor links were designed to bring your browser to a certain position in a page. Often they are used on help pages or FAQ pages to make the browser window scroll to a certain point. But, interestingly, they can also be used to set certain JavaScript states, when configured properly.

In order to monitor the hash state and determine if the browser's back or forward button were hence used, you must set up a polling loop. It will check the current hash against the last hash. If there is a change it will do something magical (whatever you want to do).

<script type="text/javascript">
/* set defaults */
var curHash = window.location.hash;

/* check for a change in hash (back or forward buttons) */
setInterval(function() {
 if (curHash != window.location.hash) {
  curHash = window.location.hash;
  /* -- do what you need to do when the hash changes! -- */
 }
}, 250);
</script>

The check time is set to 250 ms. But this can be tweaked for your particular needs.

There is rumors that in HTML 5 there will be a hash onchange event. This will really clean up the code, removing the need for polling. Until then, this is the next best thing.

Update 10/28/13 - Side Note: Checkout HTML5's push state for doing cool things like this w/o the hash. You can have the whole URL reflect a change in the DOM without the browser trying to go out and fetch a new web page. Pretty cool stuff. Some JavaScript frameworks like Backbone support both the hash change and the newer push state methods.