I signed up kbin.social but have since decided to go all in on Lemmy. I’ve tried all day to delete my account on kbin but it won’t let me. Once I click the delete confirmation pop up it simply reloads the feed and keeps your account.

Be warned. Currently you have no control over your data there. I think that settles it for me. I won’t be using that service again.

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

    One thing that definitely worries me with federation in general is the barrier to entry to hosting an instance is low, by design. On one hand this is great, but on the other hand it means just about anyone can spin up an instance and collect usernames, passwords, emails, etc. from anyone who signs up

    I know this is obviously no better than an single giant corporation who can do that. But it’s interesting to think about.

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

      I am once again reminded of the always relevant XKCD comic

      I do see and understand the concern, and honestly, I don’t see a way around it. At some point, you have to supply some information to access services, especially if you want any sort of customization to your experience. I guess if you are really concerned about it, don’t use that email/password/username combo anywhere else.

      Edit: Apologies, I am still figuring out how formatting works here.

    • HeartyBeast@fedia.io
      link
      fedilink
      arrow-up
      6
      ·
      1 year ago

      Remember folks, use a password manager and get it to create a random strong password for every site you use

    • Communist@beehaw.org
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 year ago

      I believe the passwords are stored as hashes, not sent directly to the server, at least I certainly hope so.

      • heartlessevil@lemmy.one
        link
        fedilink
        English
        arrow-up
        6
        ·
        1 year ago

        They’re sent directly to the server and stored as hashes. There’s nothing stopping someone from logging the plaintext password, or removing the hash mechanism, though. Make sure to follow best practices and use a unique password on every website.

        • Communist@beehaw.org
          link
          fedilink
          English
          arrow-up
          1
          ·
          edit-2
          1 year ago

          Oh jeeze, I guess the hashing system can’t work locally because then we’d know how the hashing works and could crack it, darn.

          edit: wait no, that’s stupid, why couldn’t it work this way?

          • roseh@lemmy.blahaj.zone
            link
            fedilink
            English
            arrow-up
            3
            ·
            1 year ago

            Hashing could happen client-side, but there’s not much of a difference. If you’re using HTTPS, then all traffic to the server is end-to-end encrypted anyway.

            At some point you have to trust the website that you’re connecting to, but obviously don’t re-use passwords, use a password manager, etc etc

          • Salamander@mander.xyz
            link
            fedilink
            English
            arrow-up
            3
            ·
            edit-2
            1 year ago

            A few years ago the plain text passwords would show up in the logs. That has been changed since then, but a malicious instance admin can easily revert this change and keep a log of plaintext passwords.

            A developer explained to me that adding client-side hashing would be problematic because different clients might do the hashing in different ways, and that the desired solution is to add OAuth at some point. There is also a bit more discussion about this in that thread: https://lemmy.ml/comment/97830

            I lack the technical knowledge in client-side hashing to explain why this is the case, but as far as I can tell client-side hashing is not common at all. The standard is to hash the passwords server-side.

            I do think that it is important to be aware of what a malicious instance admin can potentially do: they can log your plain-text password, see your e-mail and correlate it to your IP, look at what posts you like/dislike, and read your non-encrypted private messages. But these are not “Lemmy” problems, as these are general issues when it comes to trusting the servers of the sites that you create an account in.

            An important benefit of Lemmy is that you can actually set up your own server or use the server of someone who you really trust, and you can use it to interact with the rest of the instances. It is also possible to create an account without providing an e-mail, a phone number is not required, and you can usually access instances via a VPN or Tor. These are not a common luxuries when it comes to other sites.

            Using unsafe passwords is dangerous in a lemmy instance, but it is dangerous anywhere.

          • kimpilled@infosec.pub
            link
            fedilink
            English
            arrow-up
            2
            ·
            1 year ago

            Hashing on the client side creates a “pass the hash” vulnerability. What you’ve done in that case is made the hash itself the password, because that’s all the client needs to pass to the server to authenticate. This means that if those hashes are leaked, they can be immediately used to access the server instead of being cracked first.

            https://en.wikipedia.org/wiki/Pass_the_hash

          • z2k_@lemmy.nz
            link
            fedilink
            English
            arrow-up
            1
            ·
            1 year ago

            If passwords are hashed on the client side and sent to the server to authenticate, then all an attacker would need is the password hash and not the original password to authenticate. So it could protect your original password but not your account.