A Little About Passwords

You often hear about how one organization or another has had their database compromised, they publicly apologize to everyone, and suggest that everyone changes their passwords to all sites that may have used the same password as theirs.  When this happens, it always makes me wonder how securely they held my password, which I consider sensitive information.  The general public, especially the non-technical portion of computer users lack education about passwords, and what makes them secure.  I hope to help remedy some of that in this blog.

First, let’s see what makes a good password.  As you can see from this Educational Institution’s Password FAQ, they suggest using special characters and numbers mixed in with letters – and then try cramming that in to 8 characters to use for your password.  Go ahead, read on about.com for how to choose a good password. Or, you can read on Microsoft’s How-To for strong passwords.  The common theme among all of these is to take a phrase that you can remember, and then use the first letter of each word while adding some numbers in there to mix things up.  Did you know, a modern computer can brute-force a 10 character password rather quickly?  There are commercial applications which can test up to 2.6 billion passwords a second.  With that type of computing power, cracking a 10 digit password can be done in one day.  How secure are those first letter phrases now?  The answer is: not very.

Password policies came around the same time as computers and information systems that required you to.. log in.  Most of these password policies (and how passwords are stored) have not changed much since then.  Most recommend around 6-10 characters, mixing cases, adding symbols, etc.  Most software that accepts passwords are not any better at helping protect you, as they like to follow the same guidelines, and then put an upper maximum on the number of characters your password can have.  Why on earth limit a user to so few characters?  I encourage you to look at your bank’s website, and then look at their password policies.  For example, we have Wells Fargo, which tells you your password has to be between 8 and 12 characters.  Go ahead, read the policy.  Now think about this, if it takes one day to crack a 10 character password, how much longer when the maximum length of your password is 12 characters?

So, what really makes a good password?  Length.  And then more length.  Sure, it helps if you can remember a slightly obfuscated version of it as well, add some symbols or punctuation to it here and there.  But primarily, start with a sentence, “I love my black, dog, skip!”.  That is a 27 character long password, and it will take years to crack. (maybe not now, since it’s used as an example in a password blog, however, you get the point.)  The problem with it, is that most places that have passwords won’t let you use something quite that long.  Websites and applications really, really, need to catch up with computing power in their policies.  Let passwords thrive!

Now, for the programmers, have you ever registered for a website and in their introduction email, they send you your password?!  What. The. Hell.  That has happened a few times to me, or I find out the hard way when I forget my password and click the link, and then they send me my original password.  Those are sites that I immediately delete my account on.  If the purpose of a password is to authenticate a user, that password should not even be available to the website owner/programmer/etc.  That password should forever be hidden.  Most programmer’s do think of this consideration (which, when I come across a site that can email me my password, is why it absolutely baffles me as to why they are so stupid.)  Ask a PHP programmer for advice on how to create an authentication scheme.  A vast majority will have kept up well enough to tell you that “don’t use md5 to hash it, use SHA”.  Which, okay, might be a start.  However, these hashing algorithms are meant to be fast.  They are meant to be used with encryption schemes, and so they need to be fast so they don’t slow down the encryption of a large file.  They are also useful for verifying that data is correct.  Give it a large file, and it will give you a semi-unique string of 32 characters to verify the data with.

So, what is a programmer to do?  You need to create a log in for your site, you want your users to be safe when using your site, and you want to avoid attacks via a Rainbow Table.  To avoid rainbow tables, the simple solution is adding salt to the password before hashing it.  The next thing you need to take in to consideration is computational speed.  The slower an algorithm is at generating a hash the better.  So, how do you use these hashes to store a password in your database, in a way that it can be re-created and get the same exact result?  Well, for that, we get to look at stretching the hash.  We do the hash multiple (thousands) of times, and then store that result.  We also want salt that is unique to each user – that way if two users have the same password, they don’t look the same when stored, so cracking one password won’t mean cracking both.

Here is how to generate a ‘secure’ hash of a password in PHP.  The reason it is ‘secure’ is due to its slow speed at generating a hash, it also uses a static salt, and a salt that is unique to each password.  To get a salt that is unique to each user, I personally use something like the registration time of the user on the website as the dynamic salt, and then all my websites have a salt that is unique to each of them – so even if a user is on both with the same password, it will never look like it according to the hashes.  Here’s a look at a function that makes this happen.

The $pepper  variable is what is unique to each user.  This function will take about ~1-2 seconds to generate a hash, and it is suppose to take that long.  The different variations of combing the previous hash, salt, and pepper add to the complexity of generating the hash, though, knowing how it combines them, and when, makes it less effective to adding to the complexity, though, changing it a little for each application will help serve to further obfuscate the password.  Because it takes so long to generate the hash for one password, even if the salt and pepper are known to the attacker, it takes down the number of attempts from 2.6 billion per second, to 1 every two seconds.  It becomes impractical to even attempt compromising a user’s password, as the same 10 digit password would now takes 5.2 billion times longer to brute-force.

No Comments Yet

There are no comments yet. You could be the first!

Leave a Comment

    Search the Blog