- One of the issues with membership plug ins in WordPress is that they can conflict with WP Cerber.
- This is because membership plug ins leverage the WP user functionality.
Most membership plug ins leverage WP’s standard user functionality. One problem with this is that this user functionality is how bots hack WP websites. We have a large number of bots that probe and try to break into Brightwork Research & Analysis on a daily basis. Because of this, we have used WP Cerber to shut down anyone but us from being able to login to the website.
WP Membership Plug Ins
Here are some popular membership plug ins and how they create users/members.
- Memberful: Does not use WP user functionality.
- Fast Member: Uses WP user functionality.
- Paid Memberships Pro: Uses WP user functionality.
- MemberSpace: Does not use WP user functionality.
- WishList: Uses WP user functionality.
- MemberPress: Uses WP user functionality.
- WooCommerce Membership: Appears to use WP user functionality.
- ARMember: Uses WP user functionality.
- Ultimate Member: Uses WP user functionality.
- WP Full Stripe Members: TBD
What this highlights is that it is rare for a WP membership plug in to come with its own stand-alone membership functionality. This is negative because the WP user functionality is a security problem.
Relying on Problematic Functionality?
It is surprising that so many membership plug ins decided to rely on the standard WP user functionality, given its weakness and security issues.
Furthermore, user functionality does not work very well, even for non-membership tasks. For example, I have had to give out Administrator access to some collaborators because when I have given the Editor role, it does not work. This reduces the security of the Brightwork Research & Analysis because it means I am trusting someone I only want to be able to edit content, with total control over the entire website.
I don’t like doing this, but it means that I either give Administrator access or I don’t have the content edited. After roughly 12 years using WP, I have come to distrust the standard WP user functionality.
Major Issue #1: The Problem With Combining Content and the Membership Login
Finally, the membership plug ins that exist place the user/member data in the same WP instance. There is just something that seems intuitively wrong about this.
This means that if the WP instance is compromised, the hacker gets access to both the user data as well as the content.
This makes the hacked information far more valuable than just one or the other. If the content and membership users were kept separate, a single hacked item would provide the hacker with far less information that they could leverage.
Going with Custom Development
One option is to go with a plug-in like MemberPress that has open APIs and have a developer create a custom external user/member module add on.
Here are some of the APIs that would need to be leveraged.
Member Added – Sent when a new member registers but before their payment details are accepted.
Member Signup Completed – Sent when a new member completes the signup and their payment is accepted.
Member Account Info Updated – Sent when a member updates his/her account information.
Member Deleted – Sent when a member is deleted from the system.
Member Logged In – Sent when any member logs in. – MemberPress
This is the Response from WP Cerber on Working with Membership Plug-Ins
In asking WP Cerber about working with membership plug ins, I received the following response.
By default, WP Cerber doesn’t prevent users from creating accounts at least if you use the built-in WordPress registration form that can be enabled in “General Settings”.
Right, however, I have configured WP Cerber to essentially top all login attempts unless they meet very specific criteria.
WP Cerber can block user registration if you configure this in the “Data Shield Policies” settings. If you enable “Protect user accounts” and the “User registrations are limited to these roles” list is empty, nobody is able to register.
This is what the quote is referring to. I have this set to only Administrators being able to add new roles.
If you use a membership plugin, it might not be fully compatible with WP Cerber in the context of creating and managing users.
This, of course, depends upon how WP Cerber is configured, but as I have said, I have locked down the site using WP Cerber due to constant bot attacks.
Usually, this happens when a plugin author cuts corners wherever is possible or by breaking the process of creating users as it implemented in WordPress, for instance, Ultimate Member (https://wordpress.org/
It is interesting that WP Cerber points to Ultimate Member.
However, as I prefer to have WP Cerber set, I am incompatible with any membership plug in that, in any way, leverages the user functionality of WP. I do not see this as an issue with WP Cerber. I see it as an issue with membership plug ins that really should have their own completely independent user/membership functionality.
Reconfiguring WP Cerber
There is some way to change the configuration of WP Cerber such that there is login allowed, and the standard membership plug ins can be used. However, it just concerns that with a membership site, and it is virtually a requirement that users be created and controlled within WP. Realistically WP’s user functionality was never designed for this.
A Plug In With External User/Membership Functionality
The only plug ins I could find that keeps the user/membership entirely separate from WP is Memberful and Memberspace. Memberful and MemberSpace are some of the few WP membership plug-ins that are entirely independent of the WP user functionality. But there are other issues with Memberful and Memberspace that include the following:
- Both Memberful and MemberSpace prevent Google from indexing the protected page. We want the protected page to be indexed, but not viewable.
- Memberful is not multisite.
- Memberful requires text to be copied from the main article to the area that is allowed to be shown.
- Both Memberful and MemberSpace are expensive, with Memberful taking 4.9% of the sale, and MemberSpace taking 4%. This is in addition to a monthly charge for each.
- In usage/testing, MemberSpace did not work properly. However, it had some good ideas in terms of how to configure a system that does not rely on WP user functionality.
Here is the Blackout setting for pages. This means the pages flicker, and no part of the page can be read before the user is directed to a login page.
Curiously, this fact about the commonality of the standard WP functionality being leveraged is never mentioned in any of the reviews of the various membership plug ins. It seems that nearly all membership websites are using plug ins that require the use of WP’s user functionality — this can only mean that these websites have to reduce their security in order to allow these plug ins to function.
A Bit Around OAuth
OAuth 2.0 (OAuth2) is an authorization framework that enables an application to obtain access to HTTP based resources that are usually within the domain of an unrelated application and that also may be associated with a given user within that domain.
If you have or are planning to have an HTTP API where the protected resources are tied to individual users and you intend to make their data accessible to third-party applications, then OAuth2 is most likely the right tool for the job; at least is the one with more adoption. – The Authentication Survival Guide
If one wants to develop custom authorizations there are two important components.
- OAuth: An open source authorization project.
- Cloud Authorization: Cloud based identity management.
Google, AWS, and Azure all have cloud security offerings.
Leverage Cloud Identity, Google Cloud’s built-in managed identity to easily create or sync user accounts across applications and projects. It’s easy to provision and manage users and groups, set up single sign-on, and configure two-factor authentication (2FA) directly from the Google Admin Console. You also get access to the Google Cloud Organization, which enables you to centrally manage projects via Resource Manager. – Google Cloud
This video explains how irresponsible so many websites have been in requesting and normalizing the request for login information and obtaining access to things like GMail credentials, which allow that website to data-mine the customer’s data. This shows zero concern for security or privacy and the problem with not having government regulation over security and privacy on the Internet. Something else to note is how little this topic is covered.
The video explains that:
- The password is only entered in the OAuth center.
- The OAuth server is unrelated to the website, in this case, the WP website. This means authorization occurs entirely separately from WP. This is a good thing because it allows for each server to just do what it does best. WP (in this case) delivering content, and the OAuth server providing security.
- The curious feature is that OAuth is designed from the perspective of this separation between authorization/security, and the website that it is protecting. This is the exact principle that explained the earlier part of this article as a requirement for Brightwork Research & Analysis. This further means that virtually all membership plug-ins break this principle, but having the authorization to use the user functionality within WP.
- Google extensively uses an OAuth server (as Google tends to be very good at technology selection — this is highly encouraging). No logins at Google go to each service. One always logs into the OAuth server at accounts.google.com.
The following video explains how security covers how authorization is allowed through an open standard.
- This video describes how OAuth works in conjunction with OpenID. OpenID can be considered the badge, while OAuth is just the authorization. This is interesting, because most of the membership plug ins — as well as the OAuth/Wordpress plug ins (that are intended to bring OAuth to WP, use WP’s users as the badge.
- This video is made by a company called OtkaDev, which makes what appears to be a premium OpenID or OIDC service.
Google Cloud IAM or AWS Cognito?
Google has an overall solution that does more than OAuth called Google Cloud Identity and Access Management?
It is described as follows:
Google Cloud Platform offers tools with a single dashboard and simple interfaces to implement security policies. Google Cloud Identity and Access Management (IAM) provides an easy way to manage GCP users and the permissions assigned to them.
Besides human users, GCP provides a way to create non-human identities (service accounts) and attach those to cloud applications and VMs. The correct configuration and usage of service accounts and IAM are critical to GCP security. GCP also provides a centralized dashboard to view audit logs, which are useful in the case of a security breach. – Google Cloud Academy
However, AWS has a specific solution for OAuth called Amazon Cognito.
- Users can login using their social accounts or GMail account (which of course is both convenient and confidence-inspiring.
- Cognito has its own front end.
See this quote.
With a built-in UI and easy configuration for federating identity providers, you can integrate Amazon Cognito to add user sign-in, sign-up, and access control to your app in minutes. You can customize the UI to put your company branding front and center for all user interactions.
AWS Cognito also has an OAuth WordPress plug in.
This plug in allows.
WordPress OAuth Client (WordPress OAuth 2.0 Client / Login) plugin allows login with your Eveonline, Clever, Slack, Discord, Custom OAuth server, Openid Connect provider. OAuth Client plugin works with any OAuth provider that conforms to the OAuth 2.0 standard which provides quick & easy configuration.
Login with Azure (Azure Login)
Login with Facebook (Facebook Login)
Login with AWS Cognito (AWS Cognito Login)
Login with Social Apps
This means that a straightforward design for OAuth, would be to use AWS Cognito with the MiniOrange OAuth 2.0 Client WP plug in.
This is explained below.
However, this support request is concerning.
Notice this proposes leveraging the users in WP. In this case it means leveraging just the users on one WP subsite — to create a single sign-on for multiple WP subsites — which still means leveraging the standard user functionality.
There are several of these OAuth plugins.
This has been even more recently updated and has more users.
See this explanation.
However, this explanation is concerning, because it again refers to using the users stored within WP to connect to the OAuth server.
This one is also interesting and only works with Google credentials.
Google Apps Login allows existing WordPress user accounts to login to your website using Google to securely authenticate their account. This means that if they are already logged into Gmail for example, they can simply click their way through the WordPress login screen – no username or password is explicitly required!
But here again, it leverages existing WP user accounts.
This brings up the question as to whether any WordPress OAuth plug-in can or should be leveraged.
It seems the WordPress OAuth plug ins work against the principle of OAuth, which is to have the authorization completely on a separate server.
Further on in this article, we will get into why we probably not be using these plug ins.
The Memory of Authentication
The memory of authentication has normally been called a cookie — but also goes by the name token.
If you think about it, the traditional cookie-based authentication systems used in Web applications for ages is a good example of the use of tokens as a way to authenticate the user. Most implementations rely on an opaque string, which at least would be randomly generated and maybe even digitally signed, that was then used on the server-side to lookup additional information about the authenticated user. – The Authentication Survival Guide
A bit about OpenID.
OAuth2 proved so popular that people started using it for scenarios outside of its original intent – user authentication and identification. However, it became apparent that there were too many decisions left to the interpretation of the reader when this framework was applied solely to solve the authentication problems. This lead to implementations approaching the same underlying issue with different solutions which then had to be reflected in specialized client libraries for authenticating with each specific implementation. Additionally, the lack of definitive guidelines also meant that it was more difficult for client application developers to ensure proper security
OpenID Connect can be described as an extension to OAuth2 that provides clear guidance on how to achieve a functional and secure authentication system. – The Authentication Survival Guide
There is a WP plug in also created by MiniOrange.
It is described as follows:
You can SSO to your WordPress site with any OAuth 2.0 or OpenID Connect 1.0 provider using this plugin.
If the user has an existing account in the OpenID Connect Provider, but not in WordPress, this plugin will enable dynamic registration of the user in WordPress.
This seems to allow for the user to login using the OpenID component rather than using or touching the WP user functionality. Although, if that is true, depends upon how one reads and interprets this sentence.
Notice that the plug in states the following:
List of popular OpenID Providers we Support
Observe that both Google and AWS Cognito are listed as OpenID providers.
There is a combined service called AuthO. Another similar one is called FusionAuth.
This software category is called Software category Customer Identity and Access Management (CIAM) Software according to G2Crowd.
Notice that several providers are rated higher than AWS (and also Google, which is not listed in this matrix). I think this is because the authorization in AWS/Google is more restricted in their functionality and more difficult to use. AuthO and FusionAuth are more straightforward to use.
Google’s OAuth is much more technical and would require more work to get functional.
We get into AuthO in detail in the article An Analysis of AuthO for Authentication.
This is an issue that will require more analysis. It also should be highlighted more on sites that cover the topic of membership plug ins. Somehow many membership sites are using plug ins that leverage WP’s standard functionality and not getting hacked. Of course, if it were to happen, I would never find out.
What is curious is that some companies with lots of security get hacked (although in many cases they are inside jobs). WP’s user functionality, with dropped security to allow for membership plug ins to leverage the standard WP user registration functionality is like an invitation to hackers.
The more I researched this issue, the more it dawned on me that many of these plug ins were developed some years ago — and at this time there were few options for external user management — therefore it is possible that the developers leveraged the WP user functionality because there was not a good way around this problem.
Some of the configuration screens for AWS Cognito.