Image via CrunchBase

Part of my job involves reading through a lot of documentation, especially if it is security related. I don’t usually come across many mistakes or gaffes, but when I do, 99% of the time they were written by someone at IBM. The following quotes are all taken from IBM’s AIX V6 Advanced Security Features [PDF] redbook.

AES, as standardized by NIST, is not exactly in the form the Rijndael was originally submitted. It has a fixed block size of 128 bits, and has key sizes of 128, 192, and 512 bits.

Whilst a 512 bit key size for AES might be more secure, the standard doesn’t support it. The key sizes are actually 128, 192, and 256 bits. This is a simple mistake to make, so it is more forgivable than the others.

SHA256 is the Secured Hash Algorithm with a 256-bit key.

I’m not sure what the author of this statement was thinking of when writing it. The ’256′ in SHA256 corresponds to the length of the output the hash generates (256 bits). It is possible that the author was confusing a cryptographic hash function like SHA256 with an HMAC, which does involve a key. However, even then the key size is not dictated by the hash function used in the HMAC. Indeed, any length of key can be used, the longer the better. Additionally, the ‘S’ in SHA stands for “Secure” not “Secured”, but that is just a small nitpick.

Typically the owner of the private key encrypts data with their private key, and the receiver or reader of the data decrypts with the public key.

This explanation of how public key cryptography works is completely backwards, quite literally. The public key can safely be known by anyone (hence the name), so it makes no sense to use it to decrypt data. The proper way to use public key cryptography is to encrypt using the public key, and decrypt using the private key. This means that anyone can send encrypted data, but only the private key owner can decrypt it. The other way around, there is practically no security gained by encrypting the data; you are no better off than sending it in plaintext.

The resulting ciphertext was, and still is, impossible to crack with a brute force attack.

This was found in a section discussing Triple DES, which whilst being far stronger than regular DES, is not “impossible” to crack with a brute-force attack. In fact, nothing is impossible to crack with a brute-force attack (apart from properly implemented one time pads), since brute-force attacks generate and test every possible key. Such an attack on Triple DES is unfeasible, since generating the keys and running the attack takes a very long time with current hardware.

If you haven’t already subscribed to the WhiteHat Security Blog then you should. They produce a nice amount of articles that are easy to understand, and often provide interesting insights into the security industry. However, with such a wide range of topics, mistakes can be made (or concepts overlooked), and it is one particular error that I wanted to discuss in a bit more detail here.

Founder and CTO of WhiteHat Security, Jeremiah Grossman, wrote an article about how to keep yourself safe online, and whilst 99% of the article is accurate and good advice, there is one section on making passwords hard to guess where I think Grossman has entirely the wrong idea:

Pick passwords that are hard to guess, not found in the dictionary, six characters or more in length, and sprinkle in a number or special character for good measure. Something like: y77Vj6t or JX0r21b

Whilst having a password that is not found in the dictionary is sound advice, I disagree with both the minimum length suggested, and Grossman’s apparent meaning of “hard to guess”. From the examples given, and the suggested requirements for passwords, it seems that Grossman is trying to protect against a scenario where a malicious user performs a dictionary attack against some kind of login form for a specific user account.

This type of attack does not require the attacker to know any prior information about the target’s password, but instead simply tries various common passwords hoping for a match. The problem is, this type of attack is one of the least common, usually because it targets only one account at a time, and can be easily thwarted by a system simply by detecting multiple bad login attempts and locking the user account for a certain period of time.¹

Password Attacks 101

If you really want to get a user’s password (or multiple users’ passwords), your best bet is to either sniff the network, exploit any trust the target user might have in you (or someone you know), compromise the user’s own system with malware that records their keystrokes, or breach the password database and crack the hashes (assuming the target system uses hashes). Out of these four attacks, by far the most common (and most well publicised) is cracking a list of stolen hashes.

The advantage of cracking such a list is that all the actual effort can be done on the attacker’s system, where there are no defences that can stall or thwart the attempt(s). Cracking a hash can be achieved either by employing the same dictionary attack I described above, or by a method known as brute-forcing. Whilst dictionary attacks are not always guaranteed to work, brute-force attacks are. This is because instead of relying on a pre-generated list of passwords, the brute-force attack goes further, actively generating all possible passwords and checking them against the given hash(es).

Since a lot of people are still terrible at choosing secure passwords,² it is probably best to employ both these types of attack; first using a dictionary to weed out the weak choices, and then brute-forcing the rest.

Password Haystacks

So how long would it take on average to crack the passwords suggested by Grossman? Well, according to Steve Gibson‘s search space calculator, around 35.79 seconds on a decent offline cracking machine. Depending on the algorithm being used, that time could be longer or shorter, but the point is, it’s not very long at all. This is where I disagree with Grossman’s meaning of “hard to guess”. For a human, a password like “y77Vj6t” would indeed be hard to guess, but for a computer, it is simple. There are only 7 characters involved, and each character can be 1 of a very small number of characters (62 since we are only using letters and numbers). That means that in a worst case scenario, the attacker has to generate and check 3,579,345,993,194 (roughly 3.5 trillion) possible passwords. That may sound like a lot, but hardware today can do literally billions of operations a second, resulting in the 35 second average.

Of course, not all attackers will have access to such hardware, but all that means is that the time required to crack a hash is a little longer, and as I explained before, time is not a major concern when the hashes are already stolen. To really create a password that is hard to guess (by humans and computers), you need to increase the amount of search space that a brute-forcing algorithm has to use. Steve Gibson uses the analogy of looking for a needle in a haystack: given enough time, you will find the needle, but the bigger the haystack, the less chance you will have of succeeding in your search within a certain time-frame. So it is with brute-force attacks. The more types of characters you use in your password, and the longer it is, the less chance that a brute-force attempt will find it in a reasonable period of time.

 Creating a Strong Password

There are many different opinions on what strong passwords should look like, and there is obviously a lot of disagreement over various different “methods” for creating them. For some the issue is one of security vs. memorability, and there is a general belief that any password that is secure enough not to be brute-forced cannot be remembered easily either. I think this is patently and demonstrably false, and I shall share with you my method of creating extremely strong and easy to remember passwords. Firstly, let me define a new set of requirements that all strong passwords should comply with:

1. At least one of every type of character (lowercase and uppercase letters, numbers, and symbols).
2. At least 12 characters in length.
3. It should not be found in any dictionary.
4. It should be unique. In other words, it should be something that nobody (not even yourself) has used before.
5. It should not be based on nor contain any personal details.

If you think those requirements would result in passwords like “Aj18!d#B6]0W”, then you have been taught to think about passwords in entirely the wrong way. Allow me to correct your thinking, with the following easy to remember and highly secure password:

I’m bathing in 34 fish, crikey!

This password (more accurately, a passphrase) has 1 uppercase letter, 20 lowercase letters, 2 numbers, and 8 symbols (counting spaces as such). It is 31 characters long, and although the individual words of the passphrase are found in dictionaries, the entire password is not. Finally, since it is a nonsense sentence, the chances of someone else having used it in the past are very slim indeed, and it does not contain any personal details. According to Steve Gibson’s search space calculator, a brute-force attempt that makes one hundred trillion guesses per second would take 65.53 trillion trillion trillion centuries to crack this passphrase.

The Science Bit

So this type of passphrase is very strong, and I hold that it is also very memorable, because it relies on the same techniques for improving memorability as mnemonics do. Remembering the 5 musical notes represented by the lines on a treble clef stave (EGBDF) is hard for most people, but almost everyone who has studied music will remember the helpful mnemonic “Every Good Boy Deserves Favour”. Science suggests that mnemonics are effective,³ and further research concluded that we remember humourous sentences better than non-humourous ones.⁴ Thus, in my opinion, a humourous nonsensical sentence is ideal as a secure and memorable passphrase.

I have proposed this before in various discussion groups, and the feedback has more often than not been positive. However, I am of course open to criticisms, and I shall go into more detail about possible objections to this method in a separate article. The real test would be for people to start using these sorts of passphrases in their daily lives and report back their findings. Were they easy to remember? How long did you make them on average? How many did you manage to recall before you started running into trouble? Any feedback will be interesting to hear.

My own prediction is that even hours after you have finished reading this article, you will still be able to remember the passphrase I generated a few paragraphs ago.

Update (30/3/2012): Added a 5th requirement for strong passwords, concerning the inclusion of personal details.

Karsten Nohl and Sylvain Munaut from Security Research Labs have cracked GSM, enabling them to eavesdrop on any call made by a target device. The pair demonstrated their research at the Chaos Computer Club Congress (CCC), and have released a rough guide to the attack on their website.

What appears to be unique to this type of attack on GSM is that an attacker can specify an actual target device to eavesdrop on. Using a set of cheap Motorola phones with open-source firmware, the researchers were able to see all data being broadcast by the GSM base station. Once a target device is located, the relevant data can be unencrypted by finding the GSM encryption key using a set of rainbow tables. The set of tables used by the researchers was generated over a two month period in a previous research project, and is 2TB in size. An attacker only needs two encrypted known plaintext messages to have a 90% chance of finding the secret key.

In Nohl’s own words, “Now there’s a path from your telephone number to me finding you and listening to your calls, the whole way.”

Let’s just hope the GSM Association (GSMA) take on board the research, and pay special attention to the relative easiness and low cost of actually executing the attack. According to the BBC News write-up, the association have yet to comment on the attack.