If the second query is used, then the passwords are immediately available to anyone who gets his hands on a copy of the database, no cracking required. If the first query is operating, and the user employs a strong password like "g7#$gg567" with SHA1 hashing, very likely no one will crack it because it would take far too long to be worthwhile.
MySQL (and other databases) include built-in hashing functions for purposes just like this. The impact on application performance is vanishingly small. The time required to implement simple hashing over plain-text storage is measured in a few minutes in total -- enough time to add the SHA1 function call to the password storage and matching query. That's it.
If you want greater protection, add several layers of SHA1 and maybe MD5 hashing to the password. It might look like this:
Adding multiple layers of hashing won't make it 100 percent secure, but it's a very, very simple way to provide a significant level of protection to sensitive information like passwords, and it carries nearly no performance penalty. Tack on a fixed salt (a string that's not found in the database) or a simple substr (or both!) to the password and you add an even greater level of protection -- with nearly no time investment to speak of.
On an extremely small-spec Linux VM (one vCPU, 512MB of RAM), I wrote a tiny bit of PHP to create 500 randomized usernames and passwords, 4 to 8 characters for usernames, 6 to 12 characters for passwords. I then inserted them into the local MySQL database with and without varying levels of hashing. The result was that it took 0.019 second longer to store 500
SHA1(MD5(SHA1)) strings than it did to store the same data in plain text. That's well within any reasonable margin of error, and it's completely unnoticeable.
These are just minor examples of exactly how simple it is to use built-in database hashing functions to allow for the storage of hashed passwords instead of plain text. This is about as simple as it gets -- yet we continue to see large-scale apps that simply don't use hashing or any form of password security.
Nonetheless, I'm still getting hammered about the position I've taken: that those writing code exposing plain-text passwords (or any of a number of equally egregious coding practices) should be held responsible when their awful practices enable user data to be easily stolen and turned against those users.
Maybe I just don't get it. Maybe you'll log on to Twitter on Thursday and tell me exactly why I'm wrong.
I'm all ears.
This story, "The fuss over accountability for bad code," was originally published at InfoWorld.com. Read more of Paul Venezia's The Deep End blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.