Edit: @Successful_Try543@feddit.org solved it. It says “one special character”. Not “at least one”.

  • NotAnOnionAtAll@feddit.org
    link
    fedilink
    arrow-up
    7
    ·
    4 months ago

    At least the character limit had a technical reason behind it: having a set size for fields means your database can be more efficient.

    If that is the actual technical reason behind it, that is a huge red flag. When you hash a password, the hash is a fixed size. The size of the original password does not matter, because it should not be stored anyway.

    • Buddahriffic@lemmy.world
      link
      fedilink
      arrow-up
      3
      ·
      4 months ago

      Correct, hence the sentence after the one you quoted :)

      If any service can recover your password and send it back to you rather than just resetting it for you to set a new one, don’t rely on that service for anything you want to keep secure. And certainly don’t reuse a password there, though you shouldn’t be reusing passwords anyways because who knows what they are and aren’t storing, even if they don’t offer password recovery.

      • NotAnOnionAtAll@feddit.org
        link
        fedilink
        arrow-up
        3
        ·
        4 months ago

        Sorry, didn’t want this to look like an attack or disagreement. Just wanted to highlight that point, because arbitrary maximum sizes for passwords are a pet peeve of mine.

        • Buddahriffic@lemmy.world
          link
          fedilink
          arrow-up
          3
          ·
          4 months ago

          Yeah no worries and agreed. I hate seeing commercial sites using worse password sanitization practices than I used for my first development website that wasn’t even really intended for anyone else to log in to and any max length suggests the password is either stored or processed in plaintext.

          IMO it should even be hashed on the client side before being sent so that it doesn’t show up as plaintext in any http requests or logs. Then salted and hashed again server side before being stored (or checked for login).

          • SpaceCowboy@lemmy.ca
            link
            fedilink
            arrow-up
            2
            ·
            4 months ago

            IMO it should even be hashed on the client side before being sent so that it doesn’t show up as plaintext in any http requests or logs. Then salted and hashed again server side before being stored (or checked for login).

            But if someone got that hashed version they could hack the client to have client side hashing code just send that hashed value to the server. You’d want to have the server to send a rotating token of some sort to use for encrypting the password on the client and then validate it on the server side that it was encrypted with the same token the server sent.

            Seems complicated to me… https is probably has good enough encryption, so eh, whatever.

            • Buddahriffic@lemmy.world
              link
              fedilink
              arrow-up
              1
              ·
              4 months ago

              Yeah, if they are able to intercept traffic or access the logs, they probably already have other access to the account without needing the password. If you don’t reuse passwords, then your other accounts will be safe from that.