Archive for February, 2012

I got to thinking about passwords last night because I couldn’t sleep and I wanted to clarify something. Many people have asked me, “If you use numbers and special characters add to the “hardness” of a password?”

Initially I say “No, but it adds to the key space” (key space is the total number of possibilities that an attacker must try). What I actually mean to say is “Yes, it does increase the “hardness” of the password (and increases the key space), but it is not strictly necessary to use.”

One of the tips I like to use is to create a password that is composed of several words that you like or are particularly memorable. For example, you could probably look around your office or home and do this. Looking around me, I could choose projectorchocolateglobemarker (you could choose something else that is easier to remember and I probably would too, but this is just an example).

Consider this: if a password was composed of lower case, upper case, numbers and special characters, that would be 72 characters to chose from. If your mean system administrator said that your password had to be composed of 8 characters combining those 4 types of characters, then the total number of combinations would be ~7.22 x 10^14 (assuming a password length of 8 characters). That’s a lot of possible combinations a cracker/hacker must try!

Now consider the password where I ran the words together (projectorchocolateglobemarker). This would be resistant to a dictionary attack. A dictionary attack uses a targeted technique of successively trying all the words in an exhaustive list called a dictionary (from a pre-arranged list of values). Commonly, these pre-arranged lists are actually words from a dictionary because people are lazy and they will make their password is easy to remember (not through any fault of their own but humans are notoriously bad at remembering things that doesn’t make sense or they have no connection to). While those individual words (projector, chocolate, globe and marker) would all be in the dictionary, the concatenation of them would not. While we have fewer total characters to choose from (26 lower case characters), the total number possible combinations for the password would be orders of magnitude larger. In fact, it would be ~1.052 x 10^41. That is a much larger key space!

Now, if you haven’t glossed over by now, consider a computer that could do 1 key attempt per microsecond (which is certainly not out of the realm of possibilities), that is about 1 million key attempts (to crack) per second. The first password would take 722M seconds (22 years), the second would take ~10^27 years. Clearly, we can see which is more secure (and I didn’t need a lot of characters to do it). These longer, harder passwords, are also more immune to what we call “rainbow table” attacks.

A lot of the password stuff is what is called “security theater.” Security theater is a term that describes security countermeasures intended to provide the feeling of improved security while doing little or nothing to actually improve security. Having a system administrator create policies that don’t make sense (such as the crazy combinations of letters, numbers, special chars) when the password is far less secure is an example of security theater. Bruce Schneier uses it a lot to describe TSA security.

Another way to create a memorable password is to think of a memorable phrase such as “my sister likes to eat juicy orange every day”. Then, take the first letter of each word and combine them to make your password. In this example, your password would be msltejoed.

Lastly, I wanted to mention one last tip. If a user could setup a policy that would lock out after a certain number of failed attempts, such as 3, this is the most secure way to do a pass-worded system because it wouldn’t allow an attacker to do a “brute force” attack where they try all the different types of keys.

I recently had a need to build a licensing module in Java for a project I was working on. All of the modules out there cost money, so I figured that I would release a free one. What is neat about this is that it is pretty simple easy and fast to implement and it comes with a license key generator. The best part is that it relies on PKI, so unless someone were able to patch the binary to skip the authentication check, they would have to be able to break a 2048bit RSA key (which is pretty safe considering no one has broken a 1024bit RSA key).

This particular licensing module has support for multiple license types: Trial, Single Version and Lifetime. Also, the license has support for information such as name, email, license number, license type, expiration date and version number. There is support for blacklisted, invalid, phony, and expired keys. The one thing I want to mention before we get into the code is that you’ll need a public and private keypair (you can use OpenSSL to do this) in .der format (an X509 certificate using OpenSSL again). So without further ado…