Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How crackers ransack passwords like “qeadzcwrsfxv1331”

arstechnica.com

Post reply on HN
Print view View original

111–120 of 123 posts

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#111

Post by traplens »

aidenn0 wrote: post #105
Corrado wrote: post #53

My big takeaway from this article is that passwords, in almost any form, are a bad way to secure your information. The only acceptable way to use a password nowadays is to use a password manager to build huge passwords that a human could never remember or type in reliably. Even then, as machines get faster and crackers get smarter, these behemoth passwords will fall. I've been using 2-factor authentication (Google Au…

Even then, as machines get faster and crackers get smarter, these behemoth passwords will fall. This is fairly trivial to show is false. A 256-bit password that can be checked at one clock-cycle per iteration with 1 million cores running at 30GHz will take 1.2e53 years to crack[1]. If you generate it by base-64 encoding a random 256-bit string you will end up with only a 12 character password (hardly a "behemoth"). […

One note here - base-64 encoding a 256-bit string would result in a 44 character password (43 without padding).

It would be pretty cool if a 12 character password gave you 256 bits of entropy though :)

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#112

Post by aidenn0 »

traplens wrote: post #111
aidenn0 wrote: post #105

Earlier quoted context omitted.

Even then, as machines get faster and crackers get smarter, these behemoth passwords will fall. This is fairly trivial to show is false. A 256-bit password that can be checked at one clock-cycle per iteration with 1 million cores running at 30GHz will take 1.2e53 years to crack[1]. If you generate it by base-64 encoding a random 256-bit string you will end up with only a 12 character password (hardly a "behemoth"). […

One note here - base-64 encoding a 256-bit string would result in a 44 character password (43 without padding). It would be pretty cool if a 12 character password gave you 256 bits of entropy though :)

You're right; I did 256/8 in my head and got the obviously wrong result of 8 rather than 32.

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#113

Post by smackfu »

skavander wrote: post #62
reeses wrote: post #47

Earlier quoted context omitted.

Salting wouldn't have changed the outcome of the cracking attempts in the article. The primary focus was on how pre-computed hashes (rainbow tables, etc.) are no longer a tool used by most people attacking password lists because GPU-based hashers are efficient enough, the dicts long enough, and the methods of permuting the dicts (combinations, leet substitutions, markov chains, etc.) are rich enough that storing all…

Every time figure quoted in the article (eg "Retrieved 2700 passwords in 2 minutes 30 seconds") would have been up to 16,000x larger if a salt had been used since a separate hash would need to be computed for each password rather than just one hash to compare to all 16,000 passwords. 2.5 minutes x 16,000 would be around 28 days to compute the "first pass" alone.. much less feasible, especially as the parts that took…

Or 2.8 days if you go out and buy 10 GPUs for a couple of grand. And practically, how often are people really trying to crack all the hashes?

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#114

Post by smackfu »

chiph wrote: post #77
_b8r0 wrote: post #55

Earlier quoted context omitted.

I'm in the middle of researching re-evaluating rainbow table attacks in light of Moore's law, GPUs and Crack (lookup) tables, I've also looked into countermeasures. What you're describing is partially correct. When you crack passwords (either with rainbow tables or by brute force) you generate an iterator or use a dictionary and work through this generating hashes (with rainbow tables this works via a series (or chai…

If you're targeting a single hash I was going to mention this. If your user record has a column called "IsSuperuser", then an attacker is going to concentrate on those users, since the reward for cracking them is so much higher. Individual salts or not, with multi-GPU based brute-forcing, they won't stand long.

Or just do it based on usernames. It would be fairly easy to generate a list of high value usernames (reporters, admins, bloggers all tend to use consistent usernames), and then concentrate on those.

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#115

Post by markdown »

eropple wrote: post #110
danielweber wrote: post #97

Earlier quoted context omitted.

I know at least one major security company (that deals with Fortune 500 companies) is recommending having an extra key inside the app server, distinct from the database, since there are situations where someone can get the a copy of the DB and not your server. The fact that they're big doesn't mean they're right, of course. But I know I've seen a bunch of news stories about DB leaking and I haven't seem a bunch about…

For sure, and I've done similar myself in the past, but let's be real here--they actually have app/DB separation in those cases. They're definitely not running on Google App Engine, where it's much more likely that they're getting data through an exploit in your app than by getting ahold of the database. For the 99% case, 'pepper's are illusory security. And you should still be using bcrypt. (Or PKBDF2, or scrypt, wh…

> And you should still be using bcrypt. (Or PKBDF2, or scrypt, whatever. Just not something where a "pepper" actually ends up mattering.)

As I said, you can't use any of these on Google App Engine. They're not provided by the platform, and you can't upload them yourself because they use C.

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#116

Post by skavander »

smackfu wrote: post #113
skavander wrote: post #62

Earlier quoted context omitted.

Every time figure quoted in the article (eg "Retrieved 2700 passwords in 2 minutes 30 seconds") would have been up to 16,000x larger if a salt had been used since a separate hash would need to be computed for each password rather than just one hash to compare to all 16,000 passwords. 2.5 minutes x 16,000 would be around 28 days to compute the "first pass" alone.. much less feasible, especially as the parts that took…

Or 2.8 days if you go out and buy 10 GPUs for a couple of grand. And practically, how often are people really trying to crack all the hashes?

The point is that a salt would essentially give you a constant speed of cracking versus a speed that scaled with the size of the dataset you have. For example, the guy in the article cracked 10,000-ish passwords in 16 minutes - 600 passwords per minute. If he'd had a dataset of 1.6 million, he would have cracked over a million (assuming the passwords were of the same quality and he has some good way of storing them on his hardware to allow fast lookup), at a rate of 60,000 passwords per minute, all on his single GPU.

However, with a salt he'd be limited to about 1 password per every 27 minutes. And this rate would not increase as the dataset grew larger, which means that even if he had 10x the power as you suggest he could only crack about 20 passwords per hour (more or less). Thus to crack even 1% of a 1.6 million password dataset (16,000 passwords) it would take over a month of non-stop computation on 10 GPU's, versus a single GPU computing 62% (again over a million) in 16 minutes.

So even if a compromised website took a month to realize the leak, it would be able to inform it's users in time such that 99% of them would be able to change passwords and avoid their accounts being compromised in time. With no salt, no such luck since as we can see here up to 90% of the dataset would be cracked within a day.

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#117

Post by yashg »

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 at the string can't figure out it's actually salted.

Say my final salted hash is 1234 and the salt I used was ABCD. I can splice the two and store it as 1A2B3C4D. That would throw a cracker who does not know how the value was generated off the hook won't it?

Unless the crakcer also gets access to my code, it will be impossible for him to find head and tail of such hashes.

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#118

Post by eropple »

markdown wrote: post #115
eropple wrote: post #110

Earlier quoted context omitted.

For sure, and I've done similar myself in the past, but let's be real here--they actually have app/DB separation in those cases. They're definitely not running on Google App Engine, where it's much more likely that they're getting data through an exploit in your app than by getting ahold of the database. For the 99% case, 'pepper's are illusory security. And you should still be using bcrypt. (Or PKBDF2, or scrypt, wh…

> And you should still be using bcrypt. (Or PKBDF2, or scrypt, whatever. Just not something where a "pepper" actually ends up mattering.) As I said, you can't use any of these on Google App Engine. They're not provided by the platform, and you can't upload them yourself because they use C.

Right, so, like I said, don't use deficient platforms. Your users' security is more important than your ease of use.

And 'peppers' don't do anything of significant value in such an environment, either, because your app's going to get owned before your database is.

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#119

Post by spiffytech »

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 of a static salt (the 32-char nonce). The static nonce means the attacker can generate a rainbow table during their attack of all possible passwords. The hash of the password does not count as a suitable salt, because if User A uses the password 'a', and so does User B, both users' hashes come out the same. Finding User A's password means you can compare its hash against the rest of the compromised hashes and note that you grabbed User B at the same time. With a per-user salt, the users will have different hashes despite using the same password, so the attacker has to attack each hash separately, with no "quick wins". A randomly-generated salt will do, and I expect simply prepending the username or something to the password before hashing would do as well, singe it's still unique per user.

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#120

Post by qu4z-2 »

ams6110 wrote: post #16
chm wrote: post #8

Earlier quoted context omitted.

But doesn't this render the process useless? If an attacker gets access to the hashes, he also gets access to the salts. If both hashes and salts were isolated, I suppose it would be much more secure, although maybe too slow.

The point of the salt is to prevent precomputing the hashes (a rainbow table). Per-user salts take this a step farther, so that even if two users choose the same password, they will have different hashes. What the article really points out is what people have been saying for a while now, that if your passwords are exposed, salting really doesn't add more than a roadbump to a cracker if you are computing your hashes w…

I dunno... in the example there, I'd say that it costing 16000x as much to crack the passwords would be a little more than a "roadbump". (assuming people are renting {C,G}PUs in the cloud to perform the attacks)
Post reply on HN