I tried logging in on browser and I had inspected the request. My password was sent in plaintext. Is this a infosec.pub issue or a Lemmy one?

  • clb92@kbin.social
    link
    fedilink
    arrow-up
    8
    ·
    1 year ago

    The server needs to receive your password to verify it and log you it. That’s how it always is. As long as you are connecting via HTTPS, this is not a problem.

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

      Please forgive me as I haven’t coded anything in 15ish years but even when making shitty PHP message boards back in the day we would always hash and salt passwords. The server would never see a plain text version of your password.

      HTTPS is nice but that doesn’t guarantee what the server is doing with my plain text password.

      Edit: I just had the thought that when coding those message boards the PHP running on the server side would get a plain text password via POST, hash/salt it, then store that in a database to use for comparison later. So I guess the server did need it in plain text in that application. 🤷🏻‍♂️

      • clb92@kbin.social
        link
        fedilink
        arrow-up
        4
        ·
        1 year ago

        The server would never see a plain text version of your password.

        As you realized in your edit already, this part is not correct. The server would always receive your password plaintext (when signing up and when logging in), but only store it hashed and salted.

    • iamak@infosec.pubOP
      link
      fedilink
      English
      arrow-up
      2
      arrow-down
      1
      ·
      edit-2
      1 year ago

      Why not hash it client side? Edit: Isn’t SSL vulnerable to MITM attacks? (I am a noob in this field)

      • _zi@infosec.pub
        link
        fedilink
        English
        arrow-up
        14
        ·
        1 year ago

        Figured I’d expand on something Alex said in response to you.

        Client side should not hash the password which I am fairly sure would allow pass-the-hash, but don’t quote me on that.

        Basically hashing it on the client doesn’t solve the problem it just shifts it a bit. Instead of needing to capture and then send the plaintext password to the server. An attacker would simply need to capture and send the hash as generated by the client to the server. In both cases an attacker with access to the plain communication between client and server would have all the information necessary.

        Basically if you hash it on the client-side, you’ve just made the hash the password that needs to be protected as an attacker only needs to “pass the hash” to the server.


        That said you are raising a legitimate concern and its a great question that shows you’re starting to think about the issues at hand. Because, you’re right. When we send the password in plaintext at the application layer we are simply trusting that the communication channel is secure, and that is not a safe assumption.

        There is a bit of a rabbit hole regarding authentication schemes you can dive into and there is a scheme that adds a bit more onto the simple idea of just hashing the password on the client-side. Basically, the server provides a nonce (a one-time use value) to the client. The client hashes their password with this nonce included and sends the resultant hash back to the server to be validated. It kinda solves the issue of someone being able to read the communication as the hash being sent over the wire is only useful in response to that specific nonce for that specific user.

        The trade-off on this is that in-order for the server to be able to validate the response from the client, the server must have access to that same key-data the client hashed with the nonce, AKA passwords needs to be stored in a recoverable way. You increase security against a compromised communication channel, but also increased the damage that an attacker could do if they could leak the database.

        Going further down the rabbit hole, there is Salted Challenge-Response Authentication which takes a step towards alleviating this by storing a salted and hashed version of the password. And then providing the client the nonce as usual along with the salt and other information needed for the client to reproduce the version of the hash the server is storing. This does mean passwords are not in “plaintext” but it has in effect made the hashed version the password that should be protected. Anyone who compromises the database still has all the information necessary to generate the response for any nonce. They just couldn’t try for password reuse stuff like one could if it was actually recoverable.

        Ultimately, this comes down to what is the bigger threat. You can (somewhat) secure against a compromised communication channel (which is generally a targeted attack against only one user at a time), but it means that some server side vulnerabilities will be able to compromise every user account. In general, for web-apps I think you’re better off hardening the server-side and having mitigations like 2FA around sensitive actions to limit the damage just compromising the password could do.

        Also, if you really wanted to be more secure against communication channel issues, public key cryptography is a better tool for that, but has generally not be well supported for web-apps.

        • iamak@infosec.pubOP
          link
          fedilink
          English
          arrow-up
          2
          ·
          1 year ago

          First of all thanks for the very detailed response. I have a few questions.

          1. Like you said, why not use public key cryptography? Why is it not well supported for web-apps?

          2. Why not use something like Diffie-Hellman algorithm to share the password? Signal protocol uses ECDHE so I am assuming that it’s safe against mitm which the base Diffie-Hellman is vulnerable to (I might be wrong. I couldn’t find if it waa vulnerable or not).

          • 0x7d0@infosec.pub
            link
            fedilink
            English
            arrow-up
            4
            ·
            1 year ago

            You are describing TLS, which is commonly used for websites and web apps.

            Try the following command:

            openssl s_client -connect infosec.pub:443
            

            The public key, the authority that signed the certificate, and the cypher used will all be visible.

            For me, the cipher used is ECDHE-RSA-AES256-GCM-SHA384.

            • iamak@infosec.pubOP
              link
              fedilink
              English
              arrow-up
              2
              ·
              1 year ago

              Oh. Okay. I’ll check it out once. I’m pretty new to all this so I didn’t know this is how SSL works.

      • alex_02@infosec.pub
        link
        fedilink
        English
        arrow-up
        3
        ·
        1 year ago

        Most of the comments are misconceptions. SSL/TLS is supposed to create a tunnel on top of TCP. If implented correctly, it is supposed to connect, establish a session key, and anything going back and forth from server to client will be using the tunnel using a symmetric encryption. On client side usually your password will be sent plaintext before the server hashes it and checks against a db of hashes. Client side should not hash the password which I am fairly sure would allow pass-the-hash, but don’t quote me on that. Also, there is possiblity of MITM, but it requires specific conditions and isn’t like with how sslstrip or whatever was a while ago.

        I’m tired so I might be wrong about some of this stuff, but The cryptography SO has a lot of questions on how SSL/TLS works and I suggest googling how TLS works.

  • 0x7d0@infosec.pub
    link
    fedilink
    English
    arrow-up
    3
    ·
    1 year ago

    Passwords are always sent to the server, then it is hashed to check it against the value in the database. It’s also possible to view your password by inspecting login requests from other websites. TLS is used to secure it while in transit.

    Hashing is done as an extra measure of security in case the database is compromised. This measure of security would have been completely void if the server would accept password hash directly. You could log in as any user by using his compromised hash.

    • iamak@infosec.pubOP
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      1 year ago

      this measure of security would have been completely void…

      Why not hash it server side too? I’m asking because I’m curious

      • TheButtonJustSpins@infosec.pub
        link
        fedilink
        English
        arrow-up
        5
        ·
        1 year ago

        That doesn’t make any sense. If you hash it once on client and once on server, that means that your password, as far as the server knows, is the client-hashed password. Nothing has changed in terms of security. In fact, you could implement this yourself by hashing your password when creating it and when supplying it.

        • SWW13@lemmy.brief.guru
          link
          fedilink
          English
          arrow-up
          2
          ·
          1 year ago

          That’s actually a good thought though. It would prevent (clear text) password leaks from shitty / malicious websites. Having a standard for browsers to salt and hash password would have prevented a lot password leaks. On the other hand it could never be updated and we would most likely be stuck on md4 or something similarly broken.

        • iamak@infosec.pubOP
          link
          fedilink
          English
          arrow-up
          2
          ·
          1 year ago

          Okay. I am pretty new to this stuff so I’ll go and check out SSL/TLS. Thanks :)