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.

280 Reader Comments

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).

Party A has access to everything. Why are you more worried about Party B than Party A?

Quote:

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.

What difference does it make if the server itself is compromised? They can pull whatever they want off that.

After reading the article title and the first paragraph or two of the article (at which point my eyes started to gaze over) - it seems that correcthorsebatterystaple is now less strong a password?

I'm not seeing that, unless I'm misreading the article. Up until now, Hashcat has been able to crack passwords 15 chars or less. Now it's up to 55 chars. But... entropy is still in effect, and a larger password should still be more secure than a smaller one. I'm not seeing any huge increase in speed to make larger passwords able to be cracked in less time than smaller ones.

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?

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).

Party A has access to everything. Why are you more worried about Party B than Party A?

Quote:

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.

What difference does it make if the server itself is compromised? They can pull whatever they want off that.

A fair question, but the scenario I presented is not implausible. Consider some broke devs with poor ethics who realize they can sell some credit card account logins. They might consider themselves removed enough from actual credit card fraud that they would do it, but not have a problem with selling the logins to someone who will actually commit CC fraud.

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.

There won't be a true generational shift until quantum computers come into play. There's rarely one in even breaking existing encryption methods, they generally just make them slightly weaker and processing power gets stronger until one day it's just not worth a damn anymore. The issue is that what used to be a good password is now bad thanks to the general improvements in cracking passwords that has occurred over time. And a whole lot of people don't know that. Not even IT folk seem to know that, considering password policies still seem to allow $Golfing21 as a password.

The problem being shown here is that plenty of passwords that were considered good simply aren't anymore. And your 15 char random password simply isn't a reasonable solution in the slightest (even using password managers, there are still every day passwords we need like network logins that can't be managed through a password manager)

I remember KeePass let me tell it to require a number of key transformations to correspond to a second of compute time. I don't see why this isn't a standard procedure in things like Truecrypt. I can understand user authentication on websites, sort of. Making it even a 1MS delay would significantly help things.

This did remind me, though, to change my number of key transformations. I originally set this up in 2007-2009-ish. I was probably working on an Athlon 64 3200. I had about 2 million key transformations set up. I had KeePass set it to a one second delay on my I7-3770k, and it's bumped up well above 18 million key transformations.

Any time the database is saved it has to do those key transformations. In Truecrypt's case, couldn't the program just use the user's master key through several million key transformations to encrypt a larger, randomly generated key so that the only time these key transformations were done was when the user first entered the password?

8,000,000,000/18,000,000 = 444 password guesses a second if I'm correctly interpreting what these key transformations are.

This ends up with a sixteen character random password using 0-9,A-F as the character set. This is on an Intel based Redhat linux system. Is this sufficiently long to be secure? The machine is up for months at a time so the entropy should be good on the random device.

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.

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.

Almost all the usual techniques of adding "random" characters to dictionary passphrases are already covered by Hashcat. Almost all the usual techniques of obfuscating dictionary passphrases are already covered by Hashcat. If your base passphrase can be found using a google search, your passphrase is toast.

I have a question since this is out of my field of experience. But would it not be possible to encrypt the whole database and write a code which is also encrypted that deletes the data or trash it if attacks are detected?

As processing power advances, I think there is no other way to protect the Internet. You can do all you want to protect data from being leaked out but this will always happen. Hashes gave you a guarantee at least of something but there is no future for databases if they can´t be self protected from offline attacks.

What will be the purpose of hashing passwords in a database in 10 years from now if even a cell phone will be able to crack them?

Maybe a company can up with something like this. A self destructing database.

I have a question since this is out of my field of experience. But would it not be possible to encrypt the whole database and write a code which is also encrypted that deletes the data or trash it if attacks are detected?

As processing power advances, I think there is no other way to protect the Internet. You can do all you want to protect data from being leaked out but this will always happen. Hashes gave you a guarantee at least of something but there is no future for databases if they can´t be self protected from offline attacks.

What will be the purpose of hashing passwords in a database in 10 years from now if even a cell phone will be able to crack them?

Maybe a company can up with something like this. A self destructing database.

It seems like with something along that line, you'd be creating a built-in way for bad actors to DOS your own database.

Two-factor authentication seems like the best idea to me at this point. Let LastPass generate the strongest password the web site or app will allow, then use a diceware passphrase and YubiKey to get into LastPass itself. At this point, it's probably worth suffering without your data if you leave home without your YubiKey (they sell them in pairs in case you lose one).

Luxury. My utility company only allows 10 characters and you can't use symbols.

Must be awful to lie awake at night, afraid that some hacker pays your bill for you.

The level of stupid in this comment burns. A compromised account that could have your billing info, maybe your ccard info, possibly your social security account number, and your e-mail. Naaaa I see no issues with that info being obtained by "bad guys". None at all.

This ends up with a sixteen character random password using 0-9,A-F as the character set. This is on an Intel based Redhat linux system. Is this sufficiently long to be secure? The machine is up for months at a time so the entropy should be good on the random device.

The resulting search space is 16^16 (~1.8e19).

Suppose the website in question was programmed by someone completely incompetent and used only a single round of MD5 with no salt. If your attacker had this 25 GPU beast that can do 180 billion such hashes a second, he could run through that search space in around 3 years. Unless you're Glenn Greenwald, I think you're okay. If the website used bcrypt it would take over 8 million years.

This ends up with a sixteen character random password using 0-9,A-F as the character set. This is on an Intel based Redhat linux system. Is this sufficiently long to be secure? The machine is up for months at a time so the entropy should be good on the random device.

This one line:openssl rand -base64 49 | head -1...will give you a bit longer random and also include a few symbols.

I have a question since this is out of my field of experience. But would it not be possible to encrypt the whole database and write a code which is also encrypted that deletes the data or trash it if attacks are detected?

As processing power advances, I think there is no other way to protect the Internet. You can do all you want to protect data from being leaked out but this will always happen. Hashes gave you a guarantee at least of something but there is no future for databases if they can´t be self protected from offline attacks.

What will be the purpose of hashing passwords in a database in 10 years from now if even a cell phone will be able to crack them?

Maybe a company can up with something like this. A self destructing database.

It seems like with something along that line, you'd be creating a built-in way for bad actors to DOS your own database.

Two-factor authentication seems like the best idea to me at this point. Let LastPass generate the strongest password the web site or app will allow, then use a diceware passphrase and YubiKey to get into LastPass itself. At this point, it's probably worth suffering without your data if you leave home without your YubiKey (they sell them in pairs in case you lose one).

Not sure why someone down voted my comment. It seems some people would think anything that makes data more secure is a bad idea...

Regarding your comment, 2 factor authentication will do nothing to protect offline attacks. 2 factor authentication is to protect user hacking or compromise of his account. Most databases leaked are done from a system compromise.

Im talking here about protecting a database once its leaked of the server, which is what is mostly happening in most attacks. Most system have a login limit against brute force, but this article is about hacking databases which the attacker already owns locally but has hashed passwords.

In the future longer passwords will have no effect in terms of security of this attack. A new hashing would eventually be also weaker as computing gets more powerful, so its a game of the mouse and cat.

I think a database which cannot be read outside the server which can enable self destructing mechanism, similar to how brute forces protection work is the only way to look into the future. This way it would not really mater how much computing the hacker has, since he will only be able to test a few hashes before the database enters into panic mode and rewrites itself with garnish data.

I know this may not be easy, and this is the reason why this probably does not exist today as databases are supposed to be read and do not contain code by themselves to do anything.

Luxury. My utility company only allows 10 characters and you can't use symbols.

Must be awful to lie awake at night, afraid that some hacker pays your bill for you.

.... or cancels your utility for you altogether, or harvests your vital info and gives themselves and/or others utility in your name, uses that info to gain access to other accounts, or replaces your payment method with a fraudulent one....

While i know password security is important for sites were money transactions are made do we really need to keep making accessing forums to post anonymous comments harder?

I know that sites don't want spam but it seems that while banks and shopping sites still restrict passwords to six lower case letter only passwords. Forums are making it ever more difficult to remember the passwords your using with some even forcing monthly changes and others thinking of adding 2 factor authentication just to post! when even if your account is hacked there is no financial loss (unless your an idiot who uses just 1 password).

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.

It's true that you can implement limits like this, but it's more of an inconvenience than a layer of security. An attack can be distributed across many hosts with each one running at the set rate limit. It's not going to allow breaking into many accounts, but a targeted attack on an individual without a very long password is possible.

Some sites work around this by requiring something like a captcha, but that's just an arms race with software solving the trivial puzzles.

Of course, this isn't what the article is talking about so it's fairly off-topic .

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.

That just adds another layer of complication and not necessary more security.

If someone has access to the login database which is separate, they would already have access to the other separated databases you mentioned with data, its just privileges escalation.

Also this attacks are not targeted at getting information, which you would have anyway if you crack a hashed password, but compromise a service. Most data if its hashed will be cracked the same way as the password (even more easier as they are not random data).

In most databases it does not make sense to hash everything for performance benefits, they only hash passwords fields and some sensitive data, so a leaked database, already includes user information. This attacks what they want is to get the password of that user or specific users, in order to access this systems or services online and take over them.

I have a question since this is out of my field of experience. But would it not be possible to encrypt the whole database and write a code which is also encrypted that deletes the data or trash it if attacks are detected?

As processing power advances, I think there is no other way to protect the Internet. You can do all you want to protect data from being leaked out but this will always happen. Hashes gave you a guarantee at least of something but there is no future for databases if they can´t be self protected from offline attacks.

What will be the purpose of hashing passwords in a database in 10 years from now if even a cell phone will be able to crack them?

Maybe a company can up with something like this. A self destructing database.

It seems like with something along that line, you'd be creating a built-in way for bad actors to DOS your own database.

Two-factor authentication seems like the best idea to me at this point. Let LastPass generate the strongest password the web site or app will allow, then use a diceware passphrase and YubiKey to get into LastPass itself. At this point, it's probably worth suffering without your data if you leave home without your YubiKey (they sell them in pairs in case you lose one).

Not sure why someone down voted my comment. It seems some people would think anything that makes data more secure is a bad idea...

Regarding your comment, 2 factor authentication will do nothing to protect offline attacks. 2 factor authentication is to protect user hacking or compromise of his account. Most databases leaked are done from a system compromise.

Im talking here about protecting a database once its leaked of the server, which is what is mostly happening in most attacks. Most system have a login limit against brute force, but this article is about hacking databases which the attacker already owns locally but has hashed passwords.

In the future longer passwords will have no effect in terms of security of this attack. A new hashing would eventually be also weaker as computing gets more powerful, so its a game of the mouse and cat.

I think a database which cannot be read outside the server which can enable self destructing mechanism, similar to how brute forces protection work is the only way to look into the future. This way it would not really mater how much computing the hacker has, since he will only be able to test a few hashes before the database enters into panic mode and rewrites itself with garnish data.

I know this may not be easy, and this is the reason why this probably does not exist today as databases are supposed to be read and do not contain code by themselves to do anything.

It just an idea.

This (a data format that self-destructs on unauthorized access) is not possible to implement. There are many technical discussions running around as to why, but they generally break down to lack of execution control on systems you don't own. The copy operation (a fundamental processor operation) alone would invalidate such a scheme as you can just try on different copies until you are correct.

An easier indicator of the lack of this ability is the media industry. Your proposed system is quite literally perfect DRM. I have a feeling that if such a system were possible the media industry would use it first.

The real question is when are companies going to start protecting user data better by forcing split data to offline servers. There is no need to to have so much data available online when it could be split off onto a intranet and pulled up when needed which is most likely not very often. It's only needed during things like account recovery, changing passwords, changing emails, and so on. I've never seen any website that request this data more than once when you're signing up and I've never used it past recovering a account.

Accounts should always be forced to contain nothing that could ever link them to any other online accounts. Password security is no laughing matter these days and if done correctly the damage done by big leaks could be reduced drastically.

Look at it like this.

Leak A -It could be all of this or some.Account NamePasswordAddressPhone NumberCredit cardAlternate email.Name.Date of birth.SSN

Leak B -Account NamePassword END

Leak A could lead to many more of someones accounts being hijacked as well.

Forced data separation is a must and short of servers being physically stolen/downloaded on location "by a employee" leaks would be far less painful on the companies involved.At times peoples passwords are at fault for being absurdly trivial but the companies are at a bigger fault for being so goddamn careless with sensitive data.

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?

From what I understand different hashes have different characteristics in their results that make them fairly easy to recognize (length, characters allowed in the hashes, etc) but if it isn't obvious then their primary option would be what you assume. Having an account with a known password and hash result.

The first thing to remember is the process of creating the hash has to be repeatable. This is how you know if someone entered the correct password. You hash it again following the same process and see if the result matches what is stored in the database. That means that somewhere you'd have to record your psuedo-random sequence you are using to hash the password so that you know how to look it back up and repeat the process so your psuedo-random sequence isn't creating a secret that can be hidden. It is just some other known value the hackers already have and just have to figure out how to use. Repeatedly hashing something multiple times is how a number of more recent hashes allow you to adjust the time it takes to create the hash to help keep it secure.

The downside of trying to come up with your own process for randomly stringing hashes together is that you'll screw it up in some subtle way and end up making the hashes significantly less secure than they should be. Encryption and hashes are not simple things and people screw up often enough just trying to implement the standards that trying to come up with your own crazy process for mixing hashes is not a good idea.

Two was outdated about 10 years ago, LOL! Now we need four-factor authentication. Password, fingerprint, pin and keyfob.

Eva01

I might have missed the implied sarcasm tags here (implied by "LOL" perhaps?), but just in case they really aren't there, three of your four factors are static and are just as secure as a single password. The point of the keyfob is to have something dynamically changing so that the hacker can't know what it is even if he has a snapshot of all authentication factors.

And 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.

I am not an expert but my understanding was that the only way to be considered cryptographically secure was to ensure that the attacker couldn't break the password even if they had the hash and any other information they might need like the salt, the algorithm you are using, etc. Trying to hide nay of that other information really only amounts to security through obscurity which we've all heard isn't security at all.

The end result is that you can only try to make sure that the hashing process takes long enough that for a sufficiently long and random enough password that the computation time required is not practical based on current capabilities.

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.

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.

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.

There are 20,600 words in the simple English wikitionary. Lop off 600 for 1 and 2 letter words and other miscillania. 20,000 ^ 4 makes the search space 1.6e+17. At 180 billion guess a second that's around 10 days. At 71,000 guess a second it's around 71,000 years. Just makes sure you pick them in a random fashion. And for heaven sake, never reuse a password.

There are 20,600 words in the simple English wikitionary. Lop off 600 for 1 and 2 letter words and other miscillania. 20,000 ^ 4 makes the search space 1.6e+17. At 180 billion guess a second that's around 10 days

Preventing a straight dictionary attack shouldn't be too difficult though. Just mis-spell one word in your phrase: correcthorsebattnerystaple will ensure that you don't end up with anything that has ever been used before.

This ends up with a sixteen character random password using 0-9,A-F as the character set. This is on an Intel based Redhat linux system. Is this sufficiently long to be secure? The machine is up for months at a time so the entropy should be good on the random device.

It seems like you just need a random 16 character case sensitive full ascii printable password and you are above 96 bits of entropy. It is probably still crackable in 30-40 years but by then who cares. So I guess I need to upgrade my current random 13 character password. I could go all the way to 128 bits of entropy but 20 characters might get annoying.

The most annoying thing is that IT departments don't know a strong password from a weak one and thus just make me change my password every three months. Absolutely stupid. There should be two classes of passwords - strong (which don't have to be change more than once a year because it would take 10 years using state of the art cracking capabilities to crack it) and unacceptable passwords that require you to try again.