this post was submitted on 06 Dec 2023
19 points (95.2% liked)

Lemmy Apps

4992 readers
1 users here now

A home for discussion of Lemmy apps and tools for all platforms.

RULES:


An extensive list of Lemmy apps is available here:

LemmyApps.com

or lemmyapps.netlify.app


Visit our partner Communities!

Lemmy Plugins and Userscripts is a great place to enhance the Lemmy browsing experience. [email protected]

Lemmy Integrations is a community about all integrations with the lemmy API. Bots, Scripts, New Apps, etc. [email protected]

Lemmy Bots and Tools is a place to discuss and show off bots, tools, front ends, etc. you’re making that relate to lemmy. [email protected]

Lemmy App Development is a place for Lemmy builders to chat about building apps, clients, tools and bots for the Lemmy platform. [email protected]

founded 1 year ago
MODERATORS
 

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.

all 7 comments
sorted by: hot top controversial new old
[–] silas 13 points 11 months ago (2 children)

I’m building [email protected] 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!

[–] [email protected] 5 points 11 months ago (1 children)

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 6 points 11 months ago* (last edited 11 months 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
[–] [email protected] 1 points 10 months ago

Quiblr works essentially the same way. But I query the instance list so users cannot input a bad instance name

[–] [email protected] 6 points 11 months ago* (last edited 11 months ago)

Use 2FA if available. This goes a long way. My instance supports it (TOTP). Not sure if it's standard across instances.

Jerboa (Lemmy client for Android) also supports it.

[–] [email protected] 6 points 11 months ago

I'm the developer of a (still beta) mobile app for Lemmy and I don't have a backend, the credentials are inserted by the user in the app and are sent to the Lemmy instance they are using directly with no steps in between.

Instance name verification is done by just calling a public (non authenticated) API like the community list and seeing if this healthcheck passes, whereas authentication is done by the Lemmy instance itself which returns an error if the user does not exist or the password is wrong.

The login API provides a token, as explained by other devs in this thread, which is saved in the app database (but the database is encrypted with a key randomly generated on a per-install base on the device and local to that device only). This token is appended to the body (where specified) or auth header of the subsequent authenticated API calls, which are in turn encrypted too since it's HTTPS.