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

Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances

stacksmashing.net

Post reply on HN
Print view View original

31–40 of 90 posts

Re: Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances

#31

Post by yafujifide »

davidu wrote: post #9
umjames wrote: post #2

OK, I'll bite (and show my ignorance regarding security). What should we use in place of SHA1?

At the very least, add a random salt added to each plaintext before you run it through the SHA1. This will at least defeat rainbow attacks fairly well. That said, you need to do more and move beyond SHA1 since you can now reverse a SHA1 into plaintext with the computing power EC2 gives you.

> That said, you need to do more and move beyond SHA1 since you can now reverse a SHA1 into plaintext with the computing power EC2 gives you.

But this only works for small numbers of characters. You cannot inverse-hash a book length document. You also still can't inverse-hash a 16 character or probably even 12 character password.

This fast hashing stuff is only a problem because people use ridiculously short passwords. The examples in the article are a lazy, pathetic 6 characters. I think people vastly underestimate their ability to memorize passwords. For instance, I am able to memorize a 16 character password by just writing it down a few times and then testing myself. And since I can remember many such passwords, I could easily memorize 32 character passwords, which are probably impossible to crack for the next 50 years or so. And you really only need to remember one such password, because all your other passwords can be put in an encrypted file.

Re: Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances

#32

Post by grandalf »

zoomzoom wrote: post #29

If this becomes a serious issue, my bet is that the government will be forced to start monitoring or background-checking GPU cluster use. This is one case where the cloud will hurt privacy, because Amazon will not risk their empire to protect criminals. Distributed computers cannot be subpoenaed so easily.

Not sure about this, but I could definitely see "export restrictions" on the service... though what's to stop a foreign company from building the same type of service.

Re: Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances

#33

Post by yafujifide »

Allow me to be the first one to argue that we should require that users use longer passwords. This is not much of a burden. Your password will last for a very long time, and it takes only a few minutes to memorize a long password.

If computing power doubles every 2 years, then every two years we should bump up the required password length to match. If each character is randomly chosen from amongst 2^6=64 possibilities, then every 6 years we add 1 to the number of characters required.

For instance, if today we require 12 character passwords, which are clearly uncrackable even with Amazon's fancy new GPU instances, then in 2016 we require everyone update their password to a minimum of 13 characters. Every six years we bump it up again.

I think people vastly underestimate their ability to memorize passwords (just think how many phone numbers you probably had memorized back in the day). You could probably memorize passwords thousands of characters long if you bothered, and the only problem is that it would take too long to type them in.

You only need one long password, and all others can be stored in an encrypted file. This is not much to ask.

Bcrypt and scrypt look great, but not fundamentally any better than longer passwords.

Re: Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances

#34

Post by sedachv »

Rantenki wrote: post #7

First of all, only the initial release day, and the EC2 GPU killer app has been discovered. Second, store passwords as a salted hmac, not just a shaXsum. It is still usually a singel command, and WAY more secure than simple shaX or mdX, as it eliminates the risk of prefix/postfix attacks. Adding the salt makes dictionaries pretty irrelevant (as long as each install has a unique salt). I mean GEEZ; even php does it no…

This is something I've been wondering about - how can you use pre/postfix attacks on passwords? I can't see any obvious ways it would help, and googling hasn't produced any information.

Re: Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances

#35

Post by davidu »

daeken wrote: post #16
davidu wrote: post #9

Earlier quoted context omitted.

At the very least, add a random salt added to each plaintext before you run it through the SHA1. This will at least defeat rainbow attacks fairly well. That said, you need to do more and move beyond SHA1 since you can now reverse a SHA1 into plaintext with the computing power EC2 gives you.

It should be pointed out that it's impossible to "reverse a SHA1 into plaintext". The reason being that, since SHA1 produces a fixed size output and takes a variable (unbounded) input, there are an infinite number of input values for every unique output value. You may find a string that happens to come to the same SHA1, but there's no way to know whether or not it's actually what went into the SHA1 algorithm in the f…

Actually, you can reverse a SHA1 into plaintext. That's exactly what we're talking about.

Can you know it was the same plaintext that went in? No, but as far as the SHA1 output is concerned, it's a suitable input and a suitable reverse.

For the application we're discussing, the fact that collisions can be engineered is sufficient to generate a reverse of the hash. At no point do you need to generate the original input in order to reverse it for this application.

Re: Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances

#36

Post by davidu »

samd wrote: post #18
daeken wrote: post #16

Earlier quoted context omitted.

It should be pointed out that it's impossible to "reverse a SHA1 into plaintext". The reason being that, since SHA1 produces a fixed size output and takes a variable (unbounded) input, there are an infinite number of input values for every unique output value. You may find a string that happens to come to the same SHA1, but there's no way to know whether or not it's actually what went into the SHA1 algorithm in the f…

But that's ok, the server doesn't know what originally went into the algorithm either.

Bingo.

Re: Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances

#37

Post by davidu »

pyre wrote: post #25
davidu wrote: post #9

Earlier quoted context omitted.

At the very least, add a random salt added to each plaintext before you run it through the SHA1. This will at least defeat rainbow attacks fairly well. That said, you need to do more and move beyond SHA1 since you can now reverse a SHA1 into plaintext with the computing power EC2 gives you.

> you can now reverse a SHA1 into plaintext I thought that all hash algorithms were lossy. Would I be able to reverse a SHA-1 of a git commit back into the contents of the git commit with enough computing power?

The term "reverse" is not the right word to use. What is meant is that you can generate another input for which the SHA1 output matches your other SHA1 output. This is because SHA1 has collisions.

So "foo" could hash to 1 and "bar" could hash to 1 also. It doesn't mean 1 means foo, but it means if your password is foo, bar works too when hashed and compared against a stored hash.

Re: Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances

#38

Post by c1sc0 »

grandalf wrote: post #32
zoomzoom wrote: post #29

If this becomes a serious issue, my bet is that the government will be forced to start monitoring or background-checking GPU cluster use. This is one case where the cloud will hurt privacy, because Amazon will not risk their empire to protect criminals. Distributed computers cannot be subpoenaed so easily.

Not sure about this, but I could definitely see "export restrictions" on the service... though what's to stop a foreign company from building the same type of service.

export restrictions easily circumvented by getting a US credit card, just like you need one for Amazon Mechanical Turk

Re: Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances

#39

Post by alextgordon »

yafujifide wrote: post #33

Allow me to be the first one to argue that we should require that users use longer passwords. This is not much of a burden. Your password will last for a very long time, and it takes only a few minutes to memorize a long password. If computing power doubles every 2 years, then every two years we should bump up the required password length to match. If each character is randomly chosen from amongst 2^6=64 possibilitie…

We can't even get people to dump IE6. How the hell are we going to get them to use longer passwords, and change them every year?

Scrypt is better than longer passwords because it's actually possible to implement in practice.

Re: Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances

#40

Post by mchouza »

davidu wrote: post #37
pyre wrote: post #25

Earlier quoted context omitted.

> you can now reverse a SHA1 into plaintext I thought that all hash algorithms were lossy. Would I be able to reverse a SHA-1 of a git commit back into the contents of the git commit with enough computing power?

The term "reverse" is not the right word to use. What is meant is that you can generate another input for which the SHA1 output matches your other SHA1 output. This is because SHA1 has collisions. So "foo" could hash to 1 and "bar" could hash to 1 also. It doesn't mean 1 means foo, but it means if your password is foo, bar works too when hashed and compared against a stored hash.

If the original input is not very short, it's extremely unlikely that an input with the same SHA-1 hash could be found. These attacks work because the passwords are weak and SHA-1 is fast to compute, not due to any weakness of SHA-1 as a cryptographic hash function.
Post reply on HN