1

I was researching about how MD5 is known to have collisions, So its not secure enough. I am looking for some hashing algorithm that even super computers will take time to break.So can you tell me what hashing algorithm will keep my passwords safe for like next coming 20 years of super computing advancement.

s.d
  • 255
  • 1
  • 14
  • 1
    "what hashing algorithm will keep my passwords safe for like next coming 20 years of super computing advancement." That's impossible to tell. Some people predict a technological singularity by 2030 (i.e. everything about computers that we'll be able to predict will instantly be wrong), and you're asking for a hashing algorithm that will hold up? :) Even if we give you a good algorithm, we don't know if a fatal flaw won't be discovered tomorrow. MD5+salt is really enough for 99% of use cases, and for the others, there's SHA-512. – Maciej Stachowski Sep 07 '13 at 21:59
  • 1
    The algorithm and the salt do different things - to suggest using sha-512 *without* a salt is a bit silly. MD5+salt is in some regards more secure than SHA-512 without. – symcbean Sep 07 '13 at 22:16
  • 2
    @Maciej I must disagree. MD5 just doesn't cut it anymore. Not that it was ever designed to be a password hashing function... – Nik Bougalis Sep 07 '13 at 23:06
  • I can't edit the comment - I meant SHA-512+salt. Thanks. @NikBougalis - from what I know, MD5 does a better job at password hashing than as a checksum/signature (due to chosen-prefix collision attacks). A preimage attack, which would be actually relevant in this case, is still unfeasible. The truth is, properly salted MD5 is still pretty much unbreakable, and any password-cracking attempt usually boils down to either brute-force or dictionary attack. – Maciej Stachowski Sep 07 '13 at 23:21
  • 1
    @Maciej even if brute force is the most efficient way to attack properly salted MD5 password hashes, MD5 is way, way too fast and, thus, unsuitable. There are proper password hashing functions and they should be used. – Nik Bougalis Sep 08 '13 at 04:41
  • 3
    If people will still use passwords like `password`, `123456`, and `12345678`, it doesn’t matter which algorithm you take to hash it. – Gumbo Sep 08 '13 at 05:14
  • @NikBougalis that's why *properly* salting the password is important. It effectively slows down the algorithm by the factor of about 64 per character. – Maciej Stachowski Sep 08 '13 at 12:30
  • 1
    @Maciej no, salting makes certain kinds of attack more difficult and/or impractical. The salt will protect you against precomputed dictionaries and rainbow table based attacks. It doesn't make the hashing itself faster or slower. – Nik Bougalis Sep 08 '13 at 14:40
  • That's if the salt is public, of course. I'm all for private salts, but that's another discussion :) Still, the most important thing in password security is not the hashing algorithm, but the password strength. Sure, MD5 might be 10 times faster to compute than SHA-256, but simply adding 1 more lowercase letter makes brute forcing 26 times slower. – Maciej Stachowski Sep 08 '13 at 15:08
  • scrypt is by far the strongest current password hash. If you don't want to use it, consider bcrypt or the even weaker PBKDF2. But with the kind of password a typical user chooses, no algorithm will keep them secure, even today. And with a really strong password, even a crappy password hash like SHA-256 will be secure. – CodesInChaos Sep 10 '13 at 08:10

3 Answers3

4

Use a key derivation function with a variable number of rounds, such as bcrypt.

The passwords you encrypt today, with a hashing difficulty that your own system can handle without slowing down, will always be vulnerable to the faster systems of 20 years in the future. But by increasing the number of rounds gradually over time you can increase the amount of work it takes to check a password in proportion with the increasing power of supercomputers. And you can apply more rounds to existing stored passwords without having to go back to the original password.

Will it hold up for another 20 years? Difficult to say: who knows what crazy quantum crypto and password-replacement schemes we might have by then? But it certainly worked for the last 10.

Note also that entities owning supercomputers and targeting particular accounts are easily going to have enough power to throw at it that you can never protect all of your passwords. The aim of password hashing is to mitigate the damage from a database leak, by limiting the speed at which normal attackers can recover passwords, so that as few accounts as possible have already been compromised by the time you've spotted the leak and issued a notice telling everyone to change their passwords. But there is no 100% solution.

bobince
  • 528,062
  • 107
  • 651
  • 834
1

As someone else said, what you're asking is practically impossible to answer. Who knows what breakthroughs will be made in processing power over the next twenty years? Or mathematics?

In addition you aren't telling us many other important factors, including against which threat models you aim to protect. For example, are you trying to defend against an attacker getting a hold of a hashed password database and doing offline brute-forcing? An attacker with custom ASICs trying to crack one specific password? Etc.

With that said, there are things you can do to be as secure and future-proof as possible.

First of all, don't just use vanilla cryptographic hash algorithms; they aren't designed with your application in mind. Indeed they are designed for other applications with different requirements. For one thing, they are fast because speed is an important criterion for a hash function. And that works against you in this case.

Additionally some of the algorithms you mention, like MD5 or SHA1 have weaknesses (some theoretical, some practical) and should not be used.

Prefer something like bcrypt, an algorithm designed to resist brute force attacks by being much slower than a general purpose cryptographic hash whose security can be “tuned” as necessary.

Alternatively, use something like PBKDF2 which is. Designed to run a password through a function of your choice a configurable number of times along with a salt, which also makes brute forcing much more difficult.

Adjust the iteration count depending on your usage model, keeping in mind that the slower it is, the more security against brute-force you have.

In selecting a cryptographic hash function for PBKDF, prefer SHA-3 or, if you can't use that, prefer one of the long variants of SHA-2: SHA-384 or SHA-512. I'd steer clear of SHA-256 although I don't think there's an issue with it in this scenario.

In any case, use the largest possible and best salt you can; I'd suggest that you use a good cryptographically secure PRNG and never use a salt less than 64 bits (note: that I am talking about the length of the salt generated, not the value returned).

Will these recommendations help 20 years down the road? Who knows - I'd err on the side of caution and say "no". But if you need security for that long a timeframe, you should consider using something other than passwords.

Anyways, I hope this helps.

Nik Bougalis
  • 10,495
  • 1
  • 21
  • 37
1

Here are two pedantic answers to this question:

  • If P = NP, there is provably no such hash function (and vice versa, incidentally). Since it has not been proven that P != NP at the time of this writing, we cannot make any strong guarantees of that nature.
  • That being said, I think it's safe to say that supercomputers developed within the next 20 years will take "time" to break your hash, regardless of what it is. Even if it is in plaintext some time is required for I/O.

Thus, the answer to your question is both yes and no :)

J W
  • 21
  • 1