MNX

It’s all in here: https://www.wordfence.com/gdpr/dpa.pdf

I MAY be wrong on this but I think you’d only ever have to prove this for submissions made after the law came into effect.

Both possible but only with a data processing agreement in place before enabling it.

Hi, thanks for all your work. The update works just fine!

It’s enough if you can’t proceed without consent. That’s all the proof you’ll need.

Indeed, CDN’s are a problem under GDPR because you’d need a data processing agreement with them to form a legal basis for collecting and storing private data.

Under GDPR, an IP address is considered private data so we all have to go through this whole contract/agreement Spiel to make it feasible.

Aside from the webhook, you’ll also need to ask your bank for a SEPA creditor ID and add that to your Stripe account.

This extension will let users chose a group during signup:
https://www.eggemplo.com/shop/groups-user-chooses/

(It’s made by the developer of Groups)

Yes, there is a problem. It’s the fact that there’s no option to load the icons locally. The plugin makes use of a 3rd party CDN exclusively, which is difficult to justify under GDPR.

I’m not a lawyer but from what I’ve learned it’s not too hard to achieve compliance (or avoid needing it). The most important steps to avoid getting sucked into the “GDPR machine” in the first place are:

– Make sure no personal data ever leaves the system.
– Anonymize IP’s before processing/storing them (at least for unregistered users).
– Provide a data retention rule (auto-delete all of this data).
– Provide a way to search/delete/correct personal data.

Since this plugin works in the interest of site security, it is okay to handle personal data temporarily, as long as it’s mentioned in the privacy policy of that site and automatically gets deleted when not needed anymore. All users will have to give consent to this procedure when signing up to the website that’s using your plugin.

So, as long as you don’t collect any of that data yourself, this GDPR thing is pretty much out of your hair.

You could provide a list of data that may be used and explain in layman’s terms how it’s used and secured from unauthorized view so people can use that bit in their own site’s privacy policy.

Example:

This website uses Simple History, a security log and website change verification tool that helps us to identify (un)authorized changes made to this website. This tool may store site user’s personal data in a temporary log, for inspection by authorized staff only.

Data used:

• Anonymized IP address
• Site username
• Email address

This data will automatically be deleted after x days.
It will never be shared it with any third party.

—

This is a bit too basic but you get the idea. It’s the site developer’s responsibility to make sure all the tools used are compliant and you can best assist them in making that information easily accessible.

—

Note: I don’t think the feed feature is GDPR compliant (no authentication to protect the data from view), adding a note to the settings page should be all it needs though.

Again, I’m not a lawyer, it’s just a couple of recommendations to get you going.

That author name hook is not a hack, it’s just a means of reconnaissance for attackers but they would still need to brute force (or social engineer) the password for that account. If you have WordFence installed then you should be fine as it will limit the login attempts and block the IP’s breaking the rule. It should take them decades, if not centuries to hack your site that way. (Provided you use a strong password, such as the one WP automatically generates)

You can enable 2FA for the Super admin account only, that doesn’t have to do anything with other accounts, groups or customer areas.

I see, please provide such information right away as it saves everyone a lot of time. I’m hoping you have backups so you can roll back to before the change?

I’m not an expert on multi-site installations so if you need fixing here, someone else might have better insights than I do.

I do know however, that what you’re describing is ‘security through obscurity’ and it simply doesn’t work. There’s absolutely no security benefit to obfuscating/changing usernames as there are just too many ways to detect them.

I suggest using Two-factor Authentication so the username wouldn’t be of any use to attackers, even if they happen to come by the password. This is considered to be safe.

You can also change the front end author slug, if that makes you sleep any better but again, it doesn’t add any security.

• This reply was modified 6 years, 8 months ago by MNX.

To add super admin capabilities to a user, you can just add this to your functions.php or add it as a global Code Snippet:

grant_super_admin(1);

The number needs to be the ID of the new admin.
Once that’s set and verified, the line must be removed again.

Oh, I wasn’t aware of that. Sorry about that.

You should be able to put new image files in using CSS only though. Just look at the source code to find the classes and override the statements using !important.

Create a new account.
Login to the new account.
Delete the old account. (Assign content from old account to new account only after running a WordFence scan and it comes out clean.)
That’ll give your new admin account a new user ID, which is an added benefit.