Tracing the exposure of usernames, a question about what might be cached

#1

So this is a bit of a long winded question and only partly Comet related but here goes…

On a new site I recently setup I decided to try out the All In One WP Security & Firewall plugin instead of my usual go-to, the security plugin from iThemes. All In One has some interesting features which have sent me lurking down a rabbit hole.

Among other things there are several levels/methods for blocking unwanted logins. This site was just launched a few weeks ago and my login was getting hit hundreds of times in a few hours.
Part of dealing with that is preventing exposure of usernames. There are two typical ways to grab user names; via the url like https://mydomain.com/?author=3 which will return the username for the user with that numeric ID.
That user enumeration can be turned off via the plugin but I then realized that Yoast SEO was also creating a authors list as part of the sitemap (based the WordPress archive URL). That can be turned off in the Yoast plugin but still, something is allowing names to leak. Initially the login page hits went to almost zero but after a few hours they started again on a new user name that was created after the above was turned off.

Realistically this is not so important as the passwords are strong and the IPs are automatically locked out for a month after 3 attempts, I could also move the login url but it has all made me really curious.

Searching the page source content of all the public pages and posts does not reveal the username so I don’t think the theme is exposing them and there are no author links or metadata being displayed (which would be immediately found on any page source view) and the WP database does not show usernames in any unexpected place so I’m back to analyzing the plugins to see if one of them might be revealing usernames or if it really is the theme or simply WordPress itself.

So my questions here are;

  1. what if anything does a caching program like Comet cache, besides all the publicly visible pages and posts and the media contained in those posts?
  2. is there some other standard WordPress call to probe/request user names? I don’t mean serious hacking as I doubt this site is being hit by such advanced bots.

The only plugins I have are:
BackupBuddy
Comet Cache
Contact form 7
Popup Maker
Redirection
WP Maintenance Mode
Yoast SEO
Google recaptcha v3

Yoast was the obvious place to look as it is all about structured exposure but I ‘think’ those doors are closed.
Popup Maker is very clear that they do send data for usage analytics but it seems unlikely they would be exposing user names and none of the rest seem likely to be revealing user names either.

Then there is always reCaptcha v3… Do you think it might be exposing usernames?

Thanks…

#2

WordPress itself exposes usernames by default. Those “in charge” have always treated usernames as public.

#3

Yes, I’m quite aware that WordPress exposes usernames. What I was asking is if there was some other not obvious data that the cache might be relaying but it looks like Yoast is still spilling the beans.

This is somewhat anecdotal but it seems that with Yoast SEO disabled (no other changes), no usernames were extracted from the site but with Yoast SEO enabled, even with Yoast’s Author archives turned off, user names were detected.

What I did was:
– Disable Yoast SEO
– Create a new user
– Delete the old user
– Assign all the content to the new user and Wait…

During the next 24 hours+, no logins were attempted with the new username.
I then reactivated Yoast and within about an hour, that new username started showing up on the list of blocked login attempts.

What this seems to indicate is that while the default condition of WordPress is to show usernames, it is possible to block their exposure. But apparently there is another access point via Yoast.

#4

Yes, it’s possible to block exposure. Do you know how Yoast is exposing the usernames? If it’s via the REST API, then this plugin might help: https://github.com/johnalarcon/username-protection

#5

There’s no way that that can be the result of page caching, which is what Comet Cache does, unless someone first tried actually to login in using that username. If that didn’t happen — and you don’t say you tried to login in with it — then it’s simply not available for Comet Cache (or any other page caching plugin) to cache.

#6

No clue - It might be inadvertent, though I only say that as they specifically talk about how to turn off username display as part of the sitemap and don’t really discuss usernames elsewhere. And thanks for the plugin pointer. That will be a last resort though. If I further confirm it’s Yoast but can’t arrange a fix, I’ll likely change to another SEO plugin. Been reading a bit about The SEO Framework, it sounds like it might fit my needs as well or better, especially for this particular site.

In the meantime, I have a thread underway in the Yoast support forum

#7

That is exactly what I think - just looking at the possible alternatives.

That is an interesting point though I would think that since Comet does not cache for accounts that are logged in, I’m not sure how that would happen. I would also think that the login page would be ignored by most or all caching programs - seems like a big can of unnecessary worms. That said, I am sure I did log in at least once just after creating the new user to confirm the login and PW worked and were properly saved in my PW manager. Definitely have not used that account since.

Also, the account I’m using has not appeared in the list. Based on the username discovery behavior, the leak definitely seems related to logins with associated content. If the leak was related to logging-in, my current account should show as well.

#8

If you are using the default login page, CC shouldn’t cache usernames. But if you have a custom login page and haven’t excluded it from caching, then CC could cache it if you logged in after the cache was last cleared. But I don’t think that’s what’s happening here.

I actually use The SEO Framework and can recommend it.

#9

It is indeed the default login page, nothing special there…

The Yoast person has relayed that in a randomly checked handful of pages on a local test environment they are:

not able to find anywhere that Yoast SEO outputs the username in the source code with the exception of author archive URLs and when the display name and username are identical.

So if indeed it is a Yoast exposure, it would seem to be inadvertent, either a call that can be made to Yoast or some other unintentional metadata output.

#10

The saga continues - Presuming it’s not reasonably possible to make a call to a disabled plugin vs totally deleted, it is evidently not Yoast. It took longer but the new username started getting hits and Yoast is still disabled… Jeeeze

#11

I suggest installing the Rest API Log plugin to see if this is happening via that API: https://wordpress.org/plugins/wp-rest-api-log/