Hello there, and let’s continue our series on building a membership site. There was a little bit of a delay there because, well, frankly, I’ve been busy building membership sites for clients, so that goes with the territory. So in this video, I want to talk about passwords for your members and how to handle them, because sometimes this is a confusion on, should you have people pick their own passwords? Should you let the system auto-generate it? And basically, how to handle it. So let’s go ahead and talk about that. Okay, so let’s go ahead and talk about how to handle member passwords here. Now, it is often a point of confusion for site owners and how to deal with these member passwords. And I’ve seen people get confused with whether to put a field on their registration form and literally ask people the password. I’ve had clients before ask me, Hey, can we send this password in the welcome email to the membership? Things like that. And so I want to address the topic so I can give you some best practices. Now, do you have them set it themselves or should you auto-generate it? That’s definitely something we’re going to talk about here.

You can go both ways. Neither one is wrong. It’s just important on how you handle it, though. Also, should you just email that password? There’s a definite answer to that one. I’ll let you know in just a second. We’re going to discuss the different approaches and the best practices for doing this. Now, first of First of all, let’s get right to that question there about the email. No, you should not send their password in an email. You just should not do it. Here’s the thing. In order to send that password to them in an email, that means that the password would have to be stored in your database someplace in plain text. That’s inherently a security problem, and so you should not do it. The other thing is that email is not necessarily a security your platform either. And so therefore, sending plain text passwords via email is just not a good idea. It is a security problem, and you should not be doing it. Let’s go ahead and talk about the two main approaches here to handling passwords for your membership site. First of all, approach number one would be to have them specify their own password.

They can just enter into a field what they want their password to be. You have them just specify it right during the signup process, or if they are on a checkout form and they’re buying their way into your membership, you could ask for that password right then and there. And it just puts an additional field on the checkout form and they enter it. Now, It does, like I said, add an extra field to the checkout form or the registration form. One of the modes of thought with regard to that is that you could potentially reduce the conversion rate on that form because because usually the more information you ask for, the lower your conversion rate. Now, that’s not a hard and fast rule. It’s just something to be aware of that, generally speaking, it’s better to ask for as little information as possible. The other thing is that there is a higher likelihood here that they’re going to choose an insecure password because we all know that a lot of people don’t use password managers like they’re supposed to, and they just use the same password for a of different things. Often, sadly, it’s a really crappy password.

They could type in with four letters or something like that. That’s a security problem for your site as well, for their accountant on your website. We don’t want to make it that easy for them to choose really crappy passwords. The other thing, too, is that there is a chance when they’re free typing in their password that they’ll miss type it. They’ll get fat fingers and they’ll just type something wrong on the keyboard. One of the ways that you can get around that would be to then put a password confirmation field on there, which means you’re going to be adding two extra fields to your form. And of course, you’re going to need the validation in place to make sure that those two fields are identical before the form can actually submit. So it’s a little extra work, and you’re adding two fields to the form. Or what you’re going to do is you’re just going to get more support requests because they’re like, Oh, my password doesn’t work. And well, it probably does. It’s just that you didn’t type it right. So these are some of the things that go along with having them set their own password.

So then let’s go into approach number 2, and that is to have the system basically generate that password automatically. You don’t ask them for the password. The system just makes it.

In this case, we do not need to ask for the password. You do not need to have a password field on your registration forms, on your checkout forms, or anything like that. After they have enrolled, what the system is going to do is send them an automatic email that basically gives them a link to go and set their password. Essentially, what’s going on here is you’re triggering a password reset, just like you would if you were to go to the login form and say, forgot your password, you enter your email address, and you’re going to get a link in order to click and go set your password. Well, what’s going to happen if you auto-generate it is that they’re just going to get that email right out the gate. And so they will get the email. It’s a pretty simplistic email, actually. And then they’re going to click it and they will go and set their password. The idea here is that you’re never going to see their password, which is the way that it should be. Now, this is a much higher likelihood when you go this route that they’re going to have a better password because WordPress is going to auto-generate that password for them.

Even when they get to the password reset form, it’s going to generate a pretty long password. And a lot of people will just take that password and they will put it into their password manager, and that’s honestly what they should do. Now, if they want to overrun that password and type in something super simple, that’s up to them. But the point is, you’re leaving it up to them. You’re not putting it on the checkout form. It’s their problem. Also, you’re not seeing it, which is important. It also avoids sending passwords via email, which is important. You should not be sending passwords in email. Even if they type in that thing, don’t send the password via email because that means you’re storing it that way, which you should never be doing. Also, you’re not sending them an automatically generated password, you’re making them click a link and go over and do it on your website. And that’s the secure way to do it. Now, I recommend that you let the system handle passwords automatically. Generally speaking, I do not recommend that you let your members define the password in the process of registering. I think you should keep simpler checkout forms and just let the system do it.

That’s what I do with all the membership sites that I build, and it is what I would recommend that you do. You should never, ever see their password any place. You, as the owner of the site, should never see their password. Because if you can see their password, that means that the password is being stored in plain text, and that’s a super bad idea. You probably don’t know this, but the way WordPress stores passwords in the database is not plain text. It is encrypted. Basically, in your config file for WordPress, there’s what’s called salts, and basically, it’s these big, long, nasty strings. And basically, what WordPress does when you set a password, in non-geeky terms, it’s basically combining that big, long salt with their password, putting them together into an encrypted password string. So therefore, if anybody ever got access to the database, they would never be able to see users’ passwords. So the very fact that you are able to ever see somebody’s passwords means that you’re doing something really, really wrong. You should never see somebody’s passwords. Even when you go to their user profile, you should never see their password. They should have to reset their password.

And then at the most, that should ever happen would be that they email you and say, Hey, can you just take my password such and such. You’re like, Well, this isn’t the way it should be done, but you could go into their user profile and you can manually set their password, and that’s it. It will go stored into the database at that point, encrypted, and you should never, ever see that password ever again. That’s the way that it’s supposed to work.

You should never send them their password in an automatic email.

It’s just not a secure way to go.

Even though, and I’ll show you this in a minute, WP Fusion does have a way to enable you to do it, but I do not recommend that you do it. Their password should be between them and your website, not between them and you.

You should never see it, and you should just let this thing happen automatically. Now, if they forget their password, they just use the forgotten password, the reset functionality is built right into WordPress, and that’s how they fix the problem.

Here we are on the back end of our practice membership site that we’ve been putting together. I want to show you a few things related to passwords. First of all, we’re using Woocommerce, as we’ve already covered. If you go to settings, you go over to accounts and privacy, this box right here under the account creation option should remain checked. You can see it says send password, set up link, recommended. Basically, by WooCommerce’s standards, when you check this box, if they’re creating an account on checkout, which, of course, I’m allowing them to do, this will not ask them for their password, but will instead send them an email for them to set their password. It will contain that link to set their password, as I discussed earlier. Now, if you were to uncheck this box, and yet you had the ability for them to create an account, Well, Woocommerce will then have a password field. You can go that route if you’d like, but as for the reasons that I recommended before, I don’t recommend that you do that. You can see that Woocommerce says the same thing. We’re going to keep that thing That’s one thing I wanted to make sure we showed you.

Now, we also, in a previous video, talked about fluent forms and the registration forms. Let’s go over to that so we can cover that particular area. Now, this free member registration form that we had mentioned earlier, I believe we actually, yeah, we do. We have a password field on there. In this case, we would want it to be required. I don’t know why we didn’t do that before. Now, let’s see how we have this thing actually set up for the configuration. For user registration, go over to here. You can see that we are matching up the password field to the password for user registration. In this particular case, as it is right now, we would be setting their password based on the form. Now, if you’re following the best practices that I am talking about, what we would do with this registration form for free registration is go back to the editor We would delete that. Then let’s save that form. Then we’re going to go back over to our integration. Go over to here. For this one, we want to have nothing in there because you can say keep empty and it will be auto-generated.

That’s what we want it to do. Then right here, send default welcome email to user after registration. A lot of times for this particular setup of registration, I would that you check that one. Basically, WordPress will then send the default email for them to set their password.

That’s the way that I recommend that you do it from that perspective.

Now, one other thing I wanted to show you was in the settings for WP Fusion. Let’s go back over here. If I could hit that darn pop-up menu.

All right.

Now, on this screen, on the main general settings thing for WP Fusion, pop all the way down to the bottom, and there’s a few things that are of interest regarding passwords.

Now, under imported users, this is specifically if you are importing users into your system via a webhook. If you’re using an outside system, but you want to create a user profile, WP Fusion can do that for you using a webhook. And it’s a pretty handy feature. You could see one of the options would be from ThriveCart. If you were to be integrating with an external shopping parts such as that one. Now, in our case, we are using Woocommerce, so all this stuff will take place in-house. You don’t really need to worry about this stuff. But what I usually do is I have this box checked to send them the default welcome email. Our username format will be the email address. I personally think that’s a cleaner way to go. But this right here I consider to be the danger zone. I wanted to point out that WP Fusion can do it. I just don’t recommend that you do. If If you were to check this box, it says, Send new users generated passwords back to Fluent CRM after import. Basically, if you were to check that box and then over in this section for contact fields, if you were to sync their password up with a custom field inside of your CRM, you could then use a merge field in your welcome email and essentially send their email to them via email.

Sorry, send their password to them via email. This functionality down here does allow you to do that. I have come across sites that are doing this because they thought it was more user friendly to send that password to them via email, even if it’s auto-generated, and it can do that. Now, here’s the thing. It will then be storing that password in your CRM in plain text. That’s a security problem, and therefore you should not do it. The second thing to keep in mind is that if at any point the user uses the password reset functionality and gets a new password, this thing is going to be out of date. So this whole return password thing is basically a one-time thing. You can have it auto-generate a password, and you can send them that password in plain text via the welcome email. After that, they’re on their own, and it’s not going to do them any good. If they set the password, you will never, ever send it to them in an email again because the CRM is going to have the wrong password. And hopefully, that makes sense.

One other quick thing I wanted to make mention, specific to WP Fusion, is if you go over to the Contact Field section of WP Fusion, this is where you match up fields. So you can match up fields inside of WordPress over to fields sitting over inside of your CRM. It allows you to get data back and forth, and it’s super, super handy. But make note of this one right here with regard to the password. They’ve even got a big old warning It is strongly recommended to leave this disabled from sync. It gives you the whole note of what the problems are here with it. But I just wanted to make mention of the fact that, yes, you can technically sync up this password field with a field in your CRM. You can technically do it. But, again, it says real user passwords will be synced in plain text. That is a security issue. They agree with me. It is definitely a security issue, and so therefore, you should not be doing it. It’s also, it says user passwords will be loaded from fluency when webhooks are received. If not set up correctly, this could result in your user’s passwords being unexpectedly reset, etc.

Now, I have seen this before on one or two different sites where people were having all kinds of weird login issues, and it’s because they had this password syncing thing turned on on WP Fusion. They thought it was cool that they could see the user’s passwords inside their CRM, and they figured it would be helpful for their customer support people. The problem is it really gets into the works with regard to when people try to reset their password, and it can cause passwords to unexpectedly be reset. It’s just not a good idea. It gets in the way completely. So for long story short, I wanted you to know that this ability is there, but I also want to reiterate the warnings that WP Fusion themselves give about it on why you should not be using this function. All right, so that’s basically the gist of how to handle user passwords. The short summary version is this. I personally recommend that you let WordPress auto-generate passwords. You do not ask people for their passwords, let the system auto-generate it. Send them an automatic email. That email will contain a link which they then click on, go back to your site, and let the system generate a password for them and they can store it.

You should not ask for the password on on the checkout form. You can. It’s not a security risk to ask for that password on the checkout form. It’s just that it’s additional clutter, and it’s a pain in the butt. So I would just let the system handle it automatically. And this is what I do in all the membership sites that I build, and it’s just not a problem. You might think that, Oh, my gosh, my users will never be able to figure that one out. I have not found it to be a problem at all. People know how to do forgotten password functions. This is not rocket science. But if you would like to let people to choose their own password on checkout or on registration, you can do that. The big thing is, don’t ever try… You can. WordPress will not allow you to store passwords in in text. I would do not recommend that you try to use the Fluent CRM syncing functionality in order to store a password in your CRM. Don’t do that. Bad idea for multiple reasons. It will give you problems, I guarantee it. Just keep it simple. Let the system handle it.

WordPress is pretty good at it. Now, speaking to other systems, of course, the setup that I am building here is using WP Fusion, Fluent CRM. Even if you were to use another CRM, we’re using WP WP Fusion. I’m using the setup that I’m showing you here. Now, what if you were using another system, like wishlist member or member press or something like that? They all are essentially doing the same thing. Now, the interface is going to be different. They also probably don’t sync with the CRM in the same way that WP Fusion does. But a lot of them, when they have a registration form, they’re going to ask for the password. You probably have an option to just auto-generate it. If that’s the case, I would recommend that you go that route. But if your registration forms for your membership site plugin ask for the password, that’s fine. It’s still going to go into WordPress and get stored in an encrypted way. Same basic idea.

And then people can choose the password reset function if they forgot.

And that’s the way it is. Don’t try to email them their password and their welcome email.

You just shouldn’t be doing it.

Okay, that’s about all for that. And I will see you on the next video in the series. Real quick, I got a question for you. Are you subscribed to the WP Edge? If not, you’re missing out. It’s actually my weekly newsletter. I send it out every Monday morning. I spend 2-3 hours on it every single time. It’s pretty well developed. We’re well over 500 issues in. And it’s really specifically aimed at people who are using WordPress to run businesses. We talk about, yes, we talk about some tech, but I’m also talking about ways of utilizing the tools and plugins of WordPress to conduct business and create an automated business. So if you want to tackle WordPress from that angle, join me in the WP Edge. I’d love to see you every single Monday, and let me know what you think about it. I’ll see you in there..