Was testing things and ran into autofill errors with KeePassXC. Looks like the Firefox plugin manages to pass the full length of the password, even if the input field is limited to a lower number of chars. Manually pasting the password truncates it, though.

  • Slotos@feddit.nl
    link
    fedilink
    English
    arrow-up
    7
    ·
    edit-2
    1 year ago

    Considering hash functions used for passwords operate in a range of 32 to 64 bytes, that’s really not a problem. Go above that length, and you’re not ultimately improving your password collision resistance due to pigeonhole principle.

    There are caveats. For example, if the only source of feeding the colliding passwords to the system is an endpoint that filters for human readable inputs, then that could double (well, spread) the effective collision search space size. Which is not really a factor on your 480 bits password length.

    PS: Newer password hashing algorithms like argon2 can scale into gods defying territory, but in practice they also tend to stay below 128 bytes. Those hashes need to be stored, calculated, and compared - all of which are DoS vectors.

    • Illecors@lemmy.cafeOPM
      link
      fedilink
      English
      arrow-up
      5
      ·
      1 year ago

      Pidgeonhole principle for those interested. Thank you, I’ve learnt something today!

      Those hashes need to be stored, calculated, and compared - all of which are DoS vectors.

      Fair point. But at least a visible range next to the form would be such a massive improvement already.

      • Slotos@feddit.nl
        link
        fedilink
        English
        arrow-up
        2
        ·
        edit-2
        1 year ago

        Definitely. I’d say the limit should also be calculated over a useful inputs space, which is likely larger than 60 symbols. A good chunk of byte sequences that hash algorithm could accept are nearly guaranteed to never be submitted by a legitimate user.

        Depending on an encoding and an alphabet the password manager or user themselves use, up to half of possible bit sequences are impossible to achieve. E.g. 10000001 is not a valid one-character string in UTF-8. And no upper byte in UTF-8 can’t start with 0. So it’s easy to get locked to 7 bits of variability on every byte.

        Which would mean that 60 symbols input is not 2^480 variable bytes, but 2^420. That translates into an effective length of about 52 characters. Still a lot and above what’s considered vulnerable, but a few more restrictions or overeager optimizations, and suddenly the problem is shrunk to a space that a bitcoin farm can manage.

        In other words, security is a fascinating topic.

        PS: “up to half” is definitely optimistic, by the way. I’m definitely unlikely to ever produce a password that has a byte starting with 0 and two follow up bytes starting with 1s. I won’t even know how to type them, and I like my passwords typable.

        • Illecors@lemmy.cafeOPM
          link
          fedilink
          English
          arrow-up
          2
          ·
          1 year ago

          This is fascinating :)

          Just to double check - did you mean bits rather than bytes?

          • Slotos@feddit.nl
            link
            fedilink
            English
            arrow-up
            2
            ·
            1 year ago

            Just reread my wall of text, and I think bits and bytes are in the right places. I do have a tendency to be blind to my own typos, however, so there’s that ._.