Password encryption?

[rhail]

I assumed that encrypting the passwords would be nowadays default feature anywhere online, but it seems that this plugin has no means to save passwords in secure format? Is this really so?

Even though this plugin would be quite handy to our website needs, saving passwords as plain text is not acceptable for us.

[mbrsolution]

Hi, you may strengthen member password selections by enabling the following feature Force Strong Password for Members? This is located in Advanced Settings.

We also have the following addon that adds 2FA.

Regards

[The Assurer]

SWPM does not save passwords in plain text. SWPM depends upon the same User ID & password system as the core WordPress system. That is to say, the SWPM nenber name & password, is not independent from the WordPress User ID & password system (they are the same).

[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.

[rhail]

Actually I was also planning to return to this issue, since we have now tested the plugin usage and also noticed that the plugin sends both the username and password in plain text to the user after registration. So the password is not saved in no safe manner in the DB. This is indeed alarming and should be fixed ASAP.

[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.

[The Assurer]

The developer has been notified, and will validate your observation

[admin]

Thank you. This looks like an issue from the email activation feature that was added recently. I will provide an update after we investigate this more. The actual user password is stored in the database in an encrypted format.

[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.

[admin]

The password is not saved to send with registration complete email. That one simply comes from the request at the time of submission (whatever the user enters in the form submission).

The temporary saving that you saw was happening for the email activation feature. We have re-worked that feature and released a new version of the plugin. Also, there is a cronjob in there that will cleanup/delete any old data.

[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”.

[The Assurer]

As you admitted earlier; this is open source code. You are more than welcome to code and submit your own solution for peer review.

[snrie]

I’m a noob to the plugin and security, and was wondering about the state of this issue.

Can I stopgap by removing this from emails, or is the issue deeper?

Sample code: Password: {password}

Thanks for any info you can share.

[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

[Author]

Posts