Have been wondering about this in terms of how safe/secure it may be to use them. Not that a Lemmy account is exactly something to fret a ton over, but I always appreciate a little more peace of mind.

Searching through here I found where Alexandrite’s dev gives a rundown to someone asking in regards to their work, but I didn’t surface similar for others. I’ve tried running some broader searches but haven’t had a ton of luck, so thought I’d ask.

  • silas@programming.dev
    link
    fedilink
    English
    arrow-up
    13
    ·
    1 year ago

    I’m building !lemmynade@lemm.ee and can answer any questions. Each app and client handles differently, but for Lemmynade:

    1. You type in your instance, username/email, and password into Lemmynade and tap “Submit”
    2. After tapping submit, your username and password is sent to Lemmynade’s backend server to process securely (this is more secure than doing some of the next steps directly in your browser)
    3. Lemmynade’s backend server immediately verifies that your instance exists and that it’s a valid Lemmy instance (you don’t want to blindly send your password to some random server!)
    4. If the instance is a valid Lemmy instance, then your username and password is sent directly to your instance over an encrypted connection.
    5. If your username and password are valid, then your instance sends back a token (a bunch of random letters and numbers) to Lemmynade. This secure token can be used in place of your password so your actual password doesn’t have to be stored anywhere.
    6. Lemmynade then takes that token and saves it in in an http-only cookie on your own device. When it needs to authenticate or log in again, it uses this secure token to do it so you don’t have to keep typing in your password.

    Throughout this process, nothing is stored, logged, or recorded anywhere. The only thing stored is the secure token, and that secure token is only saved on your own device. Lemmynade or anyone else cannot access your account unless they have access to your specific device.

    There’s many more layers to this, but hopefully that explains the general idea. The main danger with the current method of authentication is that you are providing your raw password to a third party, meaning if someone wanted to be malicious it’s fairly easy to do.

    A much better authentication method is called OAuth. With OAuth, you never give your password directly to the third party, so it’s far safer. A lot of us devs are pushing for this and hoping to see this down the road as it would give much more peace of mind to everyone. It’s only up from here!

    • ALostInquirer@lemm.eeOP
      link
      fedilink
      arrow-up
      5
      ·
      1 year ago

      Thanks! Appreciate this for Lemmynade’s specific process.

      The main danger with the current method of authentication is that you are providing your raw password to a third party, meaning if someone wanted to be malicious it’s fairly easy to do.

      I was thinking that might be the case, but wasn’t sure if it might be some slight tech-paranoia on my part. Was particularly surprised when the apps I’ve looked into didn’t have a redirect to your chosen instance to sign in via browser or something and do a sort of hand off back to the app, but I’m guessing that may have something to do with the current state of Lemmy’s development.

      • silas@programming.dev
        link
        fedilink
        English
        arrow-up
        6
        ·
        edit-2
        1 year ago

        Yep, that’s OAuth you’re talking about! It needs to be implemented into Lemmy directly first before any apps or clients can upgrade to it. I’m not too clear where we are in the conversation, but I know one point discussed is that OAuth (and especially another method called OIDC) lean towards something centralized for authentication, and that goes against the decentralized nature of Lemmy.

        For now, the best things you can do as a user is:

        1. Decide which apps, clients, and developers you trust. Inspect privacy policies, ask questions, and review code if possible
        2. Enable 2-factor authentication
        3. Use a throwaway or aliased email (through SimpleLogin or similar)
        4. Use a unique password—one that isn’t used for any other accounts you have