Password stored in plain text

It could be encrypted, but it cannot be hashed because we need to restore that password after the user is activated. The simple solution is not to allow user defined passwords. You may say, well, regardless, why not encrypt it? Well, it’s a trivial task, certainly, but… If your usermeta table is compromised, you have a bigger problem then a few user passwords being exposed, especially considering after the user activates that meta data is dropped, so this is only a temporary placement of sensitive data. Again, if back-end data access is obtained, this will most likely be the least of you problems. And, honestly, what’s the point, anyone with the skill to get this data could EASILY decrypt it. My encryption method would be in the Register Plus Redux PHP files which are open source and freely available. And finally, they cannot login with this information as these users are inherently unactivated. Therefore this is a bit of a long con. They have to sit on the password until the user drops off that table.

I registered just to say this:

How you responded is crazy, you should always hash your passwords or at least encrypt it (in your case hash).

If your usermeta table is compromised, you have a bigger problem then a few user passwords being exposed

Really?? Say I have a wordpress userbase of 100,000 people. I now have to explain to 100k people that I have leaked their passwords in plain-text to an attacker, who probably now has access to viewing your email and possibly other things. What if these people use that password for other things?

You’re basically saying ‘why should anyone hash passwords, there are more things to worry about’. Hashing passwords is very important, hence the need for things like bcrypt.

I could never use a plugin that stores the users passwords, which I’m responsible for, in plain text.

How I respond may seem crazy, but your understanding of the issue is ridiculous considering how clearly I explained the issue. ONLY UNVERIFIED USERS PASSWORDS ARE IN THE TABLE. ONCE VERIFIED THEY ARE REMOVED FROM THE TABLE. This is a temporary measure. I find it unlikely you have 100k users registering for your site regularly.

The reason this ever came to exist is because users requested the ability to send users their login information once they are verified. With a hash, that is impossible, as you should well know.

I am still considering a few alternate strategies, but I don’t consider this a major issue. Nope. If it bothers you, I encourage you to either, A) not use user set passwords which gets you out of the whole game, or B) not use Register Plus Redux. Whichever, I encourage you to better understand the plugins you use. If all users were so interested the entire ecosystem would be better off.

There are plenty of websites that have over 100k users that run wordpress, I have 3 WordPress sites that have a few thousand users on it’s own, and they would not be pleased if this happened. Whether the passwords are stored temporarily or forever is besides the point, it should not be done.

You can very easily send them their login info, hash it and then insert it.

I have already chosen B, as I do understand the plugins that I use and the ones I do not.

You could very easily send them their login info, hash it, and then insert it. And when you are verifying users this is exactly what happens. But as soon as there verification is enabled, there is no point in sending a user login information that they cannot use. It is stored so that whenever the user is verified, be in an hour, a day, or a week, THEN, the login information can be sent. To the same point, the user is not actually created until verification is complete. So, for the user set password to actually work, I need the password available to set it following verification when the user is created. I am looking to emulate the hash the WordPress uses when the password is initially set. That would enable RPR to hash the password and store the exact hash to be stored on the user table later. This is a bit hacky because I will have to do direct table manipulation to the user table after a user is verified to insert the hash directly instead of using password setting functions. I’m not entirely sure this is going to work, but it is an idea. Regardless, written that way, emails following verification just simply won’t be able to send the user their password. Not something I’ll lose a ton of sleep over, though I will get some pushback from users used to a certain behavior.

As I said, there a number of strategies, but, as a unpaid developer this is my choice. As it is yours to use this free plugin or any other. I make no attempt to obfuscate how this plugin works. Regardless I appreciate your concern, less so your condescending tone.

radiok bro, just don’t take any password from users during registration. After they verified their emails, generate a random password and send them. If users want, they can change their password using wp native system…..and all worries gone!!!!!

True bdboy, this is an opt-in feature, you can just not check the option to allow users to set their password.