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.

  • Pennomi@lemmy.world
    link
    fedilink
    English
    arrow-up
    21
    arrow-down
    1
    ·
    3 days ago

    Not DDOS, DOS. You can often crash an unprepared server with one request by telling it to hash more data than it has memory for. See this blog post for a well-known web framework. Let’s say I just sent it a 10GB password, it still has to process that data whether or not the hash eventually shortens to the database field length.

    • rumba@lemmy.zip
      link
      fedilink
      English
      arrow-up
      2
      ·
      2 days ago

      Just another in a long list of decisions Django made that makes me dislike it.

      Let the client hash the password to reduce it. then enforce the hash length as the password length. It’s transparent to the user and doesn’t look like a pile of bad ideas.

    • jj4211@lemmy.world
      link
      fedilink
      English
      arrow-up
      3
      arrow-down
      1
      ·
      3 days ago

      Though it could also amplify DDOS. Allowing 72 character passwords lets a DDOS be three times rougher despite being a seemingly modest limit for a single request.

      If a password/passphrase is 24 characters, then any further characters have no incremental practical security value. The only sorts of secrets that demand more entropy than that are algorithms that can’t just use arbitrary values (e.g RSA keys are big because they can’t be just any value).