So what’s the solution? We will use a ‘hash’ to store password validation. Without getting scientific a hash is the result of a transformation applied to the password string. This transformation is very likely one of the better known cryptographic methods such as MD5 or SHA1.

Let’s see it in practical terms. The user provides a password of  ”abc123″ , once hashed with SHA1 it looks like 6367c48dd193d56ea7b0baad25b19455e529f5ee. A hexadecimal number 40 characters in length. The process of hashing is one way only, so it’s not possible (for regular folks) to guess the password by looking at the hash. Next time the user logs in, the system will hash the password entered and compare it to the stored hash to validate the credentials.

So far so good, except that “abc123″ is a fairly easily guessable password, and it would probably be included in a dictionary based attack using rainbow tables. A rainbow table is a lookup table containing hashes based on a dictionary of possible passwords; “password”, “Password”, “root”, etc. would be the kind of passwords that you might find in said tables, and of course “abc123″ would make the list as well. So, in this case even though it’s harder to do, it’s still possible to reveal the actual password from the hash. As usual, using had-to-guess passwords mitigates this risk.

The solution to this issue is to use a ‘salt’ which is a random value attached to the password. By appending the salt, the rainbow table becomes useless, as the number of possible combinations makes it nearly impossible to guess using this method.

Photo by PhyrePh0X

Let’s tie all the pieces. The user signs up and picks a password, we take the password salt it with a random value, hash it, then store the hash and the salt. In PHP it might look somewhat like this:

$password = 'password';

$salt = sha1(rand()); //According to PHP.net some systems such as Windows will use a max number of 32768 unless explicitly specified

$hash = sha1($salt.$password); //Hash the concatenated string of the password and the hashed random salt

//Store values

See the output of this example

Going back to the original example, you wouldn’t be a able to e-mail the exact password back to the forgetful user at this point, instead, send him a link to a password reset page where they can enter a new one, and you can store it in the form of a new hash.

As usual this is only a little something to get you started and not an in-depth production ready sample. Use common sense when dealing with security and user experience issues. It’s possible that you work in an industry that has certain requirements regarding storing passwords and such, make sure you always check what’s appropriate for the particular project you are working on.

Do you use any of these methods in your projects? What else do you do to ensure security and a good user experience?

Bookmark It

Hide Sites

Today I received an e-mail from the Google Apps team that said the following:

Dear Google Apps admin,

In order to continue to improve our products and deliver more sophisticated features and performance, we are harnessing some of the latest improvements in web browser technology. This includes faster JavaScript processing and new standards like HTML5.  As a result, over the course of 2010, we will be phasing out support for Microsoft Internet Explorer 6.0 ​as well as other older browsers that are not supported by their own manufacturers…

So far so good, but here’s the real kicker

…Later in 2010, we will start to phase out support for these browsers for Google Mail and Google Calendar.

This is major. And it is so because of the massive amount of people that use these services could create the critical mass that will finally drop IE6 market share to an insignificant level.

If you’ve ever developed for the web you’ll know that everything is peachy until you test your site on IE6. Then you realize that you have to make a lot of modifications, tweaks and other superfluous work just to deliver anything that will look half way decent in this browser.

Web developers have been expecting this browser to die for ages. We’ve been hoping for the big players to drop support which it’s expected will force people and organizations to finally upgrade to a newer version or a different browser altogether.

There is also the added -and likely more important- benefit of ridding the Internet of the security risks associated with IE6. For some strange reason this hasn’t been as strong a motivation as one would expect for IT departments and end users to get on with the program. Let’s hope they find this move by Google compelling enough to do so.

Congratulations Google on doing something that should’ve been done years ago.

Bookmark It

Hide Sites