• bjorney
    link
    fedilink
    arrow-up
    2
    ·
    1 month ago

    Client side verification is just security by obscurity, which gains you very little.

    If someone is capable of MITM attacking a user and fetching a password mid-transit to the server over HTTPS, they are surely capable of popping open devtools and reverse engineering your cryptographic code to either a) uncover the original password, or b) just using the encrypted credentials directly to authenticate with your server without ever having known the password in the first place

    • Possibly linux@lemmy.zip
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 month ago

      That assumes that an adversary has control of the browser. The big reason you don’t want to send passwords over https is that some organizations have custom certs setup. It is better to just not send the password at all.

      • bjorney
        link
        fedilink
        arrow-up
        1
        ·
        1 month ago

        That assumes that an adversary has control of the browser

        No it doesn’t, if they intercept an encrypted password over HTTPS they can resend the request from their own browser to get access to your account

        The big reason you don’t want to send passwords over https is that some organizations have custom certs setup

        What is the problem with that? The password is secure and only shared between you and the site you are intending to communicate with. Even if you sent an encrypted password, they wrote the client side code used to generate it, so they can revert it back to its plaintext state server side anyways

        It is better to just not send the password at all.

        How would you verify it then?

        If not sending plaintext passwords was best practice then why do no sites follow this? You are literally posting to a site (Lemmy) that sends plaintext passwords in its request bodies to log-in