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

  • escapesamsara@lemmings.world
    link
    fedilink
    English
    arrow-up
    4
    arrow-down
    1
    ·
    1 month ago

    Then you’re vulnerable to simple brute force attacks, which if paired with a dumped hash table, can severely cut the time it takes to solve the hash and reveal all passwords.

      • frezik@midwest.social
        link
        fedilink
        English
        arrow-up
        4
        ·
        1 month ago

        Some kind of upper bound is usually sensible. You can open a potential DoS vector by accepting anything. The 72 byte bcrypt/scrypt limit is generally sensible, but going for 255 would be fine. There’s very little security to be gained at those lengths.

        • sugar_in_your_tea@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 month ago

          I do 256 so I hopefully never need to update it, but most of my passwords are 20-30 characters or something, and generated by my password manager. I don’t care if you choose to write a poem or enter a ton of unicode, I just need a bunch of bytes to hash.