Just take the string as bytes and hash it ffs

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

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