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.

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, nor the very simple expedient they can take to mitigate this threat entirely.

It is not about the resources protected by the compromised login database, as I mentioned above that's a done deal by the time the attacker has the password hashes. Any resources or information accessible from that product are already irretrievably gone. The one and only thing an offline attack can do to further hurt you is to revel the plaintext of your password. That only matters if you have reused that password (or a close variant) elsewhere. If you haven't than an offline attack is irreverent to you.

The takeaway message on these articles should be use a unique password for each site, not use a 200 character password filled with random line noise.

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?