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

11–20 of 123 posts

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#11

Post by eksith »

grecy wrote: post #5
jacques_chester wrote: post #2

The punchline: > The list contained 16,449 passwords converted into hashes using the MD5 cryptographic hash function. Edit: I'm removing all my snarky nitpicking. This is a good article. Yes, the MD5 case they present is a poor case, but it's really about demonstrating the tactics of attack selection, rather than teaching someone how to make crack-resistant password schemes.

> the MD5 case they present is a poor case If guys using vanilla hardware get that kind of success in 1 hour with MD5, you only need to increase hardware and the time required to see it's still completely doable for other hash functions.

The issue is practicality. Which is why pbkdf2 (and increasing the rounds each year) + bcrypt or scrypt is still a better option.

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#12

Post by nknighthb »

grecy wrote: post #5
jacques_chester wrote: post #2

The punchline: > The list contained 16,449 passwords converted into hashes using the MD5 cryptographic hash function. Edit: I'm removing all my snarky nitpicking. This is a good article. Yes, the MD5 case they present is a poor case, but it's really about demonstrating the tactics of attack selection, rather than teaching someone how to make crack-resistant password schemes.

> the MD5 case they present is a poor case If guys using vanilla hardware get that kind of success in 1 hour with MD5, you only need to increase hardware and the time required to see it's still completely doable for other hash functions.

Which is why passwords just shouldn't be stored with simple hash functions. Even a naïve salt+iteration method would have drastically slowed the attack.

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#13

Post by arjie »

chm wrote: post #8
tomku wrote: post #6

Earlier quoted context omitted.

Right next to the hashed passwords. The point of salting isn't to add an additional level of secrecy, it's just to prevent the reuse of hashing work for attacking other users.

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.

Without salts: Generate table of hashes vs. Plaintext for all plaintext up to certain length. Maybe use rainbow tables. Now, for each entry use this table. Time to get plaintext of n hashes is constant.

With salt: Generate table of hashes vs. Plaintext by appending salt to each possible plaintext of given length. For first entry use first salt to generate this table. Table is now useless for second salt if it is different. Time to attack n hashes scales linearly.

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#14

Post by baddox »

chm wrote: post #8
tomku wrote: post #6

Earlier quoted context omitted.

Right next to the hashed passwords. The point of salting isn't to add an additional level of secrecy, it's just to prevent the reuse of hashing work for attacking other users.

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 salts provide their primary benefit (rendering rainbow tables useless) even when the attacker possesses the salts and the hashed passwords.

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#15

Post by lbarrow »

tomku wrote: post #3

Enjoyable read, but I question the bit near the end claiming that salts wouldn't help much against this kind of attack. From my understanding, per-user salting does substantially slow down this kind of attack because it forces you to calculate a different hash for each user/plaintext combination rather than hashing a suspected plaintext once and comparing the hash against the whole list. What it doesn't slow down is…

The article clearly explained that using more salts was preferable to using a global salt and did a good job of explaining why. They didn't come out and say that a per-user salt is best, but that's the natural conclusion of the argument they developed.

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#16

Post by ams6110 »

chm wrote: post #8
tomku wrote: post #6

Earlier quoted context omitted.

Right next to the hashed passwords. The point of salting isn't to add an additional level of secrecy, it's just to prevent the reuse of hashing work for attacking other users.

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 with fast message-digest algorithms like MD5 or SHA.

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#17

Post by theboss »

chm wrote: post #4
tomku wrote: post #3

Enjoyable read, but I question the bit near the end claiming that salts wouldn't help much against this kind of attack. From my understanding, per-user salting does substantially slow down this kind of attack because it forces you to calculate a different hash for each user/plaintext combination rather than hashing a suspected plaintext once and comparing the hash against the whole list. What it doesn't slow down is…

Where/how do you store the salts?

Salting would definitely make a difference. The point of salting is to increase the complexity and overhead of generating rainbow tables.

The first mistake here is the use of MD5. MD5 is flat out broken. Do Not use md5. Do use bcrypt.

In your db, you can store the salt right there....next to the hash...

How a salt increases the complexity is quite simple. If a attack has a giant rainbow table, the salt causes him to increase the size of his rainbow table and the space required to hold it and the pre-processing time to generate it. For example

Here is what your database might look like with a 3 byte salt

password : salt

hunter2 : 100

qwerty1 : 101

Here is what the attacks rainbow tables will have to look like

qwerty1 : 101

hunter2 : 100

qwerty1 : 100

hunter2 : 101

hunter2 : 103

qwerty1 : 102

...

..

.

That's about it. There are other purposes of the salt too but other people talked about those ones.

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#18

Post by jacques_chester »

nknighthb wrote: post #12
grecy wrote: post #5

Earlier quoted context omitted.

> the MD5 case they present is a poor case If guys using vanilla hardware get that kind of success in 1 hour with MD5, you only need to increase hardware and the time required to see it's still completely doable for other hash functions.

Which is why passwords just shouldn't be stored with simple hash functions. Even a naïve salt+iteration method would have drastically slowed the attack.

Right.

Using MD5 hashes was done as a relaxing constraint -- at the other end, the attackers had tightened constraints by getting limited time and computing power.

The goal was to show how attackers work and think.

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#19

Post by tomku »

chm wrote: post #8
tomku wrote: post #6

Earlier quoted context omitted.

Right next to the hashed passwords. The point of salting isn't to add an additional level of secrecy, it's just to prevent the reuse of hashing work for attacking other users.

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.

Absolutely not. Like I said, the point of the salt is not to provide a "second password" that needs to be independently stolen. It's to make the results from a cracking attempt on one account useless on the password of another.

If you've read the article, you have a pretty good idea of how it works without salting. You have a list of N password hashes, and you come up with candidate passwords. You run each candidate password through the hash function, and compare the resulting hash to your list. If it matches any of them, you've got the plaintext for those user accounts. The key thing here is that you only have to hash each candidate password once, and you can compare that hash to as many accounts as you'd like.

Now, let's add in a salt. It's stored next to the password, so after stealing the password db you've got a list of password hashes, each with its own salt. In order to check a candidate password against a particular user account, you have to append that user account's salt to the candidate, then hash it and compare against the stored hash. That part isn't any slower. The problem is when you try to take that hash and compare it to other accounts. Even if two users have the same plaintext password, their password hashes will be different because they have different salts. The end result is that you have to hash each candidate password fresh for every user.

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#20

Post by [deleted] »

chm wrote: post #8
tomku wrote: post #6

Earlier quoted context omitted.

Right next to the hashed passwords. The point of salting isn't to add an additional level of secrecy, it's just to prevent the reuse of hashing work for attacking other users.

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.

[deleted]
Post reply on HN