[Uwe Trenkner]

Excellent. Many thanks!

[Uwe Trenkner]

Hi @wzp, we use UTF-8 everywhere, all SWPM-tables use the MySQL-collation utf8mb4_unicode_ci. Our installation language is de_DE (German), so we are using inter alia German characters like ä, ö, ü and ß.

[Uwe Trenkner]

Hi snrie,

there are two things with which you can allow/disallow the storing of the “decryptable” password.

1) When you add a new membership level you can leave the “Email Activation” checkbox unchecked. The info in the admin back-end explains this setting: “Enable new user activation via email. When enabled, members will need to click on an activation link that is sent to their email address to activate the account. Useful for free membership. View Documentation.
Note: If enabled, the member’s decryptable password is temporarily stored in the database until the account is activated.”

2) If you want or need the “Email Activation” (e.g. because you offer your services also in the European Union, where double-opt-in is required by law) but still do not want to have the password stored in a way that it can be easily read, you can add a little swpm-enhancements plugin yourself with just one file (I think this was recommended to me by the plugin devs, back in 2019) /path/to/your/wordpress/wp-content/plugins/simple-membership-enhancements/wordpress/wp-content/plugins/simple-membership-enhancements.php
[CODE]
<?php

class SwpmEnhancements
{
function __construct()
{
add_filter(‘swpm_email_activation_data’, array($this, ‘handle_email_activation_data’));
}

function handle_email_activation_data($user_data)
{
$user_data[‘plain_password’] = ”;
return $user_data;
}

}

new SwpmEnhancements();
[/CODE]

This replaces the password with an empty string. Problem solved.

I have been using SWPM with this since 2019.

Best regards
Uwe

[Uwe Trenkner]

For clarification: “other translations work” was meant as “in all other places, I see the German translation”. I have not tested other languages…

[Uwe Trenkner]

@mbrsolution: Yes, sorry, I forgot to mention… I meant fields from the form builder addon.

@TheAssurer: Thank you. It is not the answer I had hoped for, but at least I know it is nothing I can solve with the data export addon. Maybe I have to hack the form builder to automatically update a timestamp so that my client can easily track changes.

Background: They expect to have a lot of clients paying by invoice (they come from conventional, i.e. print, publishing). Thus, they want to be able to quickly identify clients for which the invoice address has changed.

[Uwe Trenkner]

Thanks! I had read that documentation. But somehow the URL that I entered at PayPal was not picked up correctly – maybe it had to do with it being a sandbox account? It always send its info to the root of the site, i.e. https://www.mydomain.com/

But I was able to identify the GET-parameter, for which I could filter (and deactivate caching): swpm_process_ipn. With this, I a am happy.

[Uwe Trenkner]

@admin Thank you for the offer – I have not yet looked into how this would look like with a hook.

But I wanted to post a warning and fix here, for everyone: I noticed that in certain situations WordPress redirects pages with the whole QUERY-string. If that URL is exposed to e.g. a user, he gets to know the secret bypass string.

I therefore trigger the bypass now via an HTTP header, which is never returned by WordPress. And in order to make the code portable, I decided to use a hash of WP’s auth salt. This way the secret bypass string is unique to every WP installation. In class.swpm-access-control.php, I now start the can_i_read_post() function like this:

    public function can_i_read_post($post){
        if ( isset( $_SERVER['HTTP_X_SWPM_BYPASS'] ) ){
                $bypass_key = hash( 'sha256', wp_salt('auth') );
                if ( $_SERVER['HTTP_X_SWPM_BYPASS'] == $bypass_key ){
                        return true;
                }
        }
...

[Uwe Trenkner]

Thank you. That is slightly better, now.

But it does not solve the main problem: The password is stored in an form that can be reversed to get back the plain text password. This is an absolute no-no from security point of view!

Consider the attack vector: Someone gets access to the server (possibly even with backups) – that person may be an admin or a malicious hacker. That person can than read both, the encoded password and the WP installation’s salts. From that he can decrypt the password. And now comes the main problem: Because many people are lazy they re-use passwords across different websites / online service. The person now has a username, an email address and the plain text password and can run it against other web pages. This is not a theoretical threat. This is happening every day.

You will answer that the encoded password is now deleted after activation. Maybe! But maybe there is another problem in your code which prevents that from happening. Or for some reason the cron is not triggered. Cannot happen, you say? But it happened already: There was a slight mistake in the code and the password was not deleted as intended. Therefore: Play it safe and do not store a decryptable password.

In short: If you can decrypt the password, it is not stored safely! This must be considered a serious bug and should be addressed immediately.

I am somewhat frustrated with your “solution” because it is not at all necessary to store the plain text password or a decryptable representation thereof! There are only two use cases for it: To send it back to the user in the registration completion email (after email activation… there it does not come directly from user input but from the database). And you use it in the auto login after registration feature.

I know what I am talking about: Not only have I read the code. I have tried it. I deleted the storing of the plain text password (as I originally suggested) and the email activation did go through without a problem. The password in the registration completion email I received remained empty, obviously. And the auto login feature would not trigger anymore. I think these two “features” are a very small price most of your users would be happy to pay, if they knew that you treated passwords in a secure way.

They way you addressed the issue, I will have to keep my own version of the plugin. Which is really a pitty. I wish you would reconsider your “solution”.

[Uwe Trenkner]

@admin Yes the “official” password is stored in encrypted form – just the normal way WP does it. However, it is stored once more unencrypted in another table – apparently for the sole purpose of sending the password back to the user with the registration completion mail.

The relevant code was introduced into the SwpmRegistration class back in January. I believe you could just remove the saving of the plain text password in this line:

update_option('swpm_email_activation_data_usr_' . $member_id, array('act_code' => $act_code, 'plain_password' => $member_info['plain_password']), false);

But you may want to consider providing a clean-up function to rid that other table of the plain text passwords. Otherwise they will stay there forever.

Plus you really should re-work the auto-login feature, and temporarily mark it with sufficient warnings that this will lead to the plain text password (or its base64 representation) showing up in web server logs.

Sorry, for sounding pushy. I know that we consumers of free open-source software have no right to complain or ask for anything. I am really thankful that you provide and support this plugin. But when it comes to security, I think we all have a obligation to do the right thing. And if you do not fix it, I have to do it myself… and re-do it for every upgrade of the plugin you provide.

Please let me know, if I can help in any way.

[Uwe Trenkner]

From the source code it seems the devs intended at least to delete the database entry with the plain text password upon successful completion. However, they missed the correct key name:

delete_option('swpm_email_activation_code_usr_' . $member_id);
should really be
delete_option('swpm_email_activation_data_usr_' . $member_id);

This would at least prevent the plain text password from staying in the database forever. Still, the plain text password should never be written in the database in the first place.

[Uwe Trenkner]

Unfortunately, you are wrong. And I am very disappointed to find out about this, now.

Originally, I did not check the database for the plain-text password. But when the “Your registration is complete” email showed me my password, it was clear that it was saved in the database in plain text. It is dead easy to find, if you look for it.

The plain-text password is not even deleted after the registration is completed. It just sits there forever, waiting to be hacked by the bad guys.

I did a very quick check of the source code and to me it looks as if the saved plaintext password is used only for the email after the user completes the registration. As this is absolutely unnecessary, one could probably remove this saving altogether.

While looking for the use of the plaintext password in the source could, I found another problematic use: When “auto login after registration” is enabled, the user is redirected to a URL which contains the password base64 encoded (which is not a security feature, of course, as it can be decoded by anybody). Thus the easily decoded password will end up in web server logs where they can be found by malicious persons.

I call on the developers of this plugin to urgently update the code, so that:

1. the plaintext password is never ever saved anywhere
2. the plaintext password is never send via email to the user, to the admin or anyone else
3. the plaintext password (or its base64 representation) is never used in a URL

I would be happy to help with cleaning this problem in the code. But should this issue not be addressed in a timely manner, I will start warning other people not to use this plugin because it is inherently unsafe.

[Uwe Trenkner]

Resolved!

[Uwe Trenkner]

Awesome! Many thanks.

Your tools and documentation are really good. They are just not always easy to find, because to find a solution one has to read not only the documentation, but also the info about each add-on, which may or may not provide a solution (who would have thought, that a downgrade was possible via the Shortcode Addon?)

Again: Many thanks!!!

[Uwe Trenkner]

Thanks for the link. Can I insert short-code into the custom messages,too? Then I could enter [swpm_login_form] and get the login form?

If not, I could still use HTML to re-create a login box as you offer for e.g. the sidebar.

In any case, it would not re-direct to the post the user was trying to read. The login form does not adapt the URL with the redirect-Parameter.

[Uwe Trenkner]

OK, thanks!

[Author]

Posts