EDIT: I’m putting this up front so it’s the FIRST thing you see and read: I WAS WRONG I ASSUMED (and I know better) that it wasn’t possible for me to have 3000 accounts created within a day or two of going live. I ASSUMED what I saw was accounts that were NOT local, I WAS WRONG I created a process to remove the bot accounts from my database without crashing my site. I have tested and it looks like all functions are working. If you need help because you suddenly have thousands more accounts than you would suspect ask me for the procedure. I’ll gladly provide it.

I was able to identify bot accounts by looking at creation times. They accounts are grouped by “batches” where the account creation times are within seconds of each other. That’s not typically going to happen with random humans creating accounts.

I used a tool to see how many users my site had. Once I saw the count was larger than expected, I wondered who these users were. I checked the database table and saw a huge list. I know for a fact that all these users are not on my instance. I was able to confirm that the database includes email address and password hash. This SHOULD mean that if someone tries to login, and their authentication information is sitting in my database, they can login at my site locally, correct? I only ask because I did not find an entry anywhere that lists a “home” instance for them to log in to. Am I correct in understanding that accounts are distributed like communities are?

4 points

We’re entering a world where corporate media - be that music, television, movies, books, even political messaging - will soon be 99% algorithm driven. Train once, repeat ad infinitum. They already have an idea of how long it takes for public appetite to grow tired of the familiar and start craving new, and that will guide how often the algorithm should be re-trained. Meanwhile we, the consumers, will be kept fat and happy in our metaphorical pens being dished up a constant supply of delicious, processed food entertainment manipulation while they milk us for every dollar, minute, and vote that they can.

permalink
report
reply
4 points

How are you so certain that they’re not on your instance? I see that your sign up form is open. There’ve been other reports that spambots have discovered Lemmy and are signing up on instances en masse.

permalink
report
reply
2 points

At this point, I’m not certain anymore. Luckily all the accounts use values that are easy to identify them. I’ll figure out how to remove them. Sorry for the false alarm work.

permalink
report
parent
reply
2 points
*

People from different instances are not able to login on your instance. For example you might see me in the people table, but local should be false. People registered on your instance shows up on local_users and on people with local set to true.

There have been mass registrations going on recently. Imagine my surprise when my 3 people instance had 460 users but no one online today. Took my instance down to investigate and deleted all local users in person table except the known users. Not the cleanest way to do it but I don’t think I broke anything :D

permalink
report
reply

I think it’s actually pretty clean. Thanks to the references on the person table all related entries in the database like posts, comments, etc. also get deleted if there are any. It’s better than banning all those fake users and thereby spamming the modlog of all instances that federate with you 😅

permalink
report
parent
reply
2 points
*

That reminds me of an incident we had.
On of our customers sites suddenly had hundred’s of new signups.

It turns out a hacker tried to fuzz the site,
and since there was no captcha/spam protection in the signup form he created hundred’s of accounts.

permalink
report
parent
reply
2 points

I created a process to remove the bot accounts from my database without crashing my site. I have tested and it looks like all functions are working. If you need help because you suddenly have thousands more accounts than you would suspect ask me for the procedure. I’ll gladly provide it.

I was able to identify bot accounts by looking at creation times. They accounts are grouped by “batches” where the account creation times are within seconds of each other. That’s not typically going to happen with random humans creating accounts.

permalink
report
parent
reply
1 point

Dont worry, it happened years ago.

I wouldn’t be taking about that kind of stuff if it was ongoing or recent.

permalink
report
parent
reply
13 points

I was able to confirm that the database includes email address and password hash.

Uhhhh not loving that if true… Why would password hashes need to be sent all over the planet…? That’s a security bomb just ticking.

Shouldn’t each instance only need to be tracking user Metadata, with only the original users instance handling authentication…? After all my personal interaction is happening on my instance.

permalink
report
reply
11 points
*

You can see in the source that password hashes are not sent over activitypub.

permalink
report
parent
reply
7 points

Ok, I’ve looked at the source provided and don’t see an e-mail field either. The account e-mail is also limited to your own instance, correct? This thread was making me mildly concerned that e-mails were being shared when federating between instances.

permalink
report
parent
reply
2 points

Thank you for linking the source! Seems OP was just mistaken about what they were seeing.

permalink
report
parent
reply
3 points
*

Are you looking at person or local_user? The former includes all (known) users across instances and doesn’t include password hash. It has private key column but that should be empty for non-local users. Password hash is only on local_user table which like it says is only local users. If you’re seeing more entries in local_user than you expect that seems more concerning, maybe related to the recently disclosed exploit?

permalink
report
reply
4 points
*

SELECT * from local_user; provides a list of users that has a password_encrypted field. That list is exactly equal (all the same accounts are listed) to what I get from: select   p.name,   p.display_name,   a.person_id,   a.email,   a.email_verified,   a.accepted_application from   local_user a,   person p where   a.person_id = p.id;

So I can see a persons a.email (email address), a.person_id, and their password_encrypted (hash) by correlating these tables, can I not?

These accounts are NOT ALL local to my server… So I MUST be being passed hashes, right?

permalink
report
parent
reply
3 points

Can you add p.local=false to that query?

permalink
report
parent
reply
1 point
*

I always assume I’m wrong first, I may have put that in the wrong spot. Where should I put that in the query? I put it under the Select statement.

permalink
report
parent
reply

Technology

!technology@beehaw.org

Create post

A nice place to discuss rumors, happenings, innovations, and challenges in the technology sphere. We also welcome discussions on the intersections of technology and society. If it’s technological news or discussion of technology, it probably belongs here.

Remember the overriding ethos on Beehaw: Be(e) Nice. Each user you encounter here is a person, and should be treated with kindness (even if they’re wrong, or use a Linux distro you don’t like). Personal attacks will not be tolerated.

Subcommunities on Beehaw:


This community’s icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.

Community stats

  • 2.8K

    Monthly active users

  • 3.4K

    Posts

  • 78K

    Comments