[wp-hackers] Author URLs expose usernames

[Harry Metcalfe]

On 17/07/12 12:12, Mike Little wrote:
> On 17 July 2012 10:56, Harry Metcalfe <harry at dxw.com> wrote:
>
>> Not a new issue by any means, but we're seeing an increasing number of
>> attacks where:
>>
>>   * Usernames are first enumerated by visiting ?author=<id> and checking
>>     the username slug in the redirect URL
>>   * Brute-force password attacks are then carried out against those accounts
>>
>> I wondered whether WP might already have some mechanism for using
>> something else as an author slug, or for not redirecting ?author=. Or, if
>> not, whether something should be added or changed?
>>
>> I realise usernames are probably used because nothing else in wp_user has
>> permanence, but this is very much not ideal for us. We run a couple of big
>> members-only BuddyPress sites. And like all such sites, they have user
>> accounts with crap passwords. We have other controls to try to limit that,
>> but the reality is that accessing the site is extremely trivial for an
>> attacker if usernames can be enumerated, because at least a couple of them
>> will have passwords in the top 10 list, which will therefore be guessed
>> before our systems notice the attack and ban the IP/reset the password.
>>
>> For the moment, we're 403ing requests for ?author=. Not exactly optimal as
>> sites can still be spidered to look for /author/[username] links, but at
>> least it stops the naive attack.
>>
>> Has anyone else done anything to deal with these sorts of attacks?
>>
>> Harry
>>
>>
> WordPress will try to use the user's 'user_nicename' column to create the
> user's url. Alas, by default, this is the same as the user's login (unless
> a sanitised login clash causes WP to add a numerical suffix). But it is
> filterable at user creation time.
>
> So, you could go through and run a query to update everyone's user_nicename
> column (it's in the prefix_users table). WordPress will instantly start
> using that value for the author's post url (you will likely need to clear
> caches). It needs to be url friendly, so you might make it
> firstname-lastname-randomnumber, for example.
>
> To ensure new users have the appropriate user_nicename, you can hook the
> 'pre_user_nicename' filter to modify that field during user registration.
>
> Hope that helps,
>
> Mike

Ah, I should have checked that! Will the core keep those old URLs live 
if nicename changes?