• dudeami0@lemmy.dudeami.win
    link
    fedilink
    English
    arrow-up
    7
    ·
    2 years ago

    Is there a reason you consider passwords longer than 60 characters an issue, or does the backend reject such passwords? In my experience, there should be no upper bound on password length except maybe in the order of request size being too large (say a password that is a several kilobytes).

    • Lionir [he/him]@beehaw.org
      link
      fedilink
      English
      arrow-up
      17
      ·
      2 years ago

      The 60 character limit is not a problem imo, the problem is that they are truncated at 60 but the UI doesn’t tell you, this results in some problems.

    • Xanvial@lemmy.one
      link
      fedilink
      English
      arrow-up
      6
      ·
      edit-2
      2 years ago

      Some password encryption methods has max characters length. For example Bcrypt has 72 max length. This is mostly to avoid taking too much time encrypting user input.

      If there’s no limit someone can technically froze the server by inputting large password (not because the request is big, but encryption process is exponentially takes more CPU process the longer it is)

      • dudeami0@lemmy.dudeami.win
        link
        fedilink
        English
        arrow-up
        1
        ·
        2 years ago

        Having only ever implemented PBKDF2 this is a good insight as well. This limitation does not seem to be an issue with more modern hashing algorithms, but I can see where limiting the size to a reasonable amount for purposes of having an upper bound on performance would be needed.

    • livingcoder@lemmy.austinwadeheller.com
      link
      fedilink
      English
      arrow-up
      2
      ·
      2 years ago

      Passwords “should” be hashed anyway, so I don’t understand why there’s a limit. Are they actually being stored as plaintext in a VARCHAR(60) column in the database? Please tell me that’s not happening.