I think for a while leading up to the recent session stealing hack, there has been a massive amount of positivity from Lemmy users around all kinds of new Lemmy apps, frontends, and tools that have been popping up lately.

Positivity is great, but please be aware that basically all of these things work by asking for complete access to your account. When you enter your Lemmy password into any third party tool, they are not just getting access to your session (which is what was stolen from some users during the recent hack), they also get the ability to generate more sessions in the future without your knowledge. This means that even if an admin resets all sessions and kicks all users out, anybody with your password can of course still take over your account!

This isn’t to say that any current Lemmy app developers are for sure out to get you, but at this point, it’s quite clear that there are malicious folks out there. Creating a Lemmy app seems like a completely easy vector to attack users right now, considering how trusting everybody has been. So please be careful about what code you run on your devices, and who you trust with your credentials!

  • slazer2au@lemmy.world
    link
    fedilink
    English
    arrow-up
    81
    arrow-down
    3
    ·
    1 year ago

    This is why password managers are so heavily pushed. Imagine if you used the same password for Lemmy that you used for your email? Both are now compromised. A unique password for all accounts is the bare minimum you must do.

    • T156@lemmy.world
      link
      fedilink
      English
      arrow-up
      42
      ·
      1 year ago

      Although it is worth noting that the recent Lemmy hack didn’t come from a password compromise, but from session token harvesting, which a password change would not really protect against.

    • flames5123@lemmy.world
      link
      fedilink
      English
      arrow-up
      16
      ·
      1 year ago

      Lol this is not how the hack worked. JWT cookies are encrypted. They don’t contain your password at all. There was no way to reverse engineer from your cookie to your password.

      • usernotfound
        link
        fedilink
        English
        arrow-up
        3
        arrow-down
        1
        ·
        1 year ago

        Correct me if I’m wrong, but Lemmys tokens have no expiration, right? So they are effectively username and password combined.

        • flames5123@lemmy.world
          link
          fedilink
          English
          arrow-up
          6
          ·
          1 year ago

          The decoding algorithm can change, which is exactly what happened, invalidating all previously generated tokens. They cannot be decoded to a password though since they are encrypted, meaning shared passwords wouldn’t be an issue (though you should use a password manager to not have this issue in the first place).

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

            That’s not how tokens work. Tokens are (usually short-lived) credentials that are passed to a client after it authenticated e.g. with username + password. But the password is never contained in a token. They are also not encrypted, but signed, meaning the Lemmy instance can verify that the plain-text token ist authentic. Also, not the decoding algorithm has changed, but the signing key was rotated, meaning all JWTs created before the signing key rotation would not look authentic anymore

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

              Right. I was simplifying it by saying it was encrypted, but it’s just an auth token from the service after verifying that the user is authenticated.

              And correct. I’m just an idiot and didn’t do research to explain it, even though I’ve used JWT tokens in my applications before. Hahaha. Thanks for the detailed correction!