I remember hearing before that it’s a sign they are storing your info unencrypted but I never checked.

Is this true? I was logging into a .gov website and noticed it does that.

  • JoshCodes@programming.devEnglish
    1·
    23 days ago

    So ultimately hashing an email address could be a good thing, but its a matter of half measures. Sure, you can perform a basic hash before putting it in the database, but if we assume hashing is performed to prevent it being read by an attacker, why bother unless youre doing it properly?

    Passwords, being more sensitive, should only be compared once finished being entered, so you can afford to run all the hashing, salting etc that is a requirement to keep the passwords safe.

    If you were going to hash the email to the same standard, it becomes harder to retrieve and display, so when the user wants to look at their profile in the ui, you have to run an intense cryptographic algorithm just to display the email. Or if you want to contact the customer, or any other use for their email. Hence, people dont bother.

    • CameronDev@programming.devEnglish
      7·
      23 days ago

      Hashing is completely irreversible. You cannot hash an email address and then unhash it. At most you can brute-force guess the email until the hash matches, but this is basically impossible.

      Hashing the email address would break one of the main reasons to use an email address - the ability to send emails to users.

      Encrypting email addresses is fine, but you wouldnt compare the encrypted data, you’d just decrypt and compare the original email address.

    • hitmyspot@aussie.zoneEnglish
      13·
      23 days ago

      The email can be stored in 2 parts in the database. One hashed as a login and once as an email address to send to.

      Sure, if your database is compromised, it’s still public but it still makes the log in process more secure.

      • Consti@lemmy.worldEnglish
        2·
        23 days ago

        The only reason we store passwords in hashed form is to prevent damage from leaks. How would storing it twice make login more secure? The client sends both the email and the password in plaintext, everything else is on the server’s side. The client does not care or know how the data is stored (or if it is stored at all). So storing it twice does nothing except waste disk space.

        • hitmyspot@aussie.zoneEnglish
          1·
          23 days ago

          It only helps if log in details are siloed. The storage space taken is negligible.

          It’s also possible to hash client side, so that the log in process does not access data, like the email but just confirms matching hashes for received data.

          • Consti@lemmy.worldEnglish
            2·
            23 days ago

            Why the fuck would the client confirm the hashes? Don’t trust the client. The server handles the login; an attacker can just write a lying client “yeah sure I know this guy, it’s hitmyspot, now let me in”.

            • hitmyspot@aussie.zoneEnglish
              1·
              23 days ago

              The client doesn’t confirm the hash. The client hashes and sends the hashed data. The server confirms.

              Omg, how do you know my login? ;)

              • Consti@lemmy.worldEnglish
                2·
                23 days ago

                The client doesn’t hash. The client needs to send the plain text. Otherwise, that’s a security problem; the server needs to confirm the user knows the actual password, so the server needs to compute the hash and compare. If the client sent the hash, then there was no reason to compute hashes in the first place, because the attacker can just send the leaked hash (the reason to hash it is to avoid that the leak can be used to log in directly).

                • hitmyspot@aussie.zoneEnglish
                  1·
                  23 days ago

                  No client side hashing is possible and secure.

                  If you look at sending plain text under SSL, it’s almost the same thing.

                  The password hashed under a mutually known algorithm that is not reversible is just as good as the plaintext.

                  What’s particularly interesting right now is manipulation of data that is encrypted to allow the same output (encrypted) as unencrypted data.

                  The point of sending hashes info from the client is that each site uses a different key, even if publicly available. This means that leaked login data cannot be compared or matched across different leaks.

                  • Consti@lemmy.worldEnglish
                    2·
                    23 days ago

                    No, it is not. If the server accepts the hash from an untrusted source (the client), then that’s equivalent to not using hashes at all. The reason why we hash is so a database leak does not allow malicious actors to login directly. If the server accepts a hash, that means it only does hash_from_client == hash_from_db, meaning that’s the same as doing password_from_client == password_from_db in terms of security. This is because the client can just send the hash from the DB, the user does not actually need to know the password, hence your proposal is equivalent to not using hashes at all in terms of security.

                    The point of sending hashes info from the client is that each site uses a different key, even if publicly available. This means that leaked login data cannot be compared or matched across different leaks.

                    That is for keyed hash functions, which is not typically done for passwords (but peppers are sometimes used, which helps similarly). This does not prevent the above scenario, though, because the leaked hash can still be used on that site. Sending hashes is a bad idea, the hash should always be computed in a trusted environment to ensure the user actually knows the password.