Just take the string as bytes and hash it ffs

    • Showroom7561@lemmy.ca
      link
      fedilink
      English
      arrow-up
      0
      ·
      3 months ago

      Reasonable upper limits are OK. But FFS, the limit should be enough to have a passphrase with 4 or 5 words in it.

      • aname@lemmy.one
        link
        fedilink
        English
        arrow-up
        0
        ·
        3 months ago

        Usually 256 bit hash is used. 256 bits is 32 bytes or 32 characters. Of course you are losing some entropy because character set is limited, but 32 characters is beyond reasonable anyway.

        • Lojcs@lemm.ee
          link
          fedilink
          English
          arrow-up
          0
          ·
          edit-2
          3 months ago

          The eff passphrase generator has about 2.5 bits of entropy per character (without word separators). Eff recommends 6 word passphrases, and with an avg word length of 7, that’s (only) 79.45 bits of entropy that won’t even fit in the 32 characters. If there wasn’t a password length limit it would be possible to saturate the hash entropy with a 20+ word & 102+ char passphrase.

        • Showroom7561@lemmy.ca
          link
          fedilink
          English
          arrow-up
          0
          ·
          3 months ago

          I’d be totally fine woth 32 characters! But I’ve come across too many websites with unreasonably short (20 characters or less) limits.

    • CosmicTurtle0@lemmy.dbzer0.com
      link
      fedilink
      English
      arrow-up
      0
      ·
      3 months ago

      I sort of get it. You don’t want to allow the entire work of Shakespeare in the text field, even if your database can handle it.

      16 characters is too low. I’d say a good upper limit would be 100, maybe 255 if you’re feeling generous.

      • Saik0@lemmy.saik0.com
        link
        fedilink
        English
        arrow-up
        0
        ·
        3 months ago

        I sort of get it. You don’t want to allow the entire work of Shakespeare in the text field, even if your database can handle it.

        You don’t store the original text. You store the hash of it. If you SHA512 it, anything that’s ever given in the password field will always be 64Bytes.

        The only “legit” reason to restrict input to 16 character is if you’re using an encryption mechanism that just doesn’t support more characters as an input. However, if that’s the case, that’s a site I wouldn’t want to use to begin with if at all possible.

        • CosmicTurtle0@lemmy.dbzer0.com
          link
          fedilink
          English
          arrow-up
          0
          ·
          3 months ago

          I’ll admit I kind of typed this without thinking it through. In a secured site, the password would be hashed and salted before storing in the database.

          Depending on where you’re doing the hashing, long strings might still slow you down. That being said, from a security standpoint, any gain in entropy by adding characters would be negligible past a certain point. I don’t remember what that number is but it certainly isn’t in the thousands.

          • Saik0@lemmy.saik0.com
            link
            fedilink
            English
            arrow-up
            0
            ·
            3 months ago

            That being said, from a security standpoint, any gain in entropy by adding characters would be negligible past a certain point.

            That would be completely based on the hash being used. In the example above I showed SHA512 which is 64Bytes. If we’re using ASCII (7 bit per character) as our input then 64 Bytes is just over 73(73.1428…) characters. After that you’re losing data in the hashing process and by that effect it would be negligible… (There’s some wiggle room here in that we can’t type hidden ASCII characters so some passwords over 73 characters would fill those spaces… but detecting collisions is silly and non-trivial… better to just not worry about those at all.)

            Extended ASCII would be same premise, just 64 characters instead of 73.

            The reality is that nobody is using much more than 64 Bytes for their hashing algorithm for passwords… 64 characters is a good number to max out most of them. Databases don’t need to store much at all regardless of the length of your actual password. If you’re developing an app you can set the database to limit based on the algorithms you’re using. If you have no idea what the web-dev will actually use… then 128 characters on the database field is probably pretty safe (88 I think if storing as Base64, 128 if storing in Hex. Could be off by one here.) and literally trivial to store. The point being that even if every one of your users submitted 10000 character long passwords… that’s irrelevant and trivial for storage as hashes.

            • frezik@midwest.social
              link
              fedilink
              English
              arrow-up
              0
              ·
              3 months ago

              There’s a more practical limit. Using US standard keyboard symbols, a 40 char password is about as secure as a 256-bit block cipher key. That’s impossible to break due to thermodynamic limits on computing.

              The reason to put a high char limit is to mitigate DoS attacks. It can still be a few hundred chars.

        • blackstrat@lemmy.fwgx.uk
          link
          fedilink
          English
          arrow-up
          0
          ·
          2 months ago

          The resulting hash will always be the same size, but you don’t want to have an unlimited upper bound otherwise I’m using a 25GB blueray rip as my password and your service is going to have to calculate the hash of that whenever I login.

          Sensible upper bounds are a must to provide a reliable service not open to DDOS exploits.

          • Saik0@lemmy.saik0.com
            link
            fedilink
            English
            arrow-up
            0
            ·
            edit-2
            2 months ago

            Sensible upper bounds are a must to provide a reliable service not open to DDOS exploits.

            If I choose to make you hash it in browser first… Then I simply don’t care do I? I can hash/salt again when I get your hash. Edit: There are other answers to the “DDOS problem” that don’t require upper bounds.

            • blackstrat@lemmy.fwgx.uk
              link
              fedilink
              English
              arrow-up
              0
              ·
              edit-2
              2 months ago

              You can make a client hash it, but if you don’t reject large inputs to your API a client can send enough data to DOS you anyway.

              • Saik0@lemmy.saik0.com
                link
                fedilink
                English
                arrow-up
                0
                ·
                2 months ago

                And a meteor can hit my server the exact time you send your hash which will DOS you/others as well. What’s your point.

                The thread is talking about what it takes to store passwords. There is not DOS potential in a well designed system. Just because you want to arbitrarily conjure up bullshit doesn’t make that any less true.

                Rejecting large inputs != disallowing users to have large passwords. Why are you attempting to straw-man me here?

                • blackstrat@lemmy.fwgx.uk
                  link
                  fedilink
                  English
                  arrow-up
                  0
                  ·
                  2 months ago

                  You were saying the input size doesn’t matter because you only store the hash which is always the same size. What I’m saying is that the input size really does matter.

                  You absolutely should set upper limits on all input fields because it will be abused if you don’t. Systems should validate their inputs, passwords included

      • owsei@programming.dev
        link
        fedilink
        English
        arrow-up
        0
        ·
        3 months ago

        The problem is that you (hopefully) hash the passwords, so they all end up with the same length.

        • Carighan Maconar@lemmy.world
          link
          fedilink
          English
          arrow-up
          0
          ·
          3 months ago

          And sure, in theory your hashing browser-side could break if you do that. Depending on how much text the user pastes in. But at that point, it’s no longer your problem but the browser’s. 🦹

          • CommanderCloon@lemmy.ml
            link
            fedilink
            English
            arrow-up
            0
            ·
            3 months ago

            If you hash in the browser it means you don’t salt your hash. You should absolutely salt your hash, not doing so makes your hashes very little better than plaintext.

            • Shadow@lemmy.ca
              link
              fedilink
              English
              arrow-up
              0
              ·
              edit-2
              3 months ago

              There’s nothing stopping a browser from salting a hash. Salts don’t need to be kept secret, but it should be a new random salt per user.

          • owsei@programming.dev
            link
            fedilink
            English
            arrow-up
            0
            ·
            3 months ago

            Why are you hasing in the browser?

            Also, what hashing algorithm would break with large input?

            • FierySpectre@lemmy.world
              link
              fedilink
              English
              arrow-up
              0
              ·
              3 months ago

              Why would you not hash in the browser. Doing so makes sure the plaintext password never even gets to the server while still providing the same security.

              • frezik@midwest.social
                link
                fedilink
                English
                arrow-up
                0
                ·
                edit-2
                3 months ago

                Per your edit, you’re misunderstanding what Bitwarden does and why it’s different than normal web site password storage.

                Bitwarden is meant to not have any insight into your stored passwords what so ever. Bitwarden never needs to verify that the passwords you’ve stored match your input later on. The password you type into Bitwarden to unlock it is strictly for decrypting the database, and that only happens client side. Bitwarden itself never needs to even get the master password on the server side (except for initial setup, perhaps). It’d be a breach of trust and security if they did. Their system only needs to store encrypted passwords that are never decrypted or matched on their server.

                Typical website auth isn’t like that. They have to actually match your transmitted password against what’s in their database. If you transmitted the hashed password from the client and a bad actor on the server intercepted it, they could just send the hashed password and the server would match it as usual.

              • candybrie@lemmy.world
                link
                fedilink
                English
                arrow-up
                0
                ·
                edit-2
                3 months ago

                Because then the hash is the password. Someone could just send the hash instead of trying to find a password that gets the correct hash. You can’t trust the client that much.

                You can hash the password on both sides to make it work though.

              • CommanderCloon@lemmy.ml
                link
                fedilink
                English
                arrow-up
                0
                ·
                3 months ago

                Because then that means you don’t salt your hashes, or that you distribute your salt to the browser for the hash. That’s bad.

                • frezik@midwest.social
                  link
                  fedilink
                  English
                  arrow-up
                  0
                  ·
                  3 months ago

                  You could salt it. Distributing a unique salt doesn’t help attackers much. Salt is for preventing precomputing attacks against a whole database. Attacking one password hash when you know the salt is still infeasible.

                  It’s one of those things in security where there’s no particular reason to give your attacker information, but if you’ve otherwise done your job, it won’t be a big deal if they do.

                  You don’t hash in the browser because it doesn’t help anything.

                  • FierySpectre@lemmy.world
                    link
                    fedilink
                    English
                    arrow-up
                    0
                    ·
                    3 months ago

                    It helps against the server being able to read the password, so a bad actor (either the website itself or after a hack) could read your password. Which isn’t bad if you’re using good password hygiene with random passwords, but that sadly is not the norm.

              • frezik@midwest.social
                link
                fedilink
                English
                arrow-up
                0
                ·
                3 months ago

                With comments like this all over public security forums, it’s no wonder we have so many password database cracks.

              • Swedneck@discuss.tchncs.de
                link
                fedilink
                English
                arrow-up
                0
                ·
                2 months ago

                wouldn’t you then just break it up into chunks of 72 bytes, hash them individually, and concatenate the hashes? And if that’s still too long, split the hash into 72 byte chunks and repeat until it’s short enough?

                • yhvr@lemm.ee
                  link
                  fedilink
                  English
                  arrow-up
                  0
                  ·
                  2 months ago

                  I don’t know the specifics behind why the limit is 72 bytes, but that might be slightly tricky. My understanding of bcrypt is that it generates 2^salt different possible hashes for the same password, and when you want to test an input you have to hash the password 2^salt times to see if any match. So computation times would get very big if you’re combining hashes

              • owsei@programming.dev
                link
                fedilink
                English
                arrow-up
                0
                ·
                3 months ago

                Damm, I legit didn’t knew there bcrypt had a length limit! Thank you for another reason not to use bcrypt

                • frezik@midwest.social
                  link
                  fedilink
                  English
                  arrow-up
                  0
                  ·
                  3 months ago

                  Scrypt has the same limit, FWIW.

                  It doesn’t matter too much. It’s well past the point where fully random passwords are impossible to brute force in this universe. Even well conceived passphrases won’t get that long. If you’re really bothered by it, you can sha256 the input before feeding it to bcrypt/scrypt, but it doesn’t really matter.

        • expr@programming.dev
          link
          fedilink
          English
          arrow-up
          0
          ·
          3 months ago

          At minimum you need to limit the request size to avoid DOS attacks and such. But obviously that would be a much larger limit than anyone would use for a password.

      • MangoPenguin@lemmy.blahaj.zone
        link
        fedilink
        English
        arrow-up
        0
        ·
        edit-2
        3 months ago

        Even 255 bytes with 10 million entries is only ~2.6GB of data you need to store, and if you have 10 million users the probably $1 a month extra that would cost is perfectly fine.

        I suppose there may be a performance impact too since you have to read more data to check the hash, but servers are so fast now it doesn’t seem like that would be significant unless your backend was poorly made.

      • Chris@feddit.uk
        link
        fedilink
        English
        arrow-up
        0
        ·
        3 months ago

        The eBay password limit is 256 characters.

        They made the mistake of mentioning this when I went to change my password.

        Guess how many characters my eBay password has?

    • needanke@feddit.org
      link
      fedilink
      English
      arrow-up
      0
      ·
      3 months ago

      Just opened a PayPal account and their limit is 20. Plus the only 2fa option is sms 🙃.

    • rekabis@lemmy.ca
      link
      fedilink
      English
      arrow-up
      0
      ·
      2 months ago

      Especially since it takes more effort to limit it than leave it wide open for whatever length of password a user wants to use.

      nvarchar(max) is perfect to store the hashed copy.

      • CaptPretentious@lemmy.world
        link
        fedilink
        English
        arrow-up
        0
        ·
        3 months ago

        Yep. Having to have requirements that doesn’t flow with people very well and requiring constant updates, people WILL find shortcuts. In the office, I’ve seen sheets of paper with the password written down, I’ve seen sticky notes, I’ve seen people put them in notepad/word so they could just copy paste.

        This is made worse, because you have to go out of your way for a password manager, which means you need to know what that is. And you need a good one because there has been (and I’m going to generalize here) problems with some password managers in the past. And for work, they have to allow a password manager for that to even be an option. Which you then end up with this security theater.

        • rekabis@lemmy.ca
          link
          fedilink
          English
          arrow-up
          0
          ·
          2 months ago

          And you need a good one because there has been problems with some password managers in the past.

          coughLastPasscough

          “Problems”. What an delightfully understated term to use.

      • Discover5164@lemm.ee
        link
        fedilink
        English
        arrow-up
        0
        ·
        3 months ago

        the password cannot contains the same sequences of characters as the old password.

        and i have seen this requirement in a service that requires changing it every month for some reasons.

        and this is to manage a government digital identity that allows to log it in all governments websites.

        • PM_me_your_doggo@lemmy.world
          link
          fedilink
          English
          arrow-up
          0
          ·
          edit-2
          2 months ago

          the password cannot contains the same sequences of characters as the old password.

          That’s a weird way to say “we store your password in plaintext”

          • blackstrat@lemmy.fwgx.uk
            link
            fedilink
            English
            arrow-up
            0
            ·
            2 months ago

            Not necessarily. Presumably the change password form requires entering the old and new password at the same time. Then they can compare the two as plain text and hash the old password to make sure it matches, then if so, hash the new password and overwrite it. Passwords stored hashed, comparison only during the change process. A theme on this is checking password complexity rules during the login process and advising to update to something more secure. It’s possible because you’re sending the password as plain text (hopefully over a secure connection), so it can be analysed before computing the hash. This even works if the hash is salt and peppered.