• Godort@lemmy.ca
    link
    fedilink
    arrow-up
    11
    ·
    48 minutes ago

    MD5 hashes have been crackable on consumer hardware for like 20 years.

  • kmartburrito@lemmy.world
    link
    fedilink
    arrow-up
    8
    ·
    1 hour ago

    That’s why they need a little bit of seasoning. Some salt would do the trick. At least it would help with a dictionary/rainbow table based attack anyway

    • e0qdk@reddthat.com
      link
      fedilink
      arrow-up
      2
      ·
      39 minutes ago

      Yep, salt. Also, there are much better options than MD5. I used bcrypt in systems I built a while back. There’s also scrypt and argon2, which are newer. (Just be careful that you don’t create a DoS vulnerability while hardening your login system…)

      • kmartburrito@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        26 minutes ago

        Yep, and md5 is only used by many because it’s so fast. Cutting corners for speed’s sake is always going to come with a penalty somewhere.

    • Danitos@reddthat.com
      link
      fedilink
      arrow-up
      5
      ·
      22 minutes ago

      MD5 is a hashing algorithm (for simplicity, let’s wrongly say hashing it’s something akin to encrypting) that is very fast to compute. That is bad for password storage, since it means you are vulnerable to a brute force attack; you want the algorithm for password storage to be slow enough to make that attack unfeasible.

      Aditionally, there’s also attacks like dictionary attacks, where you can use precomputed hashes of commonly used passwords (that’s a reason you shouldn’t re-use passwords accross websites: if one of the falls, the rest are vulnerable to dictionary attacks). To prevent these, you use salted algorithms, of which MD5 is not, at least out of the box.

    • DahGangalang@infosec.pub
      link
      fedilink
      arrow-up
      1
      ·
      3 minutes ago

      Probably not the best for this, but to make an attempt:

      So when you store a password you don’t (or at least shouldn’t) store the actual password.

      Because of some magic some math wizards cobbled together a good while ago, we have some algorithms that take a blob of information and chop it all up in unique (or at least close enough to be called unique) ways. These algorithms make it such that changing a tiny piece of input has a major change on output. This whole thing is called “Hashing”.

      So anyway, we don’t store the actual password (“in the clear”), instead we store “hashes” of passwords.

      One of the first adopted standards for hashing was Message Digest 5 (MD5). At the time (80’s if the memory serves), it was reasonably effective for all the things it was needed for.

      But over time, we’ve found weaknesses in it. On modern hardware, its not overly difficult to figure out all the password length things that could have been used as input to generate a given hash.

      Nowadays, there’s more secure hashing algorithms, but to support legacy software, MD5 is still used. TBH, I don’t think it’s as big of a deal as the article makes it seem for personal use gear. Its once you step up to small business stuff (where multiple people have access to the same hardware).

      Other commentors have brought up salting, which is a decent way to help with security. Its where you add known info to the password before hashing to make determining the “real” password more difficult.

  • Admetus@sopuli.xyz
    link
    fedilink
    arrow-up
    1
    ·
    1 hour ago

    I think I gather from this that predictable strings are sort of reversible to hashes.

    For stuff like SQL databases, I suppose I would personally would generate completely random passwords locally on my PC.