I recently read the Ars Technical Article about new features in ocl-Hashcat-plus. In light of questions like:
Long Passwords: How are they more secure?
and
XKCD #936: Short complex password, or long dictionary passphrase?
Are pass "phrases" like "correct horse battery staple" guessed by the new features in ocl-Hashcat-plus? Does it help to capitalize a letter and add a punctuation mark ("Correct horse battery staple.")?
[Disclosure: I work for AgileBits, the makers of 1Password.]
To give credit where credit is due (comics rarely have citation footnotes), this scheme is called "Diceware" and should be credited to Arnold Reinhold, who described it in 1995.
What is absolutely crucial to the scheme is that words must be chosen from the list by a uniform random process. (Reinhold's scheme involved rolling dice.) Humans, particularly when trying to be clever in selecting passwords, are very much not random.
hashcat, as it stands today, isn't good at applying transformations (e.g., case changes) to guesses that are done by combining words (needed for Diceware=like systems). So in once sense, using a few symbols and mixed case for these sorts of password will really make things hard for hashcat. However, that would be a stupid reason to do something like that. After all, a week ago, just using a passphrase longer than 15 characters would stymy hashcat.
It is unwise to base a password selection policy on potentially transient idiosyncrasies of a particular cracking tool. It is important to realize that other password cracking tools, John the Ripper, for example did not have that 15 character limitation. And has we know, these idiosyncratic limitations do change.
The Diceware list contains 7776 words (you get these through five rolls of a die or one roll of five dice), and so a password would be about 12.9 bits per word. So a five word Diceware password would be about 64 bits. If hashcat could check 300,000 per second then it would be about 1.5 million years to crack a five word diceware password. How many guesses per second hashcat can achieve (on the same hardware) depends enormously on how the password is hashed (straight hash, PBKDF2, scrypt ...).
The reason I'm picking 300,000 guesses per second in my example is because that is the number we get against a common form of the 1Password Master Password (PBKDF2-HMAC-SHA1 10000 rounds), which I wrote about back in April. There are more numbers in that article, along with links to other articles on using Diceware (including the article, Toward Better Master Passwords that may have triggered revived interest in Diceware just prior to the XKCD comic, and advocates a modified Diceware system for the few strong passwords you need to remember.)
Hashcat's move from a 15 character limit to a 55 character limit only matters if you were specifically choosing a password greater than 15 characters to avoid being in the domain of something that hashcat could work on. I hope that nobody was doing that.
In that article I wrote back in April I studiously did not mention the 15 character limit (which I was fully aware of) for the simple reason that I wanted to offer pessimistic (from the defender's point of view) estimates of cracking time weren't relying on what I saw as temporary limitations.
Randomness is mindless.
When an attacker tries to "guess" a password, he is actually trying to enter the mind of the human user and find out what that meatbag could have come up with. For instance, the attacker may say to himself "Mmh, this guy thinks he is smart, he may have made the first letter uppercase, and added a dot at the end. After all, he himself admits it on a public Web site. So I will add this rule to the passwords I try."
When dealing with passwords, the relevant technical concept is entropy (the one from information theory, not the one from physics). Roughly speaking, it tells how much "random" the password is. When using the "correct horse" method, with four words taken from a list of 2048 words, you have 44 bits of entropy, meaning that there are 244 possible passwords and you had the exact same probability of choosing any single one of them. Under these conditions, the attacker's average effort for cracking your password will be 243 tries, and it does not matter how smart the attacker is.
What this means is that the "entropy" measure gives you resistance against a theoretical, perfect ocl-Hashcat-plus software. It tells you the worst case for you, i.e. when the attacker is "in your head" and knows exactly how you generated your password, except for the contents of the really random choices. The attacker cannot predict your random choices because you cannot predict your own random choices either -- at least, as long as you do really random choice, i.e. with dice, not with your head. Human brains are terrible at being random. Dice are good.
So the new ocl-Hashcat-plus may be able to guess passphrases like the "correct horse" one, but cannot do that with less effort, on average, than 243 tries (which is rather a lot if proper password hashing was employed).
Setting the first letter to uppercase and appending a dot at the end does not help if you do so systematically -- the attacker-in-your-head also knows that you will do that, and adjusts his system correspondingly. On the other hand, if you randomly decide (with a coin flip) to append a dot or a comma at the end, then that's one extra bit of entropy, because the attacker-in-your-head is in your head, not in the head of the coin, and as such cannot know with probability better than 1/2 whether you chose "dot" or "comma". This doubles the number of possible, equiprobable passwords, so one extra bit of entropy; and the attacker's average effort is also doubled (or, if you prefer, his chances of success are halved for a given amount of effort). Of course, adding a character which has been chosen randomly means remembering whether this specific password used an extra dot or an extra comma. That's not free; your memory is the scarce resource in the whole business of passwords.
This can be explained very simple.
If you have four words taken from a list of 2048 words, the number of possible combinations is 2048^4.
That sounds like a huge number, but for oclHashcat-plus this is nothing to be scared of.
In most of time (maybe 9 of 10 cases) passwords on the web are hashed either using raw MD5, SHA1 or some obscure mixup of these algorithms with or without a salt added.
With oclHashcat-plus you can crack those hashes with ~6 Billion keys/second with a single hd6990 in combinator mode (which is required for passphrase attacks).
Simply explained, oclHashcat-plus will go through all possible combinations in less than a hour with an 3 year old GPU.
