In password security, the longer the better. With a password manager, using more than 24 characters is simple. Unless, of course, the secure password is not accepted due to its length. (In this case, through STOVE.)

Possibly indicating cleartext storage of a limited field (which is an absolute no-go), or suboptimal or lacking security practices.

  • troed
    9•6 days ago

    I agree you might have threat actors looking to DoS your system if there’s a publicly exposed REST endpoint accepting gigabytes of data. That has nothing to do with the discussion on password hashing though.

    • @[email protected]English
      7•6 days ago

      The claim was that a limit on passwords implies plaintext storage. It doesn’t. There is no such thing as unlimited on computers.

      • troed
        6•6 days ago

        Don’t worry, I’m autistic myself and understand how difficult it can be to parse “it’s thus irrelevant how many characters the user’s password consists of” to mean something besides “all implementations must accept an unlimited amount of characters”.

        I do believe the point was understood by the general reader however.

      • @[email protected]OPEnglish
        9•6 days ago

        The claim was that a limit on passwords implies plaintext storage.

        quoting the post:

        Possibly indicating cleartext storage of a limited field (which is an absolute no-go), or

        It was not a claim that it certainly is plaintext storage. It was claimed to be a possibility. AND provided an alternative explanation.

        Maybe you’re more confident than me in good practices and implementations across all services. But I’ve seen enough to know that’s not always the case. It’s good to be skeptical on anything related to security.