How crackers ransack passwords like “qeadzcwrsfxv1331” • Hacker News Board

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#121

Post by qu4z-2 » Thu, May 30, 2013, 2:52 AM UTC

simias wrote: post #49

kenbot wrote: post #29

Earlier quoted context omitted.

Try looking at the pattern the letters form on the keyboard...

Good catch, but it could also simply be that the password had been collected during a previous hack. The article mentions it at the end but I think they should have insisted more on this point: if you have a very strong password that you reuse everywhere and it gets leaked at some point it has a high probability to end up in rainbow tables everywhere and might not be more secure than "h4x0r1234". So using hard to gue…

Could you explain the rainbow tables comment?

I would've thought it'd end up in a dictionary, not a rainbow table. (although I have to admit I've forgotten the details of how rainbow tables work)

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#122

Post by yashg » Thu, May 30, 2013, 5:33 AM UTC

spiffytech wrote: post #119

yashg wrote: post #117

How about this - User's password is a single letter "a". I MD5 it and get a 32 char string, now I append a GUID as salt - another 32 chars - and I MD5 that 64 char string again and store it. How difficult would it be to crack it? If the cracker knew my process he might crack it, but what if the process is not known to a cracker? Also I can store the hashed string and the salt in a way that a crakcer merely by looking…

Well, you're hashing and salting, which is at least a good start. But you shouldn't use MD5- if the cracker does find your secret formula, you're hosed compared to pbdfk2/bcrypt/scrypt. Not only for the speed, but because MD5 has exploits that make it easier to produce a specific desired hash than the other options, so your attacker doesn't have to make as many guesses. You should use a per-user salt, though, instead…

Yes of course I meant per user salt. And if I store a 64 char string it will be very difficult for an attacker to figure out MD5 was used.

And since the string that I MD5ed is 64 chars in length (32 of original MD5 + 32 of salt) it should make it near impossible to crack.

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#123

Post by spiffytech » Thu, Jun 06, 2013, 4:09 PM UTC

yashg wrote: post #122

spiffytech wrote: post #119

Earlier quoted context omitted.

Well, you're hashing and salting, which is at least a good start. But you shouldn't use MD5- if the cracker does find your secret formula, you're hosed compared to pbdfk2/bcrypt/scrypt. Not only for the speed, but because MD5 has exploits that make it easier to produce a specific desired hash than the other options, so your attacker doesn't have to make as many guesses. You should use a per-user salt, though, instead…

Yes of course I meant per user salt. And if I store a 64 char string it will be very difficult for an attacker to figure out MD5 was used. And since the string that I MD5ed is 64 chars in length (32 of original MD5 + 32 of salt) it should make it near impossible to crack.

Relying on a terrible hashing mechanism just because you hope nobody will realize you're using it is a very bad idea. There's no technical reason to use MD5 over at least looping over a good SHA variant, and if your code has access to bcrypt/scrypt, it's hard to come up with a reason to choose anything (except maybe pbkdf2) over them, either.

Further, a string that long might be effectively impossible to crack /by brute force/, but MD5 has been found to have flaws that allow the attacker to find alternate inputs that will produce the same hash in a very short amount of time (minutes to hours, according to Wikipedia[0]). That means if the attacker has your hash, they don't need to figure out your nonce or salt to come up with something they can use to trick your system into authenticating them as an arbitrary user. These attacks don't reveal the user's original password, but they do still allow someone to impersonate an arbitrary user on your site, for e.g., purchasing services, accessing financial details from your billing system, or performing social engineering attacks.

[0] http://en.wikipedia.org/wiki/Md5#Security