4

When my clients create a password, they are shown a strength meter and I have set the requirements fairly high. However, the strength meter is essentially only useful if being attacked by a very dumb brute force cracker. I know for a fact that passwords can be created that are easier to crack with software like John the Ripper. For example, it's easy enough to make sure people aren't creating passwords like "password1", but I need to catch common non-dictionary terms like "NCC-1701-D" (the registry number for Star Trek Enterprise) and other stuff that crackers commonly check for ("qwerty, "asdf", etc). It is my understanding that cracking programs get better as they have access to more cracked passwords (thanks LinkedIn, Evernote, LivingSocial...) because the cracker is able to start with the most common passwords, and even search for common "word fragments" within passwords and add them to the dictionary...

So how can I get access to some of these advanced configurations of John the Ripper--I know the program itself is free to install, but how do I get these advanced constructed dictionaries? Also, what are the security implications of hacking my own accounts? I can't think of how this could really be problematic--unless I store the cracked passwords plaintext or something. Am I missing some obvious problems that this would introduce?

EDIT: I am thinking of generating my own rainbow table for my salt* and then uploading the list of hashes. Then if a user's salted hash matches one from the rainbow table, they're forced to create a new password upon their next login (or even better, it's checked against the rainbow table when they first create it and it gets rejected if there is a match, though I'm not sure if this might be computationally too expensive.)

*D'oh! As pointed out below, that's not how salting works. Is there a feasible way to check passwords against a "password blacklist" without exposing the password in the process?

brentonstrine
  • 1,259
  • 2
  • 10
  • 13
  • Clients are notified that their passwords will be audited when they create them. It is also in our terms of service which they must agree to to create an account. –  Apr 28 '13 at 21:22
  • I suggest that anyone who is likely to use "NCC-1701-D" as a password is more likely to know how bad it is to use common passwords like that. – Andy Lester Apr 29 '13 at 01:32
  • 1
    http://crackstation.net/buy-crackstation-wordlist-password-cracking-dictionary.htm The list contains every wordlist, dictionary, and password database leak as well as It also includes the passwords from some low-profile database breaches that were being sold in the underground years ago. – NULLZ Apr 29 '13 at 02:43

1 Answers1

9

Don't bother! Instead of preoccupying yourself with how secure your user passwords are, may I suggest you instead make sure they're as secure as they can be once they chose any of sufficient minimum length and complexity?

I am thinking of generating my own rainbow table for my salt and then uploading the list of hashes.

You've just revealed you're not even salting passwords in any effective way. One single non-unique salt value should not be used on more than one password hash! Full stop. Needless to say, what you wrote clearly indicates you're using one single database-wide padding in a place where salt should be. Instead of calculating how difficult it would be to attack password hashes with a tool like John The Ripper (JtR), you should rather make these types of attacks nigh impossible on any passwords used that match a minimum required length and/or complexity.

I shall now refer you to this answer: How to securely hash passwords?. No need of me to write it all again then, I believe. Read it, understand it, worship its author, for once you implement the wisdom it holds, you shall sleep with a rested mind and never think of JtR again!

Community
  • 1
TildalWave
  • 10,801
  • 11
  • 45
  • 84
  • Ah, right, I forgot that that's how it works with salt. I actually haven't put any of this into effect yet (it just seemed simpler to use present tense). I'm still in the planning phase, and I know enough not to try to invent my own password encryption system--so the salt will indeed be unique to each password. I do agree with you that I need to worry about keeping the system secure, but that being said, I do think it's worth it to put a little effort into making sure the passwords themselves are secure as well, so my question still stands. – brentonstrine Apr 29 '13 at 04:01
  • @brentonstrine - I'm not sure it does actually. The whole point is to make tools like JtR pretty much pointless, so what you'd be more likely after is checking the acceptable password complexity on entry (clear password), not once it's already hashed. If you salt and hash passwords properly (and maybe store salt separate from hashes), you shouldn't be able to brute-force them (how would you know what output is the password used?) or calculate a rainbow tables for them (what salt to use?). Use slow hashing functions, and you won't even be able to do either on a single hash in your lifetime. – TildalWave Apr 29 '13 at 16:19