Cracking really long passwords just got a whole lot faster and easier.

Share this story

For the first time, the freely available password cracker ocl-Hashcat-plus is able to tackle passcodes with as many as 55 characters. It's an improvement that comes as more and more people are relying on long passcodes and phrases to protect their website accounts and other online assets.

Until now, ocl-Hashcat-plus, the Hashcat version that can use dozens of graphics cards to simultaneously crack huge numbers of cryptographic hashes, has limited guesses to 15 or fewer characters. (oclHashcat-lite and Hashcat have supported longer passwords, but these programs frequently take much longer to work.) Released over the weekend, ocl-Hashcat-plus version 0.15 can generally accommodate passwords with lengths of 55 characters. Depending on the hash that's being targeted and the types of cracking techniques being used, the maximum can grow as high as 64 characters or as low as 24. The long sought-after improvement targets one of the last remaining defenses people employ to make their passwords resistant to cracking.

"This was by far one of the most requested features," Jens Steube, the lead Hashcat developer who also goes by the handle Atom, wrote in the release notes for the new version. "We resisted adding this 'feature' as it would force us to remove several optimizations, resulting in a decrease in performance for most algorithms. The actual performance loss depends on several factors (GPU, attack mode, etc.), but typically averages around 15 percent."

As leaked lists of real-world passwords proliferate, many people have turned to passwords and passphrases dozens of characters long in hopes of staying ahead of the latest cracking techniques. Crackers have responded by expanding the dictionaries they maintain to include phrases and word combinations found in the Bible, common literature, and in online discussions. For instance, independent password researcher Kevin Young recently decoded one particularly stubborn hash as the cryptographic representation of "thereisnofatebutwhatwemake." Such cracks are known as "offline attacks" because they target the hashes leaked as a result of a database compromise, allowing the person who recovers the hashes to try an unlimited number of guesses until the correct plaintext passwords are found. Once the underlying credentials are revealed, a hacker can use them to compromise the online account they secure.

Yiannis Chrysanthou, a security researcher who recently completed his MSc thesis on modern password cracking, was able to crack the password "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn1." That's the fictional occult phrase from the H.P. Lovecraft short story The Call of Cthulhu. It would have been impossible to use a brute-force attack or even a combined dictionary to crack a phrase of that length. But because the phrase was contained in this Wikipedia article, it wound up in a word list that allowed Chrysannthou to crack the phrase in a matter of minutes.

Until now, hackers and security consultants who cracked such words had to use software controlling the central processing unit of their computer or that used one or more graphics cards to crack a single hash. This weekend's update means that for the first time, Hashcat users can achieve speeds as high as eight billion guesses per second on a virtually unlimited number of compromised hashes. Breaking the 15-character limit is just one of several improvements designed to bring increased speed and precision to the password cracking program.

Microsoft Active Directory, anyone?

Another enhancement is the support of a new technique that allows crackers to radically reduce the number of password guesses by customizing their attacks to the password policy of company or organization they're targeting. Short for Password Analysis and Cracking Kit, the PACK toolkit was developed by researcher Peter Kacherginsky and can save huge amounts of time, particularly when targeting corporate networks.

"If we're a pentester, and we're to audit an AD [short for Microsoft Active Directory] domain, we typically face a password policy," Steube wrote. "Password policies aren't always very clever; most of the time, they force users to select passwords with predictable patterns... Using a specific set of masks we can avoid candidate passwords that do not match the policy, thus reducing the keyspace efficiently."

ocl-Hashcat-plus targets a much wider number of popular cryptographic products and applications, including TrueCrypt 5.0 and beyond, 1Password, Lastpass, the SHA256 algorithm in the Unix operating system, and hashing operations found in the latest version of Apple's OS X operating system. The program also supports a much wider array of video cards from both Nvidia and AMD.

In all, Hashcat developers spent more than six months modifying 618,473 lines of source code, accounting for more than half of the Hashcat code base. Going up against a typical TrueCrypt configuration, a PC running ocl-Hashcat-plus and two AMD HD 6990 video cards can cycle through 223,000 password candidates each second, fast enough to exhaust all 14.3 million words contained in the seminal RockYou dump of passwords in 65 seconds. In many cases the slowdowns created by the support of long passwords has been offset by enhancements made to other parts of the program. One such improvement arranges passwords continued in user-supplied lists by the number of characters. Under many conditions, this can significantly reduce the time needed for GPUs to process the data.

The new version of Hashcat came two days after developers for Russia-based ElcomSoft updated the company's Phone Password Breaker software. The fee-based forensic tool now supports the selective recovery of certain types of data stored in Apple's iCloud service. The new version allows users to retrieve contacts, call logs, pictures, or other specific types of backed up data without having possession of the original iPhone, as long as the attacker has the user's Apple ID and password.

Promoted Comments

Perhaps i'm naive, but wouldn't a solution to this be simply to implement attempt limits?

This isn't an online attack. Hashcat and variants work by attacking the password hashes after they've been leaked/stolen somehow. Not by attempting billions of logins per second over the Internet (if any server allowed that... someone needs to change careers).

Perhaps i'm naive, but wouldn't a solution to this be simply to implement attempt limits?

From article: Such cracks are known as "offline attacks" because they target the hashes leaked as a result of a database compromise, allowing the person who recovers the hashes to try an unlimited number of guesses until the correct plaintext passwords are found.

In other words, they have your database, nothing you can do about attempt limits.

Such cracks are known as "offline attacks" because they target the hashes leaked as a result of a database compromise, allowing the person who recovers the hashes to try an unlimited number of guesses until the correct plaintext passwords are found. Once the underlying credentials are revealed, a hacker can use them to compromise the online account they secure.

This makes no sense. If the attacker has comprised the login database, they already have access to the online account that database controls access to.

I depends on what you mean by compromising the login database. For example, the RockYou attack was an SQL flaw, attackers were able to make RockYou's servers give them the entire user database (including passwords, usernames, etc). This is a pretty common way of attacking databases like this (when they're badly made, same way Sony was exploited a few years back).

The user database is generally (should be) very separate from the user account. The login server handles where you log in, that verifies who you are and gives you access to other databases. If those databases are better secured, getting user login details doesn't give you squat (especially if the passwords are well encrypted).

In RockYou's case, they were storing everything in plaintext, making them horrible people.

If an entire login database was actually taken over and a hacker had complete control, you're right, it'd be really bad and your password security doesn't matter (they could simply replace the hash of your password), but that doesn't actually happen very often.

All of a sudden, fingerprint reading touch screen makes much more sense than just couple of months ago, Now let's wait for Apple keynote if it becomes reality

Please, everyone that reads this, never ever ever ever hint, imply, suggest, or otherwise encourage the use of biometrics (fingerprints) as an authentication factor. If you think it's hard to change your password everywhere when there's a breach, just imagine how much harder it would be to get your finger changed too.

As far as this specific change I'm not sure how it affects xkcd or correcthorsebatterystaple. There still isn't going to be anyone cracking that by brute force because it is still far to long for that to be computationally practical. The question is does hashcat now allow you to find that from combining 4 dictionary words together where it didn't before or was it already able to crack it from dictionaries because it only considered it 4 entries long. That I'm not sure of. If it wasn't able to before and is able to now then it would weaken the strength of these types of pass phrases.

The point of the many articles recently on this subject is that no one will ever need to brute force any variation on "correcthorsebatterystaple" because it's in the password hacking dictionary. Any pass phrase that is written down on the internet, whether xkcd comic, movie quote, or biblical passage, is inherently less secure than a random (even lightly pseudo-random) pass phrase of similar length.

If your phrase is indexed somewhere (like a song lyric is), then your method is not much more secure than just using the phrase directly. This has been such a long-recommended password generation technique that anyone hacking passwords would include it in their list of attacks.

It's not a phrase; its an initialism.

They are not indexing the the entire discography of music. Even if they they tried they would have to index every lyric at every length then cut to the first letter or the last letter and include the air version and the explicit version, etc.You pick where to start the initialism and where to end it.

If you will look at what I wrote, you'll see that nothing you wrote in response counters what I said. The key phrase in my post is "your method is not much more secure than just using the phrase directly." In other words, if the original phrase is fairly secure (due to the random selection of which words in the lyric you select), then your initialism is just about as secure. If the original phrase is common enough to be in the dictionary, then any decent password tool is going to allow a quick search of common variations of that phrase, including initialism.

For example, if your magic phrase is "If you can't be with the one you love, love the one you're with" and it's included in a password dictionary (due to it being posted on Ars, for example) then the tool would probably include a good variety of derivative passwords, like:

iycbwt1yl,ltoywIycbwt1yl,ltoywiycbwt1ylltoywIycbwt1ylltoywetc.

If your phrase is not in the dictionary, then its initialism also won't be in the dictionary (unless of course someone somewhere has used it in a hacked database).

Disclaimer: I still use memorable variations of words for most of my passwords. Two of my three words are in the RockYou leak. However, they are easier to type. I have started using Keepass, and it generates and stores every password for sites I deem to be a "less secure" site.

TL;DR - Password hackers know all the common variations of manipulating memorable phrases and words. The breadth of "common" is expanding every day, therefore the odds of your particular "clever" variation is getting closer and closer to insecure.

creating pseudo-random passwords based on extremely long popular pass-phrases are also no longer going to protect your password..

Why would anyone need to use popular passphrases? Nonsense passphrases are very easy to remember:

friedrich nietzsche's norwegian antelope said ''lykke til'' to his japanti-cromtash

I reckon most people here could remmber that within a few minutes if I gave them $1000 dollars - Long nonsense passphrases are very safe at the moment (and that's a simple one using 2 languages and the odd nonsense word)

I guess what I'm still unsure on is how are these hashes that something like this breaks being created - is it JUST the password hashed using SHA1/SHA2 or are they being busted even with salts?

It's been well over a year now since I last built a login/auth, when I did it I took the password (forced to >= 12 characters, being of the understanding that length is the more important factor), split it in the rounded middle and inserted a 15 character alpha/number/symbol string as the salt, stitched it back together and then SHA2(512) encoded it… figured that had to be pretty secure.

Where the password is 'correcthorsebatterystaple' and the salt is '@atRAbe$_h*sEnu'.

Is this post indicating that even the resulting hash of that will succumb to this type of crack?

If so then fuuuuuu.

Salt is mostly a defense against rainbow tables not brute force hashing. Though in the later case it does mean each one has to be attacked individually instead of working on the whole list at the same time. While your scheme is better than storing the plaintext or omitting salt, it is still very weak.

Use Bcrypt, Scrypt, or PBKDF2.If you insist on rolling your own (which you should not!) at least do many more rounds of hashing.

This is truly scary. I'm glad people are doing the research. Because security through obscurity isn't really secure. It just goes to show that the only secure password is a one time random string. Purely random passwords are significantly harder to crack because they use no patterns. And using it only once means even if you crack it, it spreads nowhere.

That works when someone's attempting multiple logins through your front page. Those attacks are easily mitigated, though. The more effective attack vector is to get a database dump and work on that directly, bypassing the frontend and whatever limits are written into it.

Perhaps i'm naive, but wouldn't a solution to this be simply to implement attempt limits?

This isn't an online attack. Hashcat and variants work by attacking the password hashes after they've been leaked/stolen somehow. Not by attempting billions of logins per second over the Internet (if any server allowed that... someone needs to change careers).

Perhaps i'm naive, but wouldn't a solution to this be simply to implement attempt limits?

These tools are aimed at offline attacks – attacks where hashed/encrypted password has been leaked. There have been many such publicised leaks over the past year. In such cases, the hacker can make as many attempts as they want.

The goal is not to gain access to the specific account targeted, since you already backdoored/hacked access to that. The goal is to acquire the plaintext password used by the user, in order to use it in a different place.

In other words, the goal is to take your Facebook password, to log in to your bank account.

Perhaps i'm naive, but wouldn't a solution to this be simply to implement attempt limits?

From article: Such cracks are known as "offline attacks" because they target the hashes leaked as a result of a database compromise, allowing the person who recovers the hashes to try an unlimited number of guesses until the correct plaintext passwords are found.

In other words, they have your database in their hands. There is nothing you can do about attempt limits.

Even that is not 100%. When RSA's seeds were compromised, I remember the shitstorm that caused as it directly affected some of my clients. Kudos to Ars for coming up second in a serch for more information.

Going up against a typical TrueCrypt configuration, a PC running ocl-Hashcat-plus and two AMD HD 6990 video cards can cycle through 223,000 password candidates each second

So basically this is a non-story. Bad passwords are still bad, good passwords are still good. Assuming an attacker had a botnet with 10,000 such machines available full time, it'd still average a few trillion years to attack a 15-char password (the old upper bound) randomly selected from the basic 94 face keys on a keyboard. Anyone using something extended, or alternate character sets, would boost it even farther. So yeah, I guess this further highlights that non-random passwords are worthless but that was pretty much always the case. Whatever strategy you use, be it a short password from a large unit pool or a long password from a small unit pool or something in between, it needs to be fully random to be of much value. But conversely, if it is then there isn't really anything to be concerned about short of a true generational shift.

Also:

Quote:

ocl-Hashcat-plus targets a much wider number of popular cryptographic products and applications,[…] 1Password, Lastpass

These (and keypass, and any crypto product really) all are to the best of my knowledge using key stretching (as they should be). Assuming there wasn't a screwup in the implementation they should be pretty resistant to brute forcing, though perhaps there is room for improvement (such as GPU acceleration).

Even that is not 100%. When RSA's seeds were compromised, I remember the shitstorm that caused as it directly affected some of my clients. Kudos to Ars for coming up second in a serch for more information.

Be careful, "2 factor" refers to a number of different approaches, not just online fobs. A PKI/GPG system for example doesn't share any of the weaknesses involved there and doesn't require any third party or net connection whatsoever for that matter.

This is truly scary. I'm glad people are doing the research. Because security through obscurity isn't really secure. It just goes to show that the only secure password is a one time random string. Purely random passwords are significantly harder to crack because they use no patterns. And using it only once means even if you crack it, it spreads nowhere.

In a perfect world, of course! But security through obscurity is the rule in contemporary life, not the standard. I lock my doors of my house, I lock filing cabinets with relatively sensitive information, and I lock my bike to poles; however, since most locks are easy to pick, doors can be kicked down, and bike parts can be removed with a small allen wrench, what I'm really betting on is that if there's the rare chance that someone wants to take my stuff, that the extra effort is non-trivial enough to deter them at least that one time.

Generally, security measures are both social and technological systems, so most security can never rise to the level of being perfectly secure. Whenever I read articles like this, I worry for a moment, then I realize that there's nothing here on what kinds of systems are most likely threatened. I'm not about to go change my facebook password after reading this, but if I had a database with banking account numbers, I'd be freaking out a little bit.

Perhaps i'm naive, but wouldn't a solution to this be simply to implement attempt limits?

This isn't an online attack. Hashcat and variants work by attacking the password hashes after they've been leaked/stolen somehow. Not by attempting billions of logins per second over the Internet (if any server allowed that... someone needs to change careers).

First we need to have companies update their websites so that long passwords are even a possibility. Some banks still limit you to 12 characters!

This. I recently needed to create a login to my health insurance system. I was pleasantly surprised when I saw them have a bullet point that said something to the effect of "we support symbols such as @_#." Apparently the password generated by LastPass (n number of characters, with allowing for different casings, numbers, and symbols) was still considered invalid.

All things considered, I really dig the amount of forethought and energy put into building tools like this with the intent of exposing problems and holes in modern security systems; it just saddens me that these same problems are then exploited by malicious parties.

Such cracks are known as "offline attacks" because they target the hashes leaked as a result of a database compromise, allowing the person who recovers the hashes to try an unlimited number of guesses until the correct plaintext passwords are found. Once the underlying credentials are revealed, a hacker can use them to compromise the online account they secure.

This makes no sense. If the attacker has comprised the login database, they already have access to the online account that database controls access to.

This entire series of articles has been seriously flawed in that it has never clearly explained the threat that offline attacks pose to end users, [snip]

What if party A compromises the database and releases the list of credentials to Party B? Party B can perform the offline attack but does not have access to the information behind the login (well, yet).

I'm not sure how that's unclear. From the very portion you quoted, it lets attackers make unlimited attempts, thus bypassing any "three strikes and you're out" policies that various websites employ.

Even that is not 100%. When RSA's seeds were compromised, I remember the shitstorm that caused as it directly affected some of my clients. Kudos to Ars for coming up second in a serch for more information.

Be careful, "2 factor" refers to a number of different approaches, not just online fobs. A PKI/GPG system for example doesn't share any of the weaknesses involved there and doesn't require any third party or net connection whatsoever for that matter.

Granted, you are correct that there are other means of authentication. I was coming from the solution that most government/enterprise/corporations utilize when large scale security solutions are needed. Those beasts move slowly.

Well now I'm glad I didn't bother changing all my passwords to be long phrases. Not to mention "correct horse battery stable" is probably a worse password to have now over "password123". The NSA already have my emails too so I think the only strategy left to us is to not have any valuables online.

For reference, this breaks passwords that can be found in another source. The proper way to secure such a password would be to add a few random characters. thereisnofatebutwhatwemake is easy enough to remember, so just adding something to it like ther3eisn3ofatebutwhatwema9$ke would probably make it safe so long as your particular technique is not known (don't use the exact same alteration as you see someone else do), while not adding much effort to the memorization.

Going up against a typical TrueCrypt configuration, a PC running ocl-Hashcat-plus and two AMD HD 6990 video cards can cycle through 223,000 password candidates each second

So basically this is a non-story. Bad passwords are still bad, good passwords are still good. Assuming an attacker had a botnet with 10,000 such machines available full time, it'd still average a few trillion years to attack a 15-char password (the old upper bound) randomly selected from the basic 94 face keys on a keyboard. Anyone using something extended, or alternate character sets, would boost it even farther. So yeah, I guess this further highlights that non-random passwords are worthless but that was pretty much always the case. Whatever strategy you use, be it a short password from a large unit pool or a long password from a small unit pool or something in between, it needs to be fully random to be of much value. But conversely, if it is then there isn't really anything to be concerned about short of a true generational shift.

The transition from "Bank robbers have dynamite to blow up the bank" vs "The mafia owns the corporation that runs the bank where you store the money" is newsworthy. It's not a direct comparison, but an escalation of ability is a story.

Would you rather NOT know that the capability of this program has been enhanced, signficantly?

This only really impacts people that are using quotes. If you use any sort of randomly generated password (whether sf3o4tGS[/ style or dice ware, and anything in between), your protection is still based on the massive number of potential combinations. It was already infeasible to crack passwords with high entropy, and this changes nothing.

Unfortunately, people still don't seem to realize how this all works (except the black & white hats).

Quick Question: How do you know what hashes (in combination and/or iteration) you need to plug into your cracker?

In some cases, the answer is relatively straight forward because it's either one hash and you (the cracker) have an account there so you know the plain text of at least one password. Thus you could try the various common hashes to find out what is being used. Or it could be an open-source or well studied thing (like truecrypt), thus you know that way.

But in general, how do you know? Why can't they (the entity securing the passwords) do something like use 10 different hashes in a row iterated 100 times each in a psuedo-random manner?