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

  • catloaf@lemm.ee
    link
    fedilink
    English
    arrow-up
    49
    ·
    2 days ago

    I hate that anyone has to be told not to truncate passwords. Like even if you haven’t had any training at all, you’d have to be advanced stupid to even come up with that idea in the first place.

    • einlander@lemmy.world
      link
      fedilink
      English
      arrow-up
      20
      ·
      2 days ago

      Microsoft used to do that. I made a password in the late 90’s for a we service and I found out that it truncated my password when they made it after it warned my my password was too long when I tried to log in. It truncated at 16 characters.

      • catloaf@lemm.ee
        link
        fedilink
        English
        arrow-up
        7
        ·
        1 day ago

        The weirdest one I found was a site that would only check to see if what you entered started with the correct password. So if your password was hunter2 and you tried hunter246, it would let you in.

        Which means not only were they storing the password, but they had to go out of their way to use the wrong kind of string comparison.

        • wreckedcarzz@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 day ago

          USAA does this. I renentl learned that, when I updated my password a few years back to my personal standard number of characters, everything was good until someone mentioned this fuck-up in a thread. USAA only checks the first… 16? characters. I assume it just discards anything beyond that. Other users say that it warns and doesn’t let you enter more than that during password creation, but it/my pw mgr sure didn’t care, as I have a password several fold that limit. I took out a couple characters from my ‘set’ password, and it still logged in just fine. 16, just fine. 15, error.

          Fucking wild.

    • Amanduh@lemm.ee
      link
      fedilink
      English
      arrow-up
      7
      ·
      2 days ago

      Can you elaborate further? Why would someone want to truncate passwords to begin with?

      • essteeyou@lemmy.world
        link
        fedilink
        English
        arrow-up
        19
        ·
        2 days ago

        To save a few megabytes of text in a database somewhere. Likely the same database that gets hacked.

        • orclev@lemmy.world
          link
          fedilink
          English
          arrow-up
          24
          ·
          2 days ago

          Which shouldn’t even matter because passwords are salted and hashed before storing them, so you’re not actually saving anything. At least they better be. If you’re not hashing passwords you’ve got a much bigger problem than low complexity passwords.

          • essteeyou@lemmy.world
            link
            fedilink
            English
            arrow-up
            28
            ·
            2 days ago

            The place that truncates passwords is probably not the place to look for best practices when it comes to security. :-)

            • orclev@lemmy.world
              link
              fedilink
              English
              arrow-up
              6
              ·
              2 days ago

              Hashing passwords isn’t even best practice at this point, it’s the minimally acceptable standard.

                • pivot_root@lemmy.world
                  link
                  fedilink
                  English
                  arrow-up
                  8
                  ·
                  edit-2
                  2 days 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 days 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.

                  • Buddahriffic@lemmy.world
                    link
                    fedilink
                    English
                    arrow-up
                    1
                    ·
                    1 day ago

                    I remember hearing to not layer encryptions or hashes on top of themselves. It didn’t make any sense to me at the time. It was presented as if that weakened the encryption somehow, though wasn’t elaborated on (it was a security focused class, not encryption focused, so didn’t go heavy into the math).

                    Like my thought was, if doing more encryption weakened the encryption that was already there, couldn’t an attacker just do more encryption themselves to reduce entropy?

                    The class was overall good, but this was still a university level CS course and I really wish I had pressed on that bit of “advice” more. Best guess at this point is that I misunderstood what was really being said because it just never made any sense at all to me.