Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

This question already has an answer here:

Suggestions to make a good password all focus on creating a string that a computer (or more likely, a network of computers with multiple GPUs) can not guess. Putting a password meter for when users create passwords can help against this a little, e.g. by enforcing a password at least 8 characters long with a mix of cases, letters, numbers, and symbols. But password meters and rules can't protect against the following passwords, which all look pretty good:

qeadzcwrsfxv1331
Coneyisland9/
n3xtb1gth1ng,
Oscar+emmy2.
":LOL1313le
Sh1a-labe0uf,
DG091101%

All of these passwords were cracked quickly for this article on Ars Technica. It seems impossible to compete with the complexity, creativity, speed, and comprehensiveness of cracking algorithms.

So here is my question. If, in theory, a few hundred crackers used their hardware and cracking programs to generate a massive list of all of their guesses--and they continued adding to it, so that the list would include any new guesses likely to be folded into cracking programs (e.g. say another site gets hacked, all the leaked passwords would go into the blacklist), would this be feasibly useful as a secure password generation tool? Or would it be easily circumventable or does it have some massive problem I'm not seeing?

Since this massive blacklist would probably have to be crowdsourced, and therefore available to crackers, and potentially even something that crackers could add to, are there ways it could be used to a cracker's advantage? Or would using this list make their job harder no matter what?

Any other reasons why it wouldn't be useful?

share|improve this question

marked as duplicate by TildalWave, NULLZ, Xander, Scott Pack, Adnan Jul 17 '13 at 9:36

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

    
Known as a dictionary? –  Fiasco Labs Jul 16 '13 at 23:48
    
I'm annoyed that this was marked as a duplicate. I disagree. /gripe –  brentonstrine Jul 17 '13 at 18:24

2 Answers 2

Those passwords are based on offline attack -- that is, the attacker has the hash and is trying to crack it. If that's your concern, use something like scrypt, bcrypt, or PBKDF2 to harden your password hashes and make them harder to attack offline.

If you're concerned about online attack, just limit the rate of account logins with some sort of exponential backoff, or block the IP after some number of bad login attempts. Either way, you'll make the online attack so slow that the attacker won't get past 'p4ssw0rd'.

share|improve this answer
    
1. hash table never gets out, 2. computationally expensive hash, 3.property salted. Easy, right? So why do so many websites fail to do this? I've been practically crusading against Mint.com just to get them to tell me whether they do this. So I think this might be useful for people who don't know what the security on a site they use is. I also sometimes use closed-source software where I can control what passwords the users create, but can't control how they're stored. –  brentonstrine Jul 17 '13 at 18:19

There are 3 different kinds of brute-force attacks:

  1. common dictionary attack: Say to 100 most common passwords. Or top 30000, or whatever. Typically a shallow attack run against a large set of targets looking to pick off the weak ones.

  2. exhaustive dictionary attack: With varying degrees of exhaustiveness. All common passwords, all dictionary words and keyboard patterns, replace letters with numbers, append numbers and symbols, insert symbols... etc. Typically a very targeted attack.

  3. Full exhaustive attack: Start at 0x00 and work your way up. 100% success rate if you keep at it long enough. Very targeted, not particularly practical.

So the question is, which dictionary are you guarding against? A simple solution is to just check to make sure your password isn't in the corresponding attack dictionary.

Checking for 1 is something that's already done on more advanced systems such as Linux. But unfortunately, the password list for 2 could be many gigabytes or terabytes long. It's generated on-the-fly when used, so checking against it would have to be at least partially programmatic, rather than a straight lookup. As long as you're using roughly the same list for defense that is commonly used for offense, you should catch all the easy ones. 3 is of course impossible to defend against except to create very long passwords. Which you should do. By today's standards, 12 to 16 characters minimum depending on the selection of possible characters you use (uppercase, numbers, symbols, etc)

share|improve this answer
    
I'm not primarily thinking of brute force attacks at all. The first password example I gave, qeadzcwrsfxv1331, wouldn't be caught by any dictionary that I know of. If you read the article I linked to you will understand what I mean. I'm thinking about what happens if a hash-table gets loose and people start running Jack the Ripper or other custom cracking programs on it. –  brentonstrine Jul 17 '13 at 18:14
1  
@brentonstrine John the Ripper typically uses option 2. It's a permutation engine that starts with some base rules and words and generates a stream of candidate passwords. It would be impractical to store the resultant dictionary for hash lookup because of the size. Instead, you could analyze the provided password in software to see if it could be generated by the tool's rules. This is simpler than it sounds. –  tylerl Jul 17 '13 at 18:30

Not the answer you're looking for? Browse other questions tagged or ask your own question.