NIST proposes barring some of the most nonsensical password rules - eviltoast

Here is the text of the NIST sp800-63b Digital Identity Guidelines.

  • xthexder@l.sw0.com
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    2 months ago

    Newer password hashing algorithms have ways of combatting this. For example, argon2 will use a large amount of memory and CPU and can be tuned for execution time. So theoretically you could configure it to take 0.5 seconds per hash calculation and use 1 GB or more of ram. That’s going to be extremely difficult to bruteforce 8 characters.

    The trade-off is it will take a second or two to login each time, but if you’ve got some secondary pin system in place for frequent reauthentication, it can be a pretty good setup.

    Another disadvantage is the algorithm effectively gets less secure the less powerful your local device is. Calculating that same 0.5s hash on a beefy server vs your phone could make it take way longer or even impossible without enough ram.

    • nyan@lemmy.cafe
      link
      fedilink
      English
      arrow-up
      1
      ·
      2 months ago

      Unfortunately, it’s rare that we can control what hashing algorithm is being used to secure the passwords we enter. I merely pray that any account that also holds my credit card data or other important information isn’t using MD5. Some companies still don’t take cybersecurity seriously.

      • xthexder@l.sw0.com
        link
        fedilink
        English
        arrow-up
        4
        ·
        2 months ago

        Storing credit card data has its own set of strict security rules that need to be followed. It’s also the credit card company’s problem, not yours, as long as you dispute any fraudulent charges early enough.

        I’m coming at this from the perspective of a developer. A user can always use a longer password (and you should), but it’s technically possible to make an 8 character password secure, thus the NIST recommend minimum.