Just take the string as bytes and hash it ffs

  • @[email protected]
    link
    fedilink
    English
    42 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
      link
      English
      12 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
          link
          English
          1
          edit-2
          2 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

          • @[email protected]
            link
            fedilink
            English
            22 months ago

            If the end user is reusing passwords. Which, granted, a lot of people do.

            On the flip side, we’re also forcing the use of JavaScript on the client just to handle passwords. Meanwhile, the attack we’re protecting against only works for reused passwords, and the attacker is inside the server and can see the password after transport layer encryption is removed. This is a pretty marginal reason to force the complexity of JavaScript.