4 ms·

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 s

by davidu 16y ago

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.

daeken 16y ago
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 first place.
- samd 16y ago
  But that's ok, the server doesn't know what originally went into the algorithm either.
  - davidu 16y ago
    Bingo.
- dedward 16y ago
  While completely true - it's not an obstacle in a simple implementation of password hashes. Any string that produces the same hash will suffice as a password - as the password is by definition anything that hashes to that value.
  - daeken 16y ago
    Yes, but you generally don't just care about recovering a password that happens to hash the same, so you can use it against a given service; if you've already managed to get hold of their hashed passwords, you usually have considerable control already. The non-recoverability of hashes comes into play when you consider that people reuse passwords on other sites, so if you could reverse all the password hashes for one site, it's conceivable that you could get into the users' accounts on another site. But if you're not recovering the original string, the chance of the password hashing the same way on another site is slim. Of course, so is the chance of a collision in the first place, making all of this purely theoretical in the end.
- davidu 16y ago
  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.
bl4k 16y ago
technically you aren't reversing it, you are calculating it through brute-force. best analogy for a hash is smashing a plate. you may be able to glue it back together but it is not the same plate btw I wonder how long before somebody calcs and loads a rainbow table onto AWS and charges for lookups. so tempted...
- fragmede 16y ago
  http://www.wpacracker.com/ http://www.wpacracker.com/ Runs a WPA cracker against your provided pcap files for $17- $40, depending on how fast and how extensive a word list you want to use. (Yes, I realize they aren't using rainbow tables, but WPA uses the SSID as salt, so that wouldn't be as usefu.)
- corin_ 16y ago
  Adding a few cracks and glue doesn't make it a different plate...
pyre 16y ago
> 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?
- davidu 16y ago
  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.
  - mchouza 16y ago
    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.
yafujifide 16y ago
> 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.

by davidu 16y ago

daeken 16y ago

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 first place.

samd 16y ago
But that's ok, the server doesn't know what originally went into the algorithm either.
- davidu 16y ago
  Bingo.
dedward 16y ago
While completely true - it's not an obstacle in a simple implementation of password hashes. Any string that produces the same hash will suffice as a password - as the password is by definition anything that hashes to that value.
- daeken 16y ago
  Yes, but you generally don't just care about recovering a password that happens to hash the same, so you can use it against a given service; if you've already managed to get hold of their hashed passwords, you usually have considerable control already. The non-recoverability of hashes comes into play when you consider that people reuse passwords on other sites, so if you could reverse all the password hashes for one site, it's conceivable that you could get into the users' accounts on another site. But if you're not recovering the original string, the chance of the password hashing the same way on another site is slim. Of course, so is the chance of a collision in the first place, making all of this purely theoretical in the end.
davidu 16y ago
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.

bl4k 16y ago

technically you aren't reversing it, you are calculating it through brute-force. best analogy for a hash is smashing a plate. you may be able to glue it back together but it is not the same plate btw I wonder how long before somebody calcs and loads a rainbow table onto AWS and charges for lookups. so tempted...

fragmede 16y ago
http://www.wpacracker.com/ http://www.wpacracker.com/ Runs a WPA cracker against your provided pcap files for $17- $40, depending on how fast and how extensive a word list you want to use. (Yes, I realize they aren't using rainbow tables, but WPA uses the SSID as salt, so that wouldn't be as usefu.)
corin_ 16y ago
Adding a few cracks and glue doesn't make it a different plate...

pyre 16y ago

> 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?

davidu 16y ago
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.
- mchouza 16y ago
  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.

yafujifide 16y ago

> 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.