11 ms·

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

• seiji 16y ago
  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 http://www.tarsnap.com/scrypt.html (made to be computationally annoying to brute force).
  • cperciva 16y ago
    made to be computationally annoying to brute force I think the word "annoying" here wins you the understatement-of-the-day award.
• swah 16y ago
  "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/ http://codahale.com/how-to-safely-store-a-password/
  • gloob 16y ago
    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.
    • guelo 16y ago
      That's the point of that article, use bcrypt because it's slow.
      • gloob 16y ago
        Misinterpreted the parent post. Thanks for the correction.
• abyssknight 16y ago
  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 http://en.wikipedia.org/wiki/SHA-2
  • dfranke 16y ago
    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.
    • abyssknight 16y ago
      Thanks for this. :) Learn something new every day.
• 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.
• psadauskas 16y ago
  I've used bcrypt [http://bcrypt-ruby.rubyforge.org/ 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.
  • tptacek 16y ago
    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").
    • meric 16y ago
      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.
      • pjscott 16y ago
        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.