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

    • pivot_root@lemmy.world
      link
      fedilink
      English
      arrow-up
      8
      ·
      edit-2
      2 months ago

      Use a library. It’s far too easy for developers or project managers to fuck up the minimum requirements for safely storing passwords.

      But, if you are wanting to do it by hand…

      • Don’t use a regular hashing algorithm, use a password hashing algorithm
      • Use a high iteration count to make it too resource-intensive to brute force
      • Salt the hash to prevent rainbow tables
      • Salt the hash with something unique to that specific user so identical passwords have different hashes
      • Laser@feddit.org
        link
        fedilink
        English
        arrow-up
        2
        ·
        2 months ago

        Salt the hash with something unique to that specific user so identical passwords have different hashes

        Isn’t that… the very definition of a Salt? A user-specific known string? Though my understanding is that the salt gets appended to the user-provided password, hashed and then checked against the record, so I wouldn’t say that the hash is salted, but rather the password.

        Also using a pepper is good practice in addition to a salt, though the latter is more important.

        • frezik@midwest.social
          link
          fedilink
          English
          arrow-up
          4
          ·
          2 months ago

          Some implementers reuse the same salt for all passwords. It’s not the worst thing ever, but it does make it substantially easier to crack than if everything has its own salt.

          • orclev@lemmy.world
            link
            fedilink
            English
            arrow-up
            3
            ·
            2 months ago

            That’s a pepper not a salt. A constant value added to the password that’s the same for every user is a pepper and prevents rainbow table attacks. A per-user value added is a salt and prevents a number of things, but the big one is being able to overwrite a users password entry with another known users password (perhaps with a SQL injection).