I noticed that there were some accounts that were hijacked by the instance owners. All the posts from that user were then edited to say what happened.
This kind of surprised me, I figured instances could delete posts, but not edit them. So how much control do they have?
I assume they can’t see my password (hopefully). Can they post in my name? Do they have all the access to my posts to foreign instances that they do over local posts?
Edit: thanks for all the responses everyone! I’ve wanted my own instance for a while, but maybe I’ll get on it now
Just to correct the people who say they can’t see your password - this is only true if they’re running a stock copy of lemmy, which hashes passwords in the database.
They’re free to modify their instance however they want, including storing unencrypted passwords or emailing your password on registration to a bot farm.
Always use a unique password for every site you use.
Before people get worried about this, this is how literally any online service works. If you have an account anywhere, you trusted that service to not record your password.
Only exception is oauth, which actually might be a good idea for Lemmy.
An instance owner having access to the database can surely change the password to access the account and then change it back. If you’re the server owner, you can do anything you want directly on the database.
Yes but if I was a dick, I’d just harvest their passwords silently and then try them on other websites.
An instance owner can just add a session token of their own, wouldn’t even need to alter the password. You would never know.
Or even modifying the login page to send and store unencrypted passwords to get passwords from people who already registered long ago
Oh boy, I have a bad feeling about this
The passwords are hashed (AFAIK), but the instance admin has effectively full control of any and all data originating on their instance, right down to the database level.
There has to be some level of guaranteed trust for any instance to work. And in some capacity there is inherent trust across the entire Fediverse that instances federating content are to be trustworthy. It’s no different than any other forum from the old web days- there’s zero guarantees and there’s no way around it.
They have full control over the account. Since they control the server, they can modify the database to do whatever they want.
Yup, simple as changing the password hash to their own and then logging in with their known password.
Or even simpler, just edit it directly in the database.
-
Password hashing occurs server-side. Even without removing the hashing step an admin can intercept the plaintext password during login. Use unique safe passwords.
-
An admin can intercept the jwt authentication cookie and use any account that lives in the instance.
-
Private messages are stored as plaintext in the database
-
Admins can see who upvotes/downvotes what
-
These are not things that are unique to Lemmy. This is common.
-
To avoid having to trust your admin, run an instance.
Quick note,
this is note unique to Lemmy/Fediverse. Reddit admin or twitter admin (and even gmail) can also read your MP, see the hash of your password and remove your comments. Reading your MP is even part of their business model so they can show you personalized ads.
There is definitely a probability to deal with a non reliable instance admin, but not less than with any other social media, and in principle they collect even less data
Technically that’s true.
To build trust and adhere to law, corporations will usually have processes and regulations in place that determine which employees can access and modify what. That is why spez modifying user comments is such a big deal. It showed that Reddit is not to be trusted. Nevertheless, for corporations that value customers trust, any employee who does not adhere to these procedures risks their employment.
On smallish fediverse instances none of these procedures need to be in place, the admin is bound only by his own moral code.
This is true. However keep in mind that instances survive on reputation. As soon as something like this came out, which is inevitable with time, nobody will trust that instance, or the person running that instance, again. And people are usually quite quick to find this out as already demonstrated by other online services. Hiding is very difficult. Even worse, once your reputation falls, people can move to a more respectful server and continue participating in the network, so in the end it’s a losing game for the instance owner. Password safety obviously applies, but if you take a look at big social media privacy and terms, a little password manager in my personal opinion is preferable.
There is definitely a probability to deal with a non reliable instance admin, but not less than with any other social media, and in principle they collect even less data
Yeah. You can see the cookies that are stored by a site by right-clicking on the site, going to “inspect”, and the clicking “Storage”. By default, the only cookie that Lemmy has is an jwt cookie used to authenticate your user.
You are not asked for a phone number to be here. Providing an e-mail is often optional and even discouraged by some instances. When you want to send a private message through the site you get a message discouraging from doing that and encouraging to try to use an encrypted chat application instead, such as matrix.
The original Lemmy instance (lemmy.ml) is a community for FOSS and Privacy enthusiasts. What is asks from a user and what it does with the data is what it needs to be functional. Lemmy lets you take any proactive step that you would like to take to protect your privacy - use a VPN or Tor, use safe passwords, use a unique identity, and don’t provide any personal information. There are no built-in features to block you or discourage you from doing that. Lemmy never asks for your location, nor does it keep any logs of what content you visit, nor does it try to run any analytics on you. But even if that is not enough for you, the fediverse doesn’t lock you out, you can set up an instance or even create a new program to interact and communicate only precisely what you want to communicate via activity pub.
I’m assuming votes are all federated, so I think any instance admin would be able to see who voted in which direction for any post that gets federated to their instance, no? Or is it just the vote count that is federated?
I remember seeing someone listing everyone who voted, so I think the votes themself are federated.
Might even be accessible via the API so any frontend can list them, but that’s just a guess.
That is correct, any admin can check the votes on all posts and comments federated to their instance.
I kinda hope they don’t have an API for that. I really didn’t like it on reddit when two people would be having a debate on a topic, and one person would search the other person’s comment history to find something to attack their character on to hurt their credibility. I think debates should be handled using relevant points about the topic being discussed. Attempts to attack character are very underhanded. It’s how politicians debate. It almost like admitting that you couldn’t make a better point than your opponent, so you had to stoop to that level.
I think having an API for votes and front ends that showed votes would encourage people to do exactly that here. If front ends started showing that info, I think it would discourage lurkers from voting, which I’m not sure we want.
Obviously there’s very little that could or even should be done about admins seeing that info. Admins have full visibility and manipulation power over the DB, and I feel like this wouldn’t even make the list of improvements that I think lemmy needs right now. Admins just sort of need to be trusted or people will leave your instance.
No, there is no API to get the votes (https://join-lemmy.org/api/). If my understanding is correct, now that I upvoted your comment my instance will push that information. I’m not sure whether it pushes it to dandroid.app first or to all instances, saying basically “Sal@mander.xyz upvoted https://dandroid.app/comment/441785”, and so every instance that has that comment can save my user ID in the “upvote” list of that comment, and that upvote is counted.
If only the vote direction was federated, then it would be very easy for me to spam the message “Upvote https://dandroid.app/comment/441785”. I would not even need to create an instance for that, I just need to speak ActivityPub. And it would be more difficult to detect that I am doing that, because the database would only hold the vote count.
I don’t think there is a way to ask an instance to reveal this list. You can only get it by directly querying the database if you have access to it. This is why if you fetch an older post or comment, it will arrive with a single or zero votes.
The votes themselves are the federated action.
If you fetch an old post, your instance will not see the previous voters. After that, whenever a user votes the instance will get the message “User X@instance upvoted/downvoted post Y” and the vote will be added to the database with the voter’s user ID and counted.
This has a practical function. If you don’t keep a list specifying who voted for what, it would be much easier to fake votes from one instance to another by simply communicating the message “Downvote post Y”. With the current method it is still possible to create a lot of fake accounts and mass-vote, but at least you can get a better insight when looking at the database if the votes are associated with accounts with no activity from a single instance.
There are some federated platforms that will show who likes / dislikes something. I know that friendica used to do this - I have not checked if it still does. So it is not only admins who can see this, this is is basically open information in the fediverse.
Can you recommend a good free web host for running your own instance? I haven’t dabbled in web development in over 15 years now, so I’m kinda out of the loop.
I’m not sure about Web Hosting. Many of us use a dedicated virtual private server (VPS)
I use https://serverspace.io, I think Lemmy.ml is hosted with https://www.hetzner.com/
These are servers that you access via SSH and can install the instance inside of it. I personally install using docker compose, but there are some other methods that are claimed to be easier. The cost starts at ~$5 / month. Currently I pay about $15 / month. You would then rent the domain name from a domain name registrar (I use namecheap.com) and ask them to point the domain name to your server’s IP address.
I looked into it and gave up after half a day of trying. I can’t figure out how this SSH thing works at all.
I’m used to CPanel and uploading files via FTP. I can code some CSS and manage a MySQL server, but this modern era of web development goes over my head. Apparently now you have to pick a Linux distro and install it, instead of it just being ready to go for you. (At least that’s how it worked with Oracle).
Thanks for trying to help but I’m too old for this shit now. I don’t even know what “docker compose” means. I’ve read the official documentation and looked at tutorials, but it’s all a foreign language to me now. Like I said, in my day you just uploaded the files via FTP, changed some lines in a config file, redirected your .com to your nameservers in CPanel, and you were good to go. Installing an instance is 10x more difficult. Wasted $9 on a domain for nothing… *sigh*
Oracle has a pretty decent free tier.
Thanks
deleted by creator
-
as instance admins, they have access to the database, so they straight up can edit any data.
only thing they can’t do is view your password (hashed), but they can replace the hash by one of a known pw.
so you must have some trust in your instance owner, again whats good with the fediverse is that you can just start your own instance, and then the best they can do is defederate from you or ban you.
It’s important to note that your password has to be stored someway, no matter what, no matter where. How it’s stored can be varied, from hashed (think encrypted) to cleartext. I’m assuming lemmy is using hashed passwords, so if you’re concerned about your password being available to an instance owner, admin, or potential attackers, then you’ll need to follow safe password guidelines. Changing the concept from passwords to passphrases is a great start.
Always keep in mind, if the data isn’t stored on your device, you do not technically own that data. You have to trust the owners to be good data custodians and treat the data you give them as if it were their own private data.
I’ll leave this now internet-ancient sacred image for future passphrase converts.
Just to be clear, you’re talking about Lemmy. There are authentication mechanisms in which the instance never has access to your password, in any form.
I wish I could upvote your comment multiple times for the XKCD comic on this. And to anyone curious, there are many tools which will generate XKCD passwords for you. One’s called “correcthorse”, and there’s another called “correctpony”. A github search for “xkcd password” should turn up several.
Why can’t the admin just change the Lemmy source code to not hash anymore?
Are you asking why can’t a bad admin change the code so that they can more easily steal the password? They could, and this is what OP was saying about trusting the admin. What I was saying was that there are client-side auth mechanisms, where the admin never has access to the password. But Lemmy could also implement OAuth, or a similar federated identity pattern, where (again) the Lemmy admin never has access to any form of the password.
I’ve never run a Lemmy instance; it’s possible the server software supports SSO but few instances use it.
A lot of people here mentioned that passwords are hashed, but unless I missed it no one pointed out the following:
The admin of your instance controls your login form and they can pull your password when you log in. So, as others mentioned: always use unique passwords, never ever reuse them.
In general a server admin can do anything they want on their own instance.
Federation wise I’d say if your home instance is the bad actor you are screwed, if it’s another instance then their capabilities for mischief hare probably (hopefully?) more limited. And any such action would likely cause a swift defederation of the malicious instance
Exactly this, I don’t see why everyone is so obsessed with cracking the passwords in the database.
Evil instance admin guide:
- Kill the session tokens for an account, logging them out
- Attach wireshark/tshark to the docker network that’s hosting the Lemmy backend
- Wait for the user to submit their password. You will get it in plaintext.
This won’t work against people who never log in again. Active users will.
If the admin just wants to impersonate you… they can just generate a session under your account name and do that. 2FA doesn’t stop them, difficult passwords doesn’t stop them, OAuth doesn’t stop them.
There’s no way for other admins validate if someone is actually getting hacked by their admin or if they’re just being dicks spreading rumours.
The best you can do is create a new account and always cryptogroahically sign your messages using a key stored offline on your computer…There are PGP applications for every platform. If you and someone you DM both have PGP keys, you can even use that to send end-to-end encrypted messages. If everyone does that, unsigned posts can essentially he discarded by the community as fakes.
This won’t stop the admin from faking your account downvoting everyone, subscribing you to pedo communities, or messing with your account. The admin can also post things like “I don’t have my PGP key on this phone, I’ll sign this later” and delete any of your messages that indicate any protest against the admin’s actions. The admin can even strip the signature from all of your previous posts and replace with with a different signature using a key of theirs. Only if you and everyone around you know that your messages should always be signed by a certain key, are you free from admin interference.
Just like every other online platform (that isn’t run by cryptobros).
You can only avoid all of this by hosting stuff yourself and being your own admin.
On which instance did this stuff happen? I’d like to defederate for sure.
Your instance owner can easily change your password and log in as you.
You can counter that by using multiple accounts from different instances. Use at least 3, if one is compromised, you have the other 2 to counter any impersonation attempts. Make sure you link your other instance profiles in every profile description page. Then use an archive website to save each profile page. If any 1 account is compromised, use the other 2 to tell people the account has been taken over by someone else. And you have the archived profile page that links to the alt accounts to verify that it is indeed your 2 alts.
Just want to add some detail to what everyone is saying about passwords. From what I understand, by default, Lemmy uses the bcrypt hashing function to store passwords. This is a fantastic choice. The great thing about hashing a password is that there is no way to go from the hash back to the password. It’s mathematically impossible, since the process loses information. This is different from encryption where there is a mathematical way to recover the original data from the ciphertext.
So great, no recovering passwords! Well…Not exactly. While there is no way to calculate the password from the hash, the neat thing about hashing algorithms is that the same input, run through the same function, will always produce the same output. And since we know Lemmy uses bcrypt, and a sufficiently motivated attacker could look at the code and figure out all the variables that goes into the bcrypt function in Lemmy, an attacker can know exactly how your password was hashed. They can make a guess at your password, run it through the function and see if that matches the hash stored in the database (this is actually how you are authenticated when logging in). If they do that a lot of times, they might be able to guess your password this way. This is basic brute forcing of a password. and there are pre-built tools to do this.
Extending that brute force attack further. People are bad at picking passwords. Most peoples’ passwords follow similar patterns and have similar words in them. If you get such a list of words and use it to make up the guesses using common patterns, this can greatly speed up the guessing of passwords. And, wouldn’t you know it, this also has pre-built lists and tools to do. It’s dead simple. Take a class on hacking and you’ll likely be doing this on day 1. Day 2 if the instructor eats up a lot of time going over the syllabus.
So, what’s the defense against this? Well, two things:
- Unique passwords - and not just a common password with an easy to guess change. Having “Password1” here and “Password2” over there isn’t smart, no matter how smart your version of “Password” is. I mean real, complex, unique passwords. Give up memorizing them, or even knowing what they are. Get a good password vault (e.g. KeePass or BitWarden), and use that to both generate and store passwords. Protect that with a long passphrase (a sentence, with capitalization and punctuation) which you can remember.
- Multi-factor authentication (MFA) - This can be limited to stuff which you really care about. If someone hacks your PornHub account, you probably don’t care. If someone hacks your bank account, you probably do care. There’s a whole discussion on MFA and what types are better; but, if you can enable it on a site you don’t want compromised, use what’s offered.
That is a lot of words to say ‘they can’t see your password, but they can try to guess it. Make a secure password and you won’t have any problems’
That’s a fair critique. However, I find the advice “Make a secure [unique] password and you won’t have any problem” is often given, without any explanation as to “why” that advice is given. As someone who likes to know the “why” behind things like this, I like to give that detail as well.
Lemmy needs GPG signatures!
Admins would still be able to change your key, wouldn’t they?
Sure but you can also post your public key somewhere else for people to verify.
Or instances could store public keys of users from other instances, sorta like blockchain validation.
Public/private keys are already part of the ActivityPub validation mechanism. Every user/community/server has their own unique keys.
Your public key is:
-----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6yo7z/lmj/W1G5+/FnIg\nVqqLWq/h5MU88eUB6DaJkEqaz0hTslG21MaMT0KmgAnef0PwvchnPDryIUKXHY6z\nk34KakBUpgZWbGEeqm0r4YdRVHU5a+l8Rbb4lH5pp0I1IdiGftMYuYcON92V8F8H\n4VRKMNe8kCwk8VbVovigqrNW288juqAeXNG9xanNE3a5Bjke6+HlG0fa1lU2xoIL\nevpqA85Xf/sd0qhrk4gt4Lqcwp7bNt6liDNubAnWRjeDbL8hmbkz/D047Ffw/zD8\nfdfkgPepF2YshvtuudhdKaAfM4fG0X+L+D0ujHdQZUMj89lRRRxT0TmzQniIyHJj\nAQIDAQAB -----END PUBLIC KEY-----I found it using this command:
curl -H "Accept: application/activity+json" https://lemmy.dbzer0.com/u/DavyJonesThis key is stored and under the control of your server admin, of course. It mostly exists to protect other people from impersonating you in the federated network.
There’s no reason why you couldn’t just wrap the messages you post in a PGP signature, though.
That could be an interesting idea. It might be needed at some point down the line
deleted by creator
They literally created the webpage. Always assume the owner has absolute power over everything.
This is how any website is. Reddit can do the same thing, it’s why some users who edited all their comments there had them reverted back.
This is an opportunity to learn how web services work, at least.
They can’t see your password in a usable state, but have control over everything else.
