Just take the string as bytes and hash it ffs

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

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

    • expr@programming.dev
      link
      fedilink
      English
      arrow-up
      57
      ·
      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.

    • Carighan Maconar@lemmy.world
      link
      fedilink
      English
      arrow-up
      6
      arrow-down
      17
      ·
      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. 🦹

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

        Why are you hasing in the browser?

        Also, what hashing algorithm would break with large input?

          • owsei@programming.dev
            link
            fedilink
            English
            arrow-up
            4
            arrow-down
            1
            ·
            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
              4
              ·
              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.

          • Swedneck@discuss.tchncs.de
            link
            fedilink
            English
            arrow-up
            1
            ·
            3 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
              2
              ·
              3 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

          • candybrie@lemmy.world
            link
            fedilink
            English
            arrow-up
            20
            arrow-down
            1
            ·
            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 I’m not sure why you’d want to. I’m not sure what attack never having the plain text password on the server would prevent. Maybe some protection for MITM with password reuse?

          • CommanderCloon@lemmy.ml
            link
            fedilink
            English
            arrow-up
            8
            arrow-down
            2
            ·
            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
              4
              ·
              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
                1
                ·
                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.

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

                    For that particular website yes, but a salted client side hash is worthless on a different website.

                    Edit: plus even unsalted it would only work if the algorithm is the same and less iterations are done

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

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

          • frezik@midwest.social
            link
            fedilink
            English
            arrow-up
            3
            ·
            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.

      • CommanderCloon@lemmy.ml
        link
        fedilink
        English
        arrow-up
        8
        arrow-down
        3
        ·
        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
          6
          arrow-down
          1
          ·
          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.

        • Saik0@lemmy.saik0.com
          link
          fedilink
          English
          arrow-up
          1
          ·
          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.

          That’s not true. If they send hashed password you could salt/hash again on server if you’re trying to keep the salt “secret”. Their hash should always be the same if they’ve submitted the same password. You’d just be hashing a hash in that case… but it’s the same premise.