Encrypted versus hashed passwords

I’m trying to decide whether it is better to store passwords in a database as key-encrypted strings, or as the result of a hash function (with salt).

Padlock

An encrypted string is secure as long as the key is secure, which it seems to me is both its strength and its Achilles’ heel. Since the application that accesses the database needs to use the key, that means that if both the database and the application server are compromised, the data is compromised.

It also means that if the application developers have access to the database, or if the DBAs have access to the application code, the data is available to those individuals. Even though those users are most likely trustworthy, it is perhaps an unnecessary risk–not to mention their workstations may be compromised. On top of that, you need to worry about key escrow–if you lose the key, you no longer have access to your own data.

A hashed value is secure even if the database and the application are compromised, as it is the result of a one-way function. The value is also inaccessible to either the application developers or the DBAs, which provides an additional layer of security. On the other hand, since it uses a well-known hash function, such as MD5, creating a dictionary file of hashed values is trivial, and apparently an even more effective method to reveal hashed data is to use a rainbow table (the description of which goes a bit over my head right now).

That’s where the salt comes in: concatenate the original value along with extra data before creating the hash. I can see how this would foil a simple dictionary of hashed values. From what I’ve read, the salt value can be unique for each hashed value, and can be stored alongside the hashed value in the database. I’m not sure I entirely understand how that defends against rainbow tables, but it sounds good to me.

Using a hashed value, you can’t retrieve the original data–you can only match against it. This would not work well for data that you need to access again in its original form, e.g. phone numbers. This is a drawback in some cases, but probably not for passwords.

Right now I’m leaning towards salted hash over encryption, but maybe that’s because I’m hungry and it sounds more like breakfast. I’d love to know what other people think.

One of my projects is about to be licenced

A web development company that I have worked with before has decided that they are interested in licensing a web-framework that I have developed. They are probably going to go forward and use it on a _lot_ of projects (well that’s certainly what I hope) and I will get a small cut each time they deploy it. I’m really super excited about seeing my code deployed this way, as well as by the prospect of passive income.

I also feel as if recently my code has taken a big step forward in quality. I’m not sure exactly what did it, but I suspect that it was either trying to write a good written word piece for the first time, or starting to do daily meditation. Either way my code quality has gone up in a visible and measurable way. I feel good about this because I just did another pass through the code base and feel like it’s getting much closer to something that could be licensed with real value.

jQuery is AWESOME

I just took (and finished) a small project to add some ajax and javascript whiz-bang to a website. (actually it was the home page for a web development company you would think that they would keep that in house) and I decided to try out jQuery.

It blew my socks off. I’m really really impressed with jQuery, and I’m looking forward to using it a lot more. It took me an hour or two to really get a handle on how a few parts of it work, but man is it a powerhouse. If your website needs to sing and dance…. jQuery is the way!