The emailOnApproved plugin needs a facelift

Hi Jerry

I don't think there's any way around this, unfortunately. For good security, the user's password should never be stored in plaintext on the site itself, at any point.

The best solution is to use the current Website Membership as is, where the user's plaintext password is sent on creation of the account in the notification email. This doesn't store the password, it simply sends it in the email on submission of the signup form. You can then have the plugin send a second notification when the account is approved that does not include the password at all, and only references the first email.

Another option would be to allow a user to sign up, but without entering a password. Then when they're approved, they get a link to a page that allows them to add a password and complete the signup process, and then they receive the usual email.

Either way - I don't recommend compromising the password encryption for the sake of convenience. Storing it anywhere in the database in plaintext, even temporarily, is a security risk.

Hi Claire,

I totally agree that a decrypted password should not be stored in the database.

That’s why I wanted to amend the plugin so that it decrypts the password and sends that to the member via the emailOnApproved email.

Seems that if CMSB checks the plain text password against the encrypted password each time a user signs in, then there should be a way to include similar code to decrypt the password and insert it into the emailOnApproved email.

Both the membership plugin and the emailOnApproved would send a plain text password through unsecured email once, and mortals being as fallible as they are, they could easily misplace the first email.

Any ideas?

Thanks,

Jerry Kornbluth

Sorry Jerry, it's not as easy as that. The string you see in the database isn't really something that can be decrypted - it's a one-way-only unique hash value created from the password. Any secure hash can never be realistically turned back into the original plaintext.

On login, the system will take the plaintext password from the login form, generate the hash, and compare that to the stored value in the database. The actual plaintext never gets near the database to begin with.

I understand that they could misplace the email - I think your best option at that point would be to let them reset the password. It's a very common solution and still secure.

Another thing you could do is send them a generated password initially, and then let them log in and reset it when they're approved - and then send them a new email with their username and chosen password. This would be acceptable for security purposes and still let them get an email on approval, like you're doing now.

Ah...

Much clearer now, Claire.

You mentioned the option of allowing a user to sign up, but without entering a password. Then when they're approved, they get a link to a page that allows them to add a password and complete the signup process, and then they receive the usual email.

Any idea how I would go about that? I'm willing to muck about, but could use a concrete starting point.

Thanks,

Jerry Kornbluth

There's a few ways to do it - here's one of them: you start the signup as normal, and allow a user to be created as normal, but leave the password fields as autogenerated values. In the email template that usually goes out on signup, remove the password placeholder and let the user know that they'll get more info once they're approved.

The user section has an extra checkbox, which is 'Password Changed' or something similar.

Then, in the emailOnApproved plugin, set it to send an email on approval that contains their username and generated password. They can then sign in with that, and they should be immediately prompted to change their password to something new, and the system will not allow them access to anything else until that's done. Once they change it, the Password Changed checkbox is ticked, and now they have full access.

You could also send them a link to a separate form that lets them input a password on approval, provided that you also attached a unique hash to it to prevent abuse on the front end. But this is more work of course.