Hashed slug? about edit-author-slug HOT 9 CLOSED

I like this idea 👍

from edit-author-slug.

@lkraav Will you take a look at #18 and see if it meets your expectations?

from edit-author-slug.

@thebrandonallen lgtm, tyvm. I think user_login and user_email both have to unique, so not sure if there's additional value in combining them. wp_hash() is already salted, so reverse engineering just one field should be tough enough, too?

EDIT actually, I think making a case for ID + user_login only is legit: unlike user_email, these are immutable (well, immutable enough). I'm fairly certain if a user changes their account e-mail, their author slug URL should not change (bookmarks would break, SEO redirects would need to be made, etc)

from edit-author-slug.

EDIT actually, I think making a case for ID + user_login only is legit: unlike user_email, these are immutable (well, immutable enough). I'm fairly certain if a user changes their account e-mail, their author slug URL should not change (bookmarks would break, SEO redirects would need to be made, etc)

Ha! Just circled back to this to tell you about an amazing idea I had after you first wrote back, and why user_email needed to be removed. Looks like great minds think alike, because you had the same idea.

My initial thinking was that you could have a user with ID=1 and user_login=1unicorn, and another user with ID=11 and user_login=unicorn. When combined, they would result in the same hash, because both would be hashing 11unicorn. This mean you needed some extra information to reduce the likelihood of that collision. But, as you pointed out, user_email is likely to change. The simple solution was to just add a separator between the two pieces of data. This way you'd be hashing 1-1unicorn and 11-unicorn.

The other caveat here is that wp_hash is salted, so if the salts are changed, the user hash will also change. I think salts are even more immutable than ID/user_login, so the risk should be low. It's still a risk though.

from edit-author-slug.

The simple solution was to just add a separator between the two pieces of data.

Indeed. Maybe it'd be best to select a separator that is for certain never to be allowed in WP usernames?

Salt changes - I think that's a real concern. I think we might have to derive our key after all. Silent change of all user hashes does not sound good for SEO (think BuddyPress). Which probably needs a "Reset" button. Although we could just leave implementing the Reset button for when somebody actually requests it here :)

from edit-author-slug.

Maybe it'd be best to select a separator that is for certain never to be allowed in WP usernames?

Couldn't hurt, but given that the the ID is numeric, any separator should be sufficient.

Salt changes - I think that's a real concern. I think we might have to derive our key after all. Silent change of all user hashes does not sound good for SEO (think BuddyPress).

I'm not sure salt changes, for most site administrators, is something that happens very often, or at all. On top of that, a silent change is already a risk, as that's how the auto-update feature works. I don't recommend the use of it, and I have a warning that it has SEO implications, but users wanted it ¯\_(ツ)_/¯. However, in order for the silent change to happen, the salts have to change, the auto-update feature has to be activated, and the user has to update their profile. For most sites, this should be a very low risk.

All this being said, I think the best way forward might be to just use the md5() function directly, rather than a salted md5 has via wp_hash()/hash_hmac(). This would mean that the only thing could prompt a change would be for the ID or user_login to change. Given that either of these would be very rare, and would be a very special case, I don't think we need to concern ourselves with the possibility of it happening. While an md5 hash could be broken with relative ease these days, we're not hashing anything sensitive, like a password. Using a hash for the author slug/user_nicename shouldn't be meant for security, as it would just be security through obscurity.

Any objections to using md5()? It's less "secure," but also has far fewer caveats.

from edit-author-slug.

Any objections to using md5()? It's less "secure," but also has far fewer caveats.

E-mail harvesting by bots might be the only real concern. For example, there are systems where I force all logins to default to e-mails, for simplicity and uniformity.

from edit-author-slug.

I'm going to go with an md5 hash. The iThemes Security plugin encourages, and makes it easy to change salts. I'm not sure how often it's used, but I don't think the churn would be good, and I really don't want to deal with support issues with people asking why the hash for the author slug was changing.

from edit-author-slug.

@thebrandonallen thanks for the release. One more thought came to mind - how about passing the hash result through a filter to allow sites to override w/ whatever logic they have use for the most?

from edit-author-slug.