“thereisnofatebutwhat­wemake”—Turbo-charged cracking comes to long passwords

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

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.

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!

Ten and no special characters. Haven't checked in a while, but Sun Life was very bad about that. USAA was also pretty low (about 12) but at least they have a second "pin number" section. Of course, that's no good if people make that pin section the same as their ATM card pin number, but oh well.

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.

In addition it's my understanding that the password guessers have rulesets that can attempt combinations of dictionary words. So even if you used four other common words that add up to less than hashcat's new length limits your password is now more vulnerable to cracking even if those four words don't appear together in order anywhere on the Internet. Furthermore the rule sets allow for the obvious methods of adding numbers or symbols such as between words or as common letter replacements ("3" for "e", "2" for "to", etc.). Obviously using less common words increases the size of the dictionary required and as others have pointed out, using a dictionary file containing every possible word in the English language would take too long to be feasible. For now.

One way to attempt to mitigate this problem would be to use words from different languages, since having to use dictionaries from multiple languages would also likely have the result of making it take too long to crack. But I personally think the better way to create a password you have to remember is to create a new phrase composed of portions of phrases you can easily remember, then taking the first letter of each word of your new hybrid phrase and adding a few numbers and symbols wherever you can remember them. As a simplistic example let's take the phrases "Who you gonna call?" and "The knights who say NEE!" and use portions of them to create a new phrase "The knights who say Who you gonna". Taking the first letters gives us "TkwsWyg" and then you can stick in the first number of the earliest house address you can remember and a symbol, giving "Tkws4%Wyg". Obviously you'll want to choose more/longer phrase sections and stick in more numbers and symbols so you end up with a longer password. But as long as you take only portions of easily rememberable phrases and combine them in an original way, it will not be possible to generate the password based on a dictionary of common words or phrases. Instead it would be necessary to actually brute force the password using every possible combination of letters, numbers and symbols, and assuming the password is long enough that's pretty much the worst possible scenario for cracking programs.

Now, obviously you don't want to have to create and remember a new hybrid phrase-based password like this for every site you visit. So suck it up and use a password manager, and just use this technique to generate the master password for the password manager itself and those one or two other places you really want to be able to remember the password instead of having to get it out of the manager.

So... I guess we're back to completely randomly generated passwords, then? Other than two factor, that remains the most effective deterrent to cracking, leaving only brute force as an option.

robrob wrote:

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)

If it's a truly randomly generated password, then you're incorrect. There are 94 (95 with space, and 96 with tab) possible characters on a standard US QWERTY keyboard. A completely random 15 character password has:94^15 = 395,291,798,759,682,000,000,000,000,00095^15 = 463,291,230,159,753,000,000,000,000,00096^15 = 542,086,379,860,909,000,000,000,000,000

possible combinations. At 8,000,000,000 guesses / second (as indicated in the article), it would take up to:4.94114748449602E19 seconds... or about 1,565,755,153,907 years to brute force a 15 character, random password with just 94 characters. Add tabs and spaces and that number just goes up.

And your second point of network logins and other things that a password manager can't hook into is also incorrect. Other than actually getting into your computer or your password manager database, every password in the database can be copy/pasted. As long as your system isn't already compromised and the contents of your clipboard being sniffed, you should be fine. You can mitigate the computer and password manager login problems by either generating something random but that you can remember through repetition (this is what I did), or writing it down, preferrably encrypted with something like PasswordCard or Diceware, and keep it in a safe place that hopefully only you have access to.

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.

...

really hope you're not being serious. I mean, it's better than depending on a common phrase or pop culture quote, but why would you limit yourself to only 16 possible characters per space?

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.

If your dictionary is actually that large then yes it would be basically uncrackable at current technology level but the reality is that you can craft a much smaller dictionary that is still going to contain a large percentage of the words people would use for this type of thing. This is even more true as they start collecting real world data of what people are using. If you use a much more reasonable dictionary of 2,000 words to limit it to common shorter words your search space is much smaller and your password isn't nearly as secure. If you are using something like dice, you are fine because they do have a good dictionary and the words are random. If you are trying do it off the top of your head the odds are that they can find significant shortcuts to make your password much less secure. It's the same basic reason why P@ssw0rd01! looks pretty good to most password strength meters but is actually really weak.

And if hascat plus using gpus couldn't crack any combination passwords that ended up longer than 15 characters before but can now then it is a decrease in the security of those passwords because gpus provide a significant performance advantage meaning a larger dictionary can be completed in a more reasonable time frame so it is more likely to include all the words you used and if your words were already in their dictionary it will complete that much quicker.

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.

In addition it's my understanding that the password guessers have rulesets that can attempt combinations of dictionary words. So even if you used four other common words that add up to less than hashcat's new length limits your password is now more vulnerable to cracking even if those four words don't appear together in order anywhere on the Internet. Furthermore the rule sets allow for the obvious methods of adding numbers or symbols such as between words or as common letter replacements ("3" for "e", "2" for "to", etc.). Obviously using less common words increases the size of the dictionary required and as others have pointed out, using a dictionary file containing every possible word in the English language would take too long to be feasible. For now.

A 6 word Dice Ware password, at 180,000,000,000 per second would take just shy of 39,000 years to crack. If that concerns you a bit, pick a random character to use as a separator, and now you're into the millions of years. A 6 word "password" isn't hard to remember, it's easy to type on any device (including phones!), and used as the Master Password for a password manager could protect countless passwords (and any decent password manager uses pbkdf2, bcrypt, scrypt, or an equivalent system with a decent to great work factor).

For cases where the password manager can't integrate with the login system (such as not a browser based system), and copy+paste wouldn't work, you could just generate another Dice Ware passphrase, which is still easier to type than a completely random string of characters.

If you're really paranoid, you could go with a 7 word passphrase, and that 25 GPU machine would take over 300 million years to break your password.

Or, if the admin/dev wasn't incompetent (one can dream?), multiply all those time frames by 1,000 to 100,000 (or potentially more). So that "bad" 39,000 year password would take potentially 3.9 billion years. That 7 word passphrase at 100,000 iterations? Let's just say it would be easier to measure it in multiples of the current age of the universe (and even then, you'd be in thousands of times longer than the universe is estimated to have existed).

And your second point of network logins and other things that a password manager can't hook into is also incorrect. Other than actually getting into your computer or your password manager database, every password in the database can be copy/pasted. As long as your system isn't already compromised and the contents of your clipboard being sniffed, you should be fine. You can mitigate the computer and password manager login problems by either generating something random but that you can remember through repetition (this is what I did), or writing it down, preferrably encrypted with something like PasswordCard or Diceware, and keep it in a safe place that hopefully only you have access to.

The whole building just took a power surge and your computer just rebooted. Log in using your random 15 character password that you couldn't commit to memory.

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!

Ten and no special characters. Haven't checked in a while, but Sun Life was very bad about that. USAA was also pretty low (about 12) but at least they have a second "pin number" section. Of course, that's no good if people make that pin section the same as their ATM card pin number, but oh well.

Or just start using driver's licenses with smart chips in a common registry for everything.

Apparently, bankers calculate the costs and benefits of implementing proper password policies differently than technologists do. So it doesn't really matter as much as we would assume -- otherwise, this would have been fixed by now.

I feel practically forced to conclude that: banks and other institutions consider the costs incurred by inevitably compromised accounts, to be thoroughly outweighed by the increased business brought about by increased consumer convenience and ease, and/or the savings brought about by substantially shifting customer service load from human employees to automated interfaces over the web.

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

My thoughts exactly, that is why I use a base random password with capitals, lowercase, numbers and symbols with a random salt thrown into the middle for each site. I use something that I will remember for that site such as the first letter of each syllable of the site.

For example say that my random password was tHy53-#85lD I use that password for each site with the salt in between the - and # so that if my password for one site is found it will be useless for all of the other sites. For Gmail I may use gm so my password becomes tHy53-gm#85lD or for my wells fargo bank account I would use wfg so my password would be tHy53-wfg#85lD. This way I can remember the password for each site but it isn't vulnerable to this type of attack. If I needed to change my password I could either change the salt, the location of the salt, or the base password.

And your second point of network logins and other things that a password manager can't hook into is also incorrect. Other than actually getting into your computer or your password manager database, every password in the database can be copy/pasted. As long as your system isn't already compromised and the contents of your clipboard being sniffed, you should be fine. You can mitigate the computer and password manager login problems by either generating something random but that you can remember through repetition (this is what I did), or writing it down, preferrably encrypted with something like PasswordCard or Diceware, and keep it in a safe place that hopefully only you have access to.

The whole building just took a power surge and your computer just rebooted. Log in using your random 15 character password that you couldn't commit to memory.

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 don't see why the guys saying you need to use different IDs and passwords on different sites are wrong. The article clearly says (and many comments reiterate) that these attacks are being done offline, on a stolen DB. Of course they can take their sweet time cracking it, I'm not really impressed by how fast they can do it, since by now the answer is already "they can".

Go ahead, steal my facebook login - I only use that ID there, and that password there. Ditto, have fun looking up my Reddit login too, it's also another ID I don't use elsewhere. I don't give a shit if they're jacked, but even then I use a tough passphrase for them out of spite. Good job, you cracked it... oh wait, it's useless, since I don't use it elsewhere.

I'll repeat what the others said, use a different ID on different sites and different passwords as well. Doesn't matter if they crack the login for site X, when it's only used on site X and nowhere else.

If it's a truly randomly generated password, then you're incorrect. There are 94 (95 with space, and 96 with tab) possible characters on a standard US QWERTY keyboard. A completely random 15 character password has: <snip>

Totally agree from a technical solution, 15 characters using 94 characters is very, very secure. What I mean is the human perspective. Trying to get people to actually remember Td*4j3s8)sddH54 is extremely difficult. More than one password is going to be beyond the reach for most people without resorting to sticky notes.

Quote:

And your second point of network logins and other things that a password manager can't hook into is also incorrect. Other than actually getting into your computer or your password manager database, every password in the database can be copy/pasted. As long as your system isn't already compromised and the contents of your clipboard being sniffed, you should be fine. You can mitigate the computer and password manager login problems by either generating something random but that you can remember through repetition (this is what I did), or writing it down, preferrably encrypted with something like PasswordCard or Diceware, and keep it in a safe place that hopefully only you have access to.

With active directory, your password to get into your computer is usually your computer login, that's what I was referring too. However two 15 random character passwords is too many for a person to reasonably look after and remember, network admins already reset god knows how many simpler passwords because people forget them.

But personally, I have two networks, 3 computers, a phone and a tablet I have to deal with. I often access my work VPN via computers that aren't mine. It simply becomes an unreasonable number of passwords to remember or I have to constantly flick between devices just to unlock one device. If you make it that complicated, users are simply going to rebel against it, they're not going to use Diceware they're going to use sticky notes.

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.

You're still missing what an SQL injection is. You don't have access to the site. You send a message to the server and it has the privileges. You tell it your name is "Robert" and it runs a check to see if you're in the database. An SQL injection works via what being sent isn't clean (ala http://xkcd.com/327/), instead of having limits to what you can send the server (your name and password) you can create a SQL query that returns whatever you want (such as the entire database of users, password hashes, etc).

You say "its just privileges escalation", but that doesn't make any sense, you don't ever have access to the server directly nor connection to any other database, you can't craft a SQL string to give you access to everything that's potentially connected to that server.

If it's a truly randomly generated password, then you're incorrect. There are 94 (95 with space, and 96 with tab) possible characters on a standard US QWERTY keyboard. A completely random 15 character password has: <snip>

Totally agree from a technical solution, 15 characters using 94 characters is very, very secure. What I mean is the human perspective. Trying to get people to actually remember Td*4j3s8)sddH54 is extremely difficult. More than one password is going to be beyond the reach for most people without resorting to sticky notes.

Sticky notes have a bad rap, but they protect against most of the attacks most people are concerned about. A hacker in Sevastopol isn't going to find it any easier to access your bank account because you taped the password to your monitor. On the other hand, your babysitter may well be able to.

You can only reasonably protect yourself if you have a clear and reasonable threat model. There are always trade-offs to be made.

The security people where I work are very good, and very clued. They had a very brief seminar a couple months ago and they're very aware of the state of the art in this area (and others). They discussed spear phishing, recommended using DiceWare for generating passwords, using misspelled words and/or homonym/numeric substitution for words in phrases, adding unique characters before/after a phrase, and mentioned using a password program (although they couldn't officially recommend one).

And so I suspect they were screaming at the sky when it was mandated that you change your password a couple weeks ago, and it included a number of recommendations:

* mixed case, numbers, symbols (must have 3 of the 4)* password cannot contain more than a few sequential letters of your name or login id* A couple other rules I don't care to disclose* minimum 8 characters* maximum 16 characters

Every single example violated the last rule, and I'm willing to bet that there's some system that has issues with >16 characters that causes the requirement.

The odd thing is that while this password is used for some things, a combination PIN and 2factor is used for other systems. I'm guessing they couldn't use it for everything for the same reason they're limited to idiotic 16 character passwords -- some system just couldn't handle it.

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.

Just think how awkward it would be to sign in to your phone in a business meeting after you had lost your password 10 times. You would have to log in with your toe print.

In addition it's my understanding that the password guessers have rulesets that can attempt combinations of dictionary words. So even if you used four other common words that add up to less than hashcat's new length limits your password is now more vulnerable to cracking even if those four words don't appear together in order anywhere on the Internet. Furthermore the rule sets allow for the obvious methods of adding numbers or symbols such as between words or as common letter replacements ("3" for "e", "2" for "to", etc.). Obviously using less common words increases the size of the dictionary required and as others have pointed out, using a dictionary file containing every possible word in the English language would take too long to be feasible. For now.

A 6 word Dice Ware password, at 180,000,000,000 per second would take just shy of 39,000 years to crack. If that concerns you a bit, pick a random character to use as a separator, and now you're into the millions of years. A 6 word "password" isn't hard to remember, it's easy to type on any device (including phones!), and used as the Master Password for a password manager could protect countless passwords (and any decent password manager uses pbkdf2, bcrypt, scrypt, or an equivalent system with a decent to great work factor).

Personally I find phrases to be easier to remember than random words that make no grammatical sense when strung together. I suspect I'm not alone in this, which is why I recommended the system I did in my original post. It allows you to create a memorable phrase that likely doesn't already exist and then processes it in a memorable way into a password that very closely approximates a truly randomly generated string of gibberish that isn't going to be reproducible by a ruleset that's going to be meaningfully more efficient than a brute force attack.

Its true, the only security passwords have to offer is its length relative to computing power. The goal then is to leave crackers no choice but to brute force.

Humans have got to learn to implement Knuths pseudo-random number generator in their heads and be creative in using readily observable things in their environment (like clothing color combination of their co-workers) as seed. Otherwise, long term, the convenience of passwords will no longer be an option.

Looks like sophisticated password mangers are quickly becoming a necessity. Two-crack authentication helps a lot, but at the end of the day extreme password length and randomness are the only insurmountable obstacles to cracking, and those factors will have to exponentially increase as computer hardware and cracking techniques improve.

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.

This data separation is already mandated by U.S. law, if you're talking about data on paper.

Personally identifying information (PII), as well as any information shielded by HIPAA, must be stored separately and securely from employee records on relatively non-sensitive information, such as evaluations and status forms.

Lawsuits have already been won, and large sums paid, because employers did not do this properly.

It would seem to me that, for the sake of liability alone, databases would be similarly structured.

Looks like sophisticated password mangers are quickly becoming a necessity. Two-crack authentication helps a lot, but at the end of the day extreme password length and randomness are the only insurmountable obstacles to cracking, and those factors will have to exponentially increase as computer hardware and cracking techniques improve.

Two-factor only stops your active accounts from being hijacked, Matt Honan style. The article is referring specifically to offline cracking of already-stolen password databases. Only a long and random password will protect your info from offline attack.

I think this has not yet been said, or stated clearly: The point of the long password is to buy you time to change your password after it has been stolen.

No password is unassailable, but some are tougher than others. The point is to make hacking your password a massive pain in the ass, so that yours is the last password standing. This gives you time to secure compromised accounts.

The whole building just took a power surge and your computer just rebooted. Log in using your random 15 character password that you couldn't commit to memory.

(HINT: this was the point)

(HINT: that's why I also suggested writing it down, preferably encrypted. Even writing it down in plaintext to have while you're memorizing it, and then burn the note once you're confident it's committed to memory would work.)

Also most password managers have mobile clients. I know for certain 1Password, LastPass, and KeePass have apps on iOS and Android (dunno about WinPhone). That'd be another good option.

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

My thoughts exactly, that is why I use a base random password with capitals, lowercase, numbers and symbols with a random salt thrown into the middle for each site. I use something that I will remember for that site such as the first letter of each syllable of the site.

For example say that my random password was tHy53-#85lD I use that password for each site with the salt in between the - and # so that if my password for one site is found it will be useless for all of the other sites. For Gmail I may use gm so my password becomes tHy53-gm#85lD or for my wells fargo bank account I would use wfg so my password would be tHy53-wfg#85lD. This way I can remember the password for each site but it isn't vulnerable to this type of attack. If I needed to change my password I could either change the salt, the location of the salt, or the base password.

I have done something similar, but your "salt" is almost immediately obvious to anyone looking at your plain text password. It wouldn't take much to guess that your Facebook password would be something like:

tHy53-fb#85lD

Or

tHy53-fbk#85lD

Or some variation thereof. If one password is compromised you might find that they all are. Ideally you should obfuscate your per site customizations in some manner. Do a keyboard walk on them and then reverse the order and split them up and interleave them back into your base. That way your Facebook password goes from:

tHy53-fbk#85lD

To

ItHy53-g#r85lD

(fbk became rgi - look at your keyboard to see why -, then it was reversed to igr, and then split up and inserted into the rest of your password)

now anyone looking at your plan text password will not be able to easily deduce your pattern.

It's becoming increasingly obvious that corporations really need to abandon passwords and replace them with a dual-factor authentication scheme. For simplicity, perhaps cherry-picking the latter two from "something you know, are or have" - biometrics combined with a smart card, for instance. There are already AD integrated variants of that.

It seems like the only way to do passwords safely is a password manager where you retain control over the database file (like KeePass) - not even Hashcat can crack something that isn't in a dictionary and is really long and random, but no normal human can remember and type in "PAFx/pSfc5d`?LUENsy\tGmDj4TC;X*6i8eQ9YJV2vhZq":=" ...

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.

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.

You're still missing what an SQL injection is. You don't have access to the site. You send a message to the server and it has the privileges. You tell it your name is "Robert" and it runs a check to see if you're in the database. An SQL injection works via what being sent isn't clean (ala http://xkcd.com/327/), instead of having limits to what you can send the server (your name and password) you can create a SQL query that returns whatever you want (such as the entire database of users, password hashes, etc).

You say "its just privileges escalation", but that doesn't make any sense, you don't ever have access to the server directly nor connection to any other database, you can't craft a SQL string to give you access to everything that's potentially connected to that server.

This is probably the biggest issue with password hacking - limiting the hacker so they don't get the password dump in the first place.

Unfortunately, too many devs (especially today) use the easy-to-use dev tools to connect a DB server to a client (or webserver) so they can interrogate the tables quickly and easily. That means if a hackers gets access to your webserver, they too can quickly and easily interrogate the tables too. The answer is partly to slap as much security on it as possible, but more to hide the DB away behind an application tier on a different box and not have any connection between the web and the DB tiers - no physical connection is best. So a hacker who gained access to your webserver would then have to hack the application tier too, and I expect that would be limited access API that, in turn, only had limited access to the database via an API comprised of secured stored procedures.

Then the only practical way for the hacker to get your passwords would be to work at the company hosting the DB server.

In many ways think of it like this: Imagine you stored your passwords in the DB in plain text. What steps would you then take to ensure their safety? This makes you think what else is needed, as articles like this show - even an encrypted password hash is not that much different from plain text by today's standards anyway.

This is why I think it's still best to use a password manager to generate fully random passwords; they should theoretically have as much entropy as the hash does, and it should be safe to then use a nice big password to protect the password manager itself, provided you're careful about where you keep it.

The main issue is when you rely on a password manager and you need to keep it somewhere safe; it's tempting to put it into a cloud service where you can always get it, but then you need a non-random password for the cloud service (or you can't access it). It's probably not such a big issue since you'd still have the benefit of having two passwords protecting the password manager (one for the cloud service, one for the manager itself, unless you foolishly use the same password). And it's still only two passwords that you need to choose carefully and remember.

That's for personal practice however; the best solution to offline attacks for a website, assuming that preventing your hashes being stolen isn't guaranteed to work, is to store passwords in a mechanism disassociated from the original account.

Basically something like:

User table stores a user's e-mail and/or username, plus the two different salt values to be used when hashing the password.

Password table stores password hash generated using the first salt (for lookup) plus the user ID encrypted using a second hash generated using the second salt-value.

When a user signs in their password is hashed with the first salt to lookup possible password fields (though it's unlikely there'd be more than one match, even so). It is also hashed with the second salt to decrypt the user ID; if it's a match then the password was valid, if not it was the wrong password field, or the password is incorrect.

It's actually fairly simple, but the point is that if someone steals the database then there is no direct connection between the passwords and the user accounts; you need to guess both a password and a salt in order to decrypt a record to get a useful user ID out of it.The first salt can also safely use a faster hashing algorithm, while the second should definitely use a slow one, since it's only used for lookups in one-direction; grabbing a user's first salt and guessing passwords won't guarantee you'll match the correct record, and you could potentially match multiple records with every guess, which then need to be checked against the second field. I'd still probably use a relatively slow algorithm anyway though, just because I'm like that. Or you could use an intentionally low-entropy hashing scheme for lookups, so that every login attempt will match multiple records, but this may introduce an unacceptable login delay.The only real issue is that you need to somehow expire unused passwords; this is easy enough if the user is updating their password as you can just use the old password to look-up the old entry for deletion, however you may also want passwords to expire after a period of inactivity (forcing the user to generate a new one with an appropriate forgot password system). But you could do this with a boolean flag, set to true when the password is used, and set to false at the start of each month; any records set to false already are deleted. You can also update both salts when the user changes their password, so the old password entry can never be re-used.

But eh… considering we have had major companies still storing plaintext passwords I dunno how long it would be till such a system could be rolled out on a large scale.

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!

Some government websites still limit you to 6 characters, and you can't even use symbols, just letters and numbers.

Depending on other security measures, that might not be a problem. It depends what the password allows you to access.

My bank only allows 6 *digits* for internet banking, but it's perfectly secure because a few failed guesses will instantly shut down internet banking for my account. If their servers are hacked, I don't give a shit about my password being lost - the hacker will have stolen all the bank's money instead.

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.

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.

Came here to upvote this one. I was put off by the use of fingerprints at Universal and Disney World when my family went there on vacation this year. You can't change your fingerprint and now I've given it to Disney and Universal. No idea who they are saving it for or if they are saving it. Can you trust them if they say no after hearing about the NSA's activities. Could Disney be helping to gather fingerprints on everyone in the country? Certainly wouldn't put it past our government. Problem is, now that I am in "The System" (tm), I can't get out, or change the very thing that identifies me. Biometrics is scary stupid to use as a password/identification mechanism. Besides it leads to more crime: