Hacker News Reader

Comment by umjames | Hacker News Reader

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

In short, for passwords, never use a hash function. Hash functions are made to be fast. If you absolutely must use a hash function, iterate it a few thousand times.

Ideally, use http://www.tarsnap.com/scrypt.html (made to be computationally annoying to brute force).

made to be computationally annoying to brute force

I think the word "annoying" here wins you the understatement-of-the-day award.

I've used bcrypt [http://bcrypt-ruby.rubyforge.org/] in the past. Automatically handles a salt, and you can "tune" the number of iterations, so you can pick the cost. You can make it so the hash function takes 300ms on fast hardware, which limits the rate that an attacker can brute-force your database.

Edit: Wrote up this comment before the one about scrypt. It also looks nice, but it looks like there's no or only primitive language bindings available.

You're just fine with bcrypt. scrypt is almost certainly better, but even iterating SHA1 repeatedly is still acceptable. What isn't acceptable is using a naked hash function (or a naked hash with a "salt").

Really? All I've been doing is just picking 8 random characters as a "salt", sticking it to the password, and SHA-1 it, and you're saying its not secure? Uh oh.

The good news is, there are libraries for bcrypt for most every major language out there, and they are extremely simple to use. Some languages also have scrypt libraries, which is even better. Either will be a huge improvement over plain salted SHA-1.

"Why Not {MD5, SHA1, SHA256, SHA512, SHA-3, etc}?

These are all general purpose hash functions, designed to calculate a digest of huge amounts of data in as short a time as possible."

See the rest here: http://codahale.com/how-to-safely-store-a-password/

designed to calculate a digest of huge amounts of data in as short a time as possible.

That's a weakness, not a strength. If you can only calculate 100 hashes per second, it will take a lot longer to crack a password than if you can calculate 100 000 hashes per second.

That's the point of that article, use bcrypt because it's slow.

Misinterpreted the parent post. Thanks for the correction.

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

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.

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

Bingo.

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.

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.

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

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

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

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

Adding a few cracks and glue doesn't make it a different plate...

SHA-2 would be a good choice. The algorithm is based on SHA-1, but avoids the same vulnerabilites found in the SHA-1 algorithm.

http://en.wikipedia.org/wiki/SHA-2

SHA-1's vulnerabilities are entirely irrelevant to its unsuitability as a KDF, making SHA-2 no more suitable. As others have recommended, use scrypt or PBKDF2.

Thanks for this. :) Learn something new every day.

Reply on news.ycombinator.com