Automattic / wordpress-activitypub

ActivityPub for WordPress
https://wordpress.org/plugins/activitypub/
MIT License
496 stars 76 forks source link

Usernames vs. Nicknames #141

Open SndChaser opened 2 years ago

SndChaser commented 2 years ago

I would like to suggest that it is not a good idea to be publicly using the username as part of the URI for the ActivityPub plugin. Using the username is creating a potential vulnerability on sites that wish to use this plugin. In Wordpress usernames are the login ID's for user accounts. This means that the URI is exposing the user ID of accounts publicly.

Instead it would be better to use Nickname, and handle the lookup to map them to the Username. This way the account login ID is kept within the system and not made public.

pfefferle commented 2 years ago

the problem with the nickname is, that it is not unique and it might have spaces in it.

SndChaser commented 2 years ago

I think the uniqueness is something that should be addressed by the instance administrator... I find it highly unlikely that a WordPress instance is going to use the same nickname for multiple contributors / admins.

As for spaces, there are many cases where there are disallowed characters that need to be dealt with. That's kind of a coding 101 issue that has multiple solutions (substitution, deletion, etc.) If those options aren't acceptable, you could always add another field to the user record to add an ActivitySteam identifier.

No matter how you slice it, exposing the user ID of an account publicly is not a good idea.

pfefferle commented 2 years ago

I understand your point, but without using plugins, the username will always exposed with the Autor URL.

I think it is better to add an extra field to not upset long time WordPress users and to not force them to maybe change their nickname afterwards.

stale[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

pfefferle commented 2 years ago

Keep

ThomasKujawa commented 2 years ago

My username also contains dial tone and because of that there is an error when calling/searching.

@Thomas Kujawa@www.fachkraeftesicherer.de

cibersheep commented 1 year ago

the problem with the nickname is, that it is not unique and it might have spaces in it.

usernames can contain spaces as well. See https://github.com/pfefferle/wordpress-activitypub/issues/221

stiller-leser commented 1 year ago

the problem with the nickname is, that it is not unique and it might have spaces in it.

For me the not-uniqueness of the nickname would be very desirable. We have many people working on our site, but I would prefer if people could simply follow all entries from the team by following one nickname. Alternatively, it would be great if the display_name could be used.

pfefferle commented 1 year ago

The display_name brings the same Issues as the nickname... it could have spaces and is not unique...

stiller-leser commented 1 year ago

Hey,

thanks for the quick reply. That was unexpected in a very positive way. I understand that a space could be an issue, but same as the uniqueness, this should be something which should be manageable by the site admin.

I agree that potential usability issues could arise from this, but IMHO that's something a documentation entry would solve easily.

Alternatively: Is there a way to follow a whole blog?

sjlongland commented 1 year ago

@stiller-leser See issue #1. :-)

mediaformat commented 1 year ago

The other problem with display_name & nickname is they are user editable. If this happens it would break federation, and your followers servers would likely drop all sent messages.

stevenjaycohen commented 1 year ago

Shouldn't this be solved in code?

if (nickName)isUnique {
nickEligible=true;
}

If a nickname is not unique, shouldn't it just be greyed out as an option (along with an explanation which might encourage someone to come up with a unique nickname)?

The initial poster is correct in the assertion that mandating the use of actual usernames lessens WP security on every instance with this plugin active. So, any option that results in people not getting 50% of my login information just by looking at my ActivityPub handle should be explored.

stevenjaycohen commented 1 year ago

The other problem with display_name & nickname is they are user editable. If this happens it would break federation, and your followers servers would likely drop all sent messages.

Sure, so warn the end user? Lock the display or nick (if possible)? Allow an arbitrary name to be defined in the plugin and mapped to the account?

That last idea is probably the simplest and the most secure. To reiterate, as it stands, activating this plugin announces to the world 50% of the login data for every account on an instance. That is a major security consideration.

timnolte commented 1 year ago

Actually, I would refute the idea that using the username reduces anything security-wise. If you actually have a Mastodon, or any other Fediverse platform, account your identity is your username. Same was always true with even platforms such as Twitter. If you properly secure your accounts with good passwords and 2FA then all of this is pretty much moot.

stevenjaycohen commented 1 year ago

Same was always true with even platforms such as Twitter.

Correct, platforms like Twitter have decided to compromise security by forcing a username to be public. WordPress chose not to do this, hence one of the reasons DisplayName and NickName exist.

This is a WordPress plugin. Respecting a wordpress design choice while achieving integration would make more sense. This would be achieved most simply with a new table for ActivityPub username (which is then mapped to the account internally).

timnolte commented 1 year ago

No, security through obscurity is actually not real security, that is what you are pushing for. This makes this unnecessary complex for little actual benefit.

timnolte commented 1 year ago

Not to mention the fact, that unless you've taken extra precautions, if you simply go to the open REST endpoint of your WordPress site https://example.com/wp-json/wp/v2/users all of this data is exposed, by WordPress, by default.

stevenjaycohen commented 1 year ago

security through obscurity is actually not real security

You are missing the point. Exposing someone's username opens social engineering vectors for attackers that are only exposed by insisting that login data be made public.

Grab a username here, grab an email address there...

stevenjaycohen commented 1 year ago

Not to mention the fact, that unless you've taken extra precautions, if you simply go to the open REST endpoint of your WordPress site https://example.com/wp-json/wp/v2/users all of this data is exposed, by WordPress, by default.

I stand corrected.

sjlongland commented 1 year ago

So, if someone visits http://example.org/author/user; and user happens to be the nickname of multiple user accounts, how does Wordpress handle this? Does it just pick one user? Or does it merge everyone's posts together?

Why would following @user@example.org via ActivityPub not provide identical behaviour?

timnolte commented 1 year ago

@sjlongland so that is a very good point that ActivityPub should be following the same logic. Looking at the Core methods for the author permalink it is using the user_nicename, and looking at get_posts() and assuming the default would be to call that with author_name => user_nicename that would in fact mean that all posts for users with the same user_nicename would be returned.

In keeping with what WordPress Core does, I would say this logic should be maintained. Essentially, this Issue shouldn't be about anything to do with changing the URL, because that is already handled by WordPress.

pfefferle commented 1 year ago

As a quick fix: You can install the WebFinger plugin for WordPress, that already supports the user_nicename (hidden feature).

mediaformat commented 1 year ago

... user happens to be the nickname of multiple user accounts

This wouldn't happen since user_nicename is not the same as the user nickname, it is rather a url sanitized version of user_login.

From wp_insert_user()

  • user_login string The user's login username.
    • user_nicename string The URL-friendly user name.
    • nickname string The user's nickname. Default is the user's username.
cbzen commented 1 year ago

There are many Wordpress admins that have used their email addresses as a login and (required) email address. Which can not be changed. Or re-used. That exposes those site admin's email addresses in a very public way.

So is the plugin simply going to dictate that those admins create new email addresses, to create new Wordpress profiles, in order to get a second chance at creating a username that is not an email address?

That seems very restrictive. If a user loses access to that specific username profile, do they lose access to their ActivityPub feed? I feel there should be a way to recover (e.g. seed phrase) and migrate one's content to a new username.

timnolte commented 1 year ago

Migrating content is just the normal WordPress Core method of migration. When you delete a WordPress user you are prompted with the option to reassign the content to another user. I don't understand what the concern is here as there is nothing restrictive.

cbzen commented 1 year ago

Let me clarify the scenario because it's not about migrating content from one profile to a different profile. It's about changing the profile username and continuing to use the same email address associated with that profile.

Granted, this is a Wordpress restriction, but it's exacerbated with the ActivityPub plugin because the username is now public. (Most people don't care what the username is when it's private)

The ActivityPub plugin uses the profile username, and it becomes a major effort to change it. You can't simply create a new profile because you won't be able to use your existing email address. The next alternative is finding a plugin to do it. Or opening phpMyAdmin and performing surgery on the database.

Perhaps there is a solution I'm not seeing.

pfefferle commented 1 year ago

We have built in a possibility to change the username of the blog user and will be implementing the same possibility for author profiles in one of the next versions.

github-actions[bot] commented 10 months ago

This issue is stale because it has been open 120 days with no activity. Remove stale label or comment or this will be closed in 5 days.

pfefferle commented 10 months ago

keep!