MD5 password scrambler 'no longer safe'

MD5 password scrambler 'no longer safe'

Summary: The MD5 password hash algorithm is "no longer considered safe" by the original software developer, a day after the leak of more than 6.4 million hashed LinkedIn passwords.

SHARE:
TOPICS: Browser
16

The original author of the MD5 password hash algorithm has publicly declared his software end-of-life and is "no longer considered safe" to use on commercial websites.

This comes only a day after a data breach led to 6.46 million LinkedIn hashed passwords leaking to the Web. Since the data breach, thousands of passwords, including many that could be considered strong, have been decrypted, either through brute force or through lookups.

The primary cause is LinkedIn's failure to properly 'salt' the hashed passwords using SHA-1 algorithm. MD5 is a password hashing algorithm similar to that of SHA-1.

LinkedIn's Vicente Silveira said on Wednesday the company has increased its security "which includes hashing and salting of our current password databases." Although the post says this change was made “recently,” it does not indicate whether the change was applied last month, this week, or yesterday.

Danish developer Poul-Henning Kamp, who developed the widely used MD5 password scrambler, said that limitations to his software and a corresponding increase in computing power since its initial release has rendered his algorithm obsolete.

"I implore everybody to migrate to a stronger password scrambler without undue delay," he wrote in a blog post.

"On a state of the art COTS computer, the algorithm should take at the very least [100 milliseconds] when implemented in software, preferably more. Some kind of 'round count' parameter should be made run-time tweakable so that the runtime/complexity can be increased over time by system administrators."

"The algorithm should be based on repeated data-dependent iterations of several different complex one-way hash functions (MD5, SHA1, SHA2, BLOWFISH, you name it, use them all) in order to 'soak up area' in hardware based attack implementations."

How an MD5 hash is generated

How an MD5 hash is generated.

In 2004, researchers revealed a number of weaknesses in regularly-used hash functions. Later in 2005, MD5 was declared "broken" by security expert Bruce Schneier.

Kamp emphasised that there is "no advantage" in every major website using the exact same algorithm --- "quite the contrary in fact," he added --- as it makes it easier for hackers to develop their attack strategy.

"All major Internet sites, anybody with more than 50.000 passwords, should design or configure a unique algorithm --- consisting of course of standard one-way hash functions like SHA2 etc --- for their site, in order to make development of highly optimized password brute-force technologies a 'per-site' exercise for attackers."

Image credit: Hashcat.

Related:

Topic: Browser

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

16 comments
Log in or register to join the discussion
  • A hash algorithm is NOT encryption

    I realize you are not a technical writer, but at least get your facts straight. A hash algorithm is NOT encryption.
    cpuh0g
    • Yes, It is.

      Actually, MD5 is a cryptographic hash function. While not all hash algorithms are used for security, MD5 is.
      http://en.wikipedia.org/wiki/MD5
      http://tools.ietf.org/html/rfc1321
      Theory5
      • hash != Encryption

        Yes, it is a "cryptographic hash function", but that is still not encryption. An encryption operation involves a key and can be reversed if one knows the right key to reverse the operation. A hash is a one-way operation that cannot be reversed. You can run brute-force or dictionary or rainbow table attacks which attempt to find an input that results in the same hash, but that doesn't constitute a reversal of the operation.

        My point is that the headline is misleading and incorrect.

        Pedantic, yes.
        cpuh0g
      • Title changed

        Thanks for the comments, all.
        zwhittaker
      • No, it isn't

        Encryption only makes sense if you can decrypt what you've encrypted. That can only be done if the transformation is mutual, ie. it works both ways. MD5 - or any other hash function for that matter - DO NOT allow you to "decrypt" the encrypted password, ie. you can't restore the original plaintextfrom it (you can only look it up in tables listing pairs). Therefore MD5 is not an encryption, but a hash algorithm. QED
        ff2
      • Well done Zack

        For the acknowledgement/changes etc.
        ego.sum.stig
    • (Removed as redundant)

      (Removed as redundant)
      Spatha@...
  • Article confuses md5 and a program that uses md5 and misleads about LinkedI

    Poul-Henning Kamp (not a cryptographer by his own admission) developed md5crypt, a particular program that uses MD5. Ron Rivest (a well-known cryptographer) developed MD5.

    However, MD5 is also being deprecated due to increasingly powerful hardware and attack techniques.

    The article (in particular the summary) also wrongly implies LinkedIn uses MD5 (which is weaker than SHA-1).
    mattflaschen
  • nice graphic

    good explanation of how md5 is generated - no wonder its easily cracked!
    wendellgee2
  • Except Linked in isn't...well the same deal

    The LinkedIn breach uses SHA-1 which you did acknowledge but I don't understand why you bring MD5 into this. You shouldn't be using EITHER unless you have no choice and no matter what hashing algorithm is used you should always salt it. Heck why were the hashfiles even internet accessible?? There's many many ways around this and LinkedIn messed up big time.
    gorkon
  • fwiw, difference between keys and hashes

    A key is an index of functions.
    A hash is a function without an index.

    while encryption can be said to differ from communication in the exchange of a "secret" AKA a "key". encryption which uses different "keys" for encryption and decryption rely on the existence of one-way functions - hashes being an example of such a function.

    so, encryption is "coding" with secrets. AKA "keys".

    the principles of a code system can be traced to kerckhoff's principle. out of the six principles, the one that draws the most attention is to assume your adversary knows what you know so that the secrecy is in the "key", not the cipher/system.

    and, yes, RSA can be a public or one key system if the user shares his private key with receivers (the public key rendered irrelevant in that case).
    digitalshamen
    • I'm not sure what you're on about...

      Hashes aren't encryptors and have nothing to do with PKI in the way you're describing it. There is no 'key' for a hash in a normal sense. There's a salt, which is a randomiser.

      Hashes are a way to take large data and map it into a smaller space, which then can be used to index a table, or as a key (in the database sense, not the PKI sense) into a database.

      Hashes aren't even required to be one way. Technically, a perfect hash generates a unique value for every possible valid input. You could then make a table of every possible hash and use the hash as index back to the original value.

      The only reason people use hashes instead of proper crypto is that it's computationally inexpensive. But ultimately, it's the wrong solution. A better solution would be to encrypt the passwords using PKI (or some other good encryption scheme).
      TheWerewolf
      • Hashes have advantages over encryption for passwords

        Encryption is a two-way function, while hashing is one way. You can guess at the password needed to map into the hash key, but this is computationally expensive. It can be made virtually impossible with proper salting.

        With Encryption, the server will have all the passwords on the server in an encrypted form that could be recovered through decryption. A decryption would have to be available on the server to validate passwords. If the server is hacked, all original passwords would be known immediately.
        jordan.henderson@...
      • "hashes have nothing to do with PKI"

        Maybe you should reread what I wrote. You seem utterly clueless to underlying primitives. Without one way functions - there is NO PKI. Fact.

        As for your explanation of hashes, again, not relevant to the act of salting the input.

        Try the easy definition, then brush up on "crypto" using common language before incorrectly mixing terminology ...

        Simply stated: a hash takes a variable length input and returns a fixed length output.

        These outputs are ("hash values" they are not "keyed" and a hashed encryption of cipher text yields the term "digital signature", but let's keep simple) and typically expected to meet a test for randomness (only historically as they are proving easier to reverse than previously thought).

        As for your disparaging remarks: please educate yourself.
        digitalshamen
  • Thank You!

    [b]Zack Whittaker[/b]'s article this morning, [i]2012-06-07 Thursday 06:01(PDT)[/i], reminds me when I managed password updates with my fellow [b]Unix[/b] system administrators. Keeping over 100 system passwords distinct and changed regularly (and without repetition) was quite a trick.
    I may have let that security responsibility slip. But hearing Zack's exclamation, "[i]Hey![/i]" had my account password updated well before lunch. We should all create new and obscure passwords regularly. Then use them. Resigned to [i]deal with what we've got[/i], I hope to say "[b][i]TGiF[/i][/b]" tomorrow.
    mjd@...
  • Salting is not the only issue

    The absence of salting at linkedin is a major fault but not the only one. This fault only makes it as easy to crack 6M passwords as it is to crack only one. What is even more important than salting is to force the algorithm to use a large number of rounds so that passwords take a huge time to be generated. My 2-years old computer generates 20M SHA1 hashes a second. It's not normal to be able to test that many passwords as fast. I should just be able to test a few tens, hundreds or at most thousands, but not millions. It takes less than one day to exhaut the entire key space for 8 lower case chars ! It should take tens of years instead ! So don't just consider that your salted SHA1 are fine, you need to add many rounds otherwise you'll fail just like linkedin.
    wtarreau