In this episode:
Discussion – Feeling insecure about security (Part 1)
It’s been a little while since David and I did a podcast episode about something tightly related to WordPress. For a few weeks, we’ve covered some more personal topics and focussed upon client interactions and personalities.
This week we’re back to WordPress but in the guise of security. Sadly, dear listener this episode ran on for so long that we ended up splitting it up into two parts. This is the first and you can hear part two in a week, which will be episode 141.
We split this subject up into some sub headings as follows:
GENERAL STUFF FIRST
1. Non WordPress security
GDPR (remember that?) and Data protection (looking after client’s personal date). What do we do regarding ensuring that our clients and visitors data is kept safe and that we’re following the policies that we have are up to date.
Do we expunge all of the data that we no longer need? Do you still have client SSH keys in LastPass, are form submissions being kept for longer than they need to be? Have we got backups stored in some repository somewhere, gathering dust, which belongs to an ex-client? A backup that contains all of their site config.php data that you probably should have gotten rid of several years ago? How do we manage all this?
David is a digital nomad having laptops that connect to shared/public Wifi. Could this be putting data on his laptop at risk? Is this something that we need to worry about under law or is this just worrying for the sake of worrying?
How do we share password for WordPress websites with clients? There’s great service called 1ty which allows you to send passwords or anything else that you want to send. As soon as the recipient reads it, the service deletes their version and so nobody can get at it again. There’s also the use of password managers to send passwords securely. I use LastPass and this enables me to send passwords to fellow LastPass users in a way that never reveals the password, but enables other people to use the password in their browsers.
Whatever you do, I hope that you’re using a password manager?! Please tell me that you are! You need to be using unique passwords that you cannot remember because them are too long and utter nonsense, including lots of odd characters that you’d never use otherwise!
Are clients sending you their login details in plain text emails which the entire world could read. Do they even send the username and password in the same email! What do you do with those emails? Are you also advising your clients that using the password “monkey123” is not advised as WordPress can be brute forced against a vast array of known passwords.
What about passwords clients share with us when we take their domain registration account over at during a project. Do you make sure that your clients alter their registrars login credentials after you’ve had access so that you cannot be accused of doing something in the future?. David always tells his clients to change their passwords in this way, but says that they just don’t do it!
Google Domains (and some others too I’m sure) allow you to delegate each domain to another user who can then gain access to the domain that you set up for them, and if need be, then can revoke your access. I think that this is a great service which could have saved me hours in the past.
2. Sites we don’t manage
Do we have a responsibility to inform clients about security if we recommend WordPress? Many people take the opinion that WordPress is not very ‘secure’. I think that this is a myth and is based largely upon the fact that WordPress is such a giant surface area of attack. The software is well maintained and updates to core can be automated. It’s really the plugins and the themes that are the problem as there is no way to really keep all of that under control.
So how much of that do we need to communicate to our clients. Do they need to know anything? Do we need to pre-warn them about the fact that all websites are under attack, or do we just brush this aside and tell the clients nothing?
What about updates, how often to we perform updates to plugins and themes? Do clients need to be kept up-to-date about this too? Are you in the habit of sending them reports about this kind of thing?
Do we restrict plugins client may want to use?
Do we add a Security Plugin for them and can they manage it? Perhaps this is a cheap way of keeping clients who don’t want to pay for care plans in some way protected?
Perhaps you roll a whole heap of security related information in your care plans? I myself mention backups, uptime monitoring and some kind of firewall. David offers to get hacked sites back up and running in the state that they were before any hack. Backups will only work if the hack is recent enough that restoring them won’t destroy any new content that’s been created.
We also discuss whether or not we advise clients on how to pick plugins as well as what roles we assign to users – spolier, we think that the editor role is all that’s needed!
We completely ran out of time making this episode, and so, joy of joys, you get to hear part 2 next week!
Mentioned in this episode:
1ty – One Time Password (or anything) sending service.
The WP Builds podcast is sponsored this week by…
We thanks them for their support of WP Builds.
Transcript (if available)
These transcripts are created using software, so apologies if there are errors in them.
Nathan Wrigley: 00:00 Welcome to the WP Builds podcast, bringing you the latest news from theWordPress community. Now welcome your host, David Waumsley, Nathan Wrigley.
Nathan Wrigley: 00:21 Hello there and welcome to this episode number 140 of the WP Builds podcast, which is entitled feeling in secure about security part one. It was published on Thursday the 8th of August, 2019 my name is Nathan Wrigley from picture and word.co dot. UK, a small web development agency based in the north of England and I'll be joined in a few minutes by David Waumsley from David Waumsley.com because it's a discussion episode this week and we'll be talking about Internet security like I just said, but a couple of things before we begin, if you wouldn't mind heading over to the WP Builds.com website. I've got a few links I'd like to share with you. The first one is the subscribe link, so that's WP Builds.com forward slash subscribe. And there you'll be able to join our email list and be notified about updates, podcast updates, news updates that we put out on Monday, and also updates to plugins when there's deals and promotions offered.
Nathan Wrigley: 01:19 We'll let you know about those. Also, you can subscribe to us with your favorite podcast player. Join our 2,200 strong Facebook group and find out what we do on Youtube and so on. So that's WP Builds.com forward slash subscribe. The other one is WP Builds.com forward slash and deals or you can just click the deals link in the main menu at the top of the website and over there you'll find something akin to black Friday. It's black Friday, but every day of the week you can get significant amounts of plugins and themes and chances are if you're in the market to buy someWordPress product, it's worth heading over there and seeing because you never know. There might be something there that, uh, that you can snag a deal on. WP Builds.com forward slash contribute. If you'd like to join us on the podcast and share some things so that the community at large can understand something that you recently did that you're proud of and WP Builds.com forward slash advertise.
Nathan Wrigley: 02:13 If you would like to advertise on the WP Builds podcast, we have banner ads and audio inserts so that you can get your product out in front of a wider audience. A bit like the page builder framework have done, do you use a page builder to create your website? The page builder framework is a mobile responsive and lightening fastWordPress theme that works with beaver builder elementor or brizy and other page builders. With this endless customization options in theWordPress customizer. It's the perfect fit for you or your agency. Go to WP dash page builder framework.com today and we thank the page builder framework for supporting the WP Builds podcast. Right. Let's get stuck into it today. We're talking about insecurity of security. It's part one. We've got to the end of this episode and realized it was far too long. So we kind of cut it in half. So you've got part one this week followed by part two next week. And in this episode we talk about all of the, the usual security stuff that might be affecting WordPress, freelancers andWordPress developers. So we talk about actually quite a lot of nonWordPress stuff, things like passwords, GDPR, that kind of thing. And then we talk about the things that we do with the sites that we manage and care plans and security plugins and so on. But there's more next week for now though, I hope you enjoy this week,
David Waumsley: 03:36 this discussion we're calling feeling insecure about security. So we thought it was probably time that we discussed something that was kind of more practical. Nathan, we'd been a bit sort of tree huggy recently, haven't we talking about kind of personal stuff? Yeah. You've got really into your psychology and your personality types and things like that as well. Yeah. So this is back to, uh, back to solid ground, should we say? Yeah. So we're talking about what actually, well, we were happy with it now cause we've already had a chat. But I think so many of our friends don't feel they've got theirWordPress security or the security sorted out in their business. So we thought we'd have a chat about all different areas of that. Yeah. So we're actually quite organized, aren't we? So we've actually got some categories of stuff to talk about. Yeah.
David Waumsley: 04:23 One, I suppose it's always good to, um, to sort of say at the beginning that, you know, there are people in theWordPress community who live and breathe this stuff. You know, they literally do work for security all day everyday. So we're kind of, um, we're kind of cribbing our collective memories about things that we've seen or things that we've heard. And, um, but I, I would say that, you know, if you've got a real security, like proper concern about something, then, um, then this is probably not the place to get the, the perfect advice. No, exactly. And you've done great interviews with people who know this stuff. But yes, I guess W W we're coming at it from a different angle, aren't we as business owners who have to make decisions [inaudible] right. Bow What we're gonna you know, take on board from experts. So yeah. So first thing perhaps to talk about is the nonWordPress security side of things.
David Waumsley: 05:15 So we've had GDPR and we most countries have some form of data protection where we need to look after personal data. So yeah. How, how good are you in this? Well, kind of delete stuff. I do, I've, you know, I've set up all the gravity forms now so that they expunge the data after a certain period of time. I can't remember how that works, but basically most ingress of data for me comes via gravity forms. And so I have set whatever the capabilities in gravity forms to expunge all that data. So I can't remember how it works, but that's the way I'm dealing with that kind of stuff. I'm still, I'm still a bit mystified by this whole GDPR thing. To be honest. I still have yet to hear a story of somebody ordinary like me who's been bitten by it, but I think it was a bit of a wake up call.
David Waumsley: 07:00 Yeah, I'm sure that's the same for all of us. You know, when, when we suddenly lose a client, it's not right on the top of my list to go through lastpass and expunge all that. Um, it's not right at the top of my list to go through and check the, I've disconnected and removed all ssh keys and things like that, so I can't log into their site anymore. Um, but I do periodically go through the settings in my ide and just delete sites. I have no idea on my Mac what's happening to those ssh keys, whether they are truly being expunged or not. But I am, I am cleaning it up as and when, but I don't really have a, a process of doing it at the, the moment, the ics to work with them. Yeah. And you know, there's something I should be more conscious of because I'm, you know, been a bit of a digital nomad and I'm working mostly from my laptop and I'm often connecting to shared or public Wifi as well.
David Waumsley: 07:57 Do you use a pen? I do a lot. And most of the time I'm renting a place where our, you know, Internet's kind of our own. It's separate. So that's kind of okay most of the time. But you know, something like that I have to be really careful on, particularly when I'm, when I am a FTP in. Um, in fact, I did this recently is in Thailand before and I went to connect to my FTP and I realized I was on the shed. But you know what, my FTP file Zilla actually stopped me from connecting. Oh, nice. Yeah. So I was surprised about that. I really don't know, but it just wouldn't for the first time. And then I stuck my dongle in which of course is ours. But I mean, again, you know, it's one of those things I was it a change in ip address. Was that presumably, presumably it can't know what the type of, um, you know, the type of sharing of the Internet connection is. I don't suppose it knows that, but maybe it does. Maybe there's some amazing mystery stuff going on. Some flag in TCP
Nathan Wrigley: 08:56 connection that, that tells it this is shared. I've, I literally don't know how it would do that, but I always, I always use a VPN if I'm out and about, you know, if I, and I, because I'm basically based in the UK and there's always a, you know, a connection, uh, somewhere nearby. I very rarely have to use it to be honest, cause most of the work I'll do at home and, but if I go into a client's office or something, I just switch it on. Um, make it so that everything goes through there and you don't even notice. It's just on my Mac. It's a little tiny, basically a green.in the bar at the top. And so long as that's connected, it's fine. But yeah, I do take those precautions. I pay for a VPN, um, annually.
David Waumsley: 09:37 Yeah. Oh, excellent. Yeah. So I d yeah, it's easy to slip up on those things I think. But, uh, anyway, no issues so far. But uh, yeah, so one of the things, um, there is something we were talking about earlier, something that I started doing because I saw other people do it and that's use a service which is, well it's said as time, oh sorry, one time, but it's actually the URL for it. If no one's seen, this is the number one t y. Dot. Emmy. And it's a way of sharing passwords with the client. So it's a self-destruct thing. So you put in your password, you share the link to the client. When the client opens it, they can take the password, but as soon as they've dismissed it, it's deleted.
Nathan Wrigley: 10:22 Yeah. I think this is a really cool service if we can take them on face value that they are in fact managing the data. So there's obviously that caveat, but let's assume that's true. So nice idea. I am. I recently became aware that lastpass has the capability to share, excuse me, share passwords in, uh, in quite a clever way in that you can share a password, but the, the other person, so long as they're a lastpass user, they, they don't actually have access to it. They can make use of it but they can't see it. So I think it's quite ingenious, you know, so it can fill out a log in field, for example, inWordPress, but it, there's no way that you can actually get that password out and look at it and scribble it down anywhere. So that's quite a nice way of doing it.
Nathan Wrigley: 11:06 And I would really, really strongly recommend that if anybody isn't using a password manager, that the state's, the way things are at the moment, you really should be, you should never be reusing a passwords. They should be long, horrifically complicated, including all sorts of jibberish characters. And um, like I say, never reuse them and that the human brain can't keep up with that. So we have to, we have to give that knowledge to something else. And a password manager like lastpass or one password or dash lane, all of these different rivals, they're worth investing in, I would say.
David Waumsley: 11:43 Yeah, absolutely. I mean, I didn't know that you could kind of share last past like that, but you certainly, you told me how it kind of works because I've never really shared with someone. Yeah. So you hadn't
Nathan Wrigley: 11:54 proactively done that. Somebody shared one into me and then I, I was quite amazed how it worked. Actually. The, the problem of course is getting these passwords and things like this to your clients because virtually none of them are using a password manager. They, you know, they, they're amazingly willing to share their information towards me. Like, you know, if they bring theirWordPress site to me, they'll quite happily send me an email showing me their username and password and what have you for the admin account. Uh, it flies over the Internet all in the clear, in an email, you know, unencrypted. And I'm always quite amazed that people are so willing to do this. I try when I communicate with this stuff with clients, I try to send this stuff, um, through things like last, last pass. But obviously most of them don't use it. So then I can try, you have to be a little bit security conscious. So I might send the logging user name or email in one service. So that might go through email. Then if I know they're email, sorry, their um, mobile phone number, I might text them the password. I'm adding a little bit of security but frankly it's not particularly secure.
David Waumsley: 13:04 Yeah, exactly. The visa I use the one a time is because of that link because of the trying to get over to the client. This idea that security is important because I think nearly every client who's given me a password and then they do freely share, it gives me one that I think is so easy to crack that I don't think I've ever been sent anything that's been a long complicated password.
Nathan Wrigley: 13:28 No before. And we do know thatWordPress getting to WordPress, I suppose that um, it is possible to brute forceWordPress. You know, you can just keep having a go at the, yeah. The username and password. And so if, you know, if your client is using a ridiculously simple password, you know the word monkey one, two, three or something like that. And um, there's a, there's a bit of education to be done there and I can't see why we shouldn't be having those conversations. Yeah. Yeah. I mean I am
David Waumsley: 13:58 conscious as well. I mean, I say the same thing every time, but I don't think anyone's ever done it. So, uh, you know, I will help someone to move their, their, um, domain to our site when it's built and they'll give me their login to their domain registration account and that, and I ask them always to change it after the, let me have it cause I shouldn't, I shouldn't have that kind of information. Yeah. And um, they never do.
Nathan Wrigley: 14:24 I think that's that. I think that's really an important conversation to have because obviously if something were to go wrong at some point in the future and they scan around in their brain who, who, who's had access to this well David David warms that he wants to have access to it could be him. Maybe he's done something. There's um, there's a feature in Google domains that I've mentioned before, so it's goo domains.google.com whereby you can delegate, I think is the word they use. You can delegate the ownership of, um, domains to other people so you could purchase the domain on their behalf because you know, they don't understand that process and they don't want to set up the DNS and then you can delegate it to an email address. And from that moment on, at any moment of their choosing, if I've understood it correctly, nobody's actually deployed this with me yet, but I understand that they can, they can then take it from you, uh, trivially. You know, they don't have to go through the whole process of moving registrars and all that kind of stuff, just keep it where they are. But they can take control of it. And then when you log into your Google domains account, it's gone. You know, you know how no longer have the capability do that. I'm sure that's the same with other registrars, but I've not come across that before. I quite like it.
David Waumsley: 15:35 Yeah, that is good. I mean, I certainly come off from a culture of, I'm looking out for this coast kind of responsibilities, making sure that you're always protected. I mean, I worked in quite a few places that did childcare, you know, and you always sort of made sure you did certain protections so you could never be accused of anything. Yeah. You wouldn't leave you, you wouldn't leave yourself alone with a vulnerable person. Yeah. That kind of thing. So, you know, I think it reminds me really to look into those kinds of things. So that's why I'm kind of keen to say change your passwords, but when they don't do it, you're still kind of vulnerable.
Nathan Wrigley: 16:10 Uh, yeah. It's interesting as well. You know, the recycling of passwords. I think the general consensus now, and I am going to be shot down in flames for this, I'm sure, but I'm speaking from a position of taking somebody's advice, let's say, who knows what they're on about. They used to be this policy and companies to sort of recycled your passwords every few months, you know, swap it because you haven't changed it for a couple of months. Realistically, if your password is jibberish and long and complicated, there's no real need to change those things so long as, uh, you know, you can be sure that nobody has had access to it. The, the initial one will be good. Um, uh, anyway, yeah, a bit of an aside that,
David Waumsley: 16:51 yeah, yeah, absolutely. Well, should we talk about, we don't do this cause we tried to get people on their care plans mainly, but I still have some of these people who, that have sites who still come to me, but I don't manage them on a ongoing basis. So, so there's some questions there about security. Do we, they're going to manage theirWordPress site. We've probably recommended it to them. Do we, do we have a responsibility then to inform the clients aboutWordPress security?
Nathan Wrigley: 17:19 I thinkWordPress security is a, is a, is an interesting one because it, because of its massive surface area, it has a massive attack vector, you know, because it's just so many people using it. But, but that is to say that isn't to say sorry that WordPress core is, is a bad piece of software. I would say that it's, you know, it's updated constantly. We do get these occasional little, um, quick minor updates for security reasons. They can push it out a central place. Now that update is being signed from now on. So that's an added benefit inWordPress's ecosystem that all the CMS is possibly don't have. Um, I would sayWordPress core itself is pretty darn good depending on what hosting environment you've got it. Um, it's the plugin architecture that that causes the problems. You know, the plugin and theme architecture, which is mostly to blame.
Nathan Wrigley: 18:12 And I, I do have this conversation with people who come to me. I do say, look, it's not reallyWordPress, it's just, it's just the nature of online software. It's, it's liable to be attacked. You've got to take, there's got to be preventative measures. Whether that's, well, we'll come to this, but whether that's backups or some sort of firewall, the, these are all good ideas, but you can't protect yourself fully. You've just got to do as best you can and have something ready for the rainy day when it, when it goes down and all goes wrong.
David Waumsley: 18:44 Yeah, absolutely. That was really beautifully put actually. No, I think that really sums it up. I don't, you know, I think when I have tried to explain it or largely it's been the colleague that I worked with who add to explain it to clients, I don't think they really took it on board. I think may be because their focus was on getting a website or not. Or they yell at Ar. So even though they were told to update it, you know that this is kind of important. And also, and I don't know who else does this or, I mean I'm kind of a bit sniffy about plugins. I just don't like to get involved in putting the site together with plugins that I don't feel I trust, you know, so does usually a warning for, for clients to go, you know, or plugins that are on the repository on all created equally though all safe as each other. That's
Nathan Wrigley: 19:31 absolutely true. I mean, I suppose some little easy, too easy to consume bits of, I'd hate to use the word wisdom, but you know, that had been passed down to me as wisdom. So I'm, I'm passing, I'm not claiming wisdom, um, is you know, don't use the default admin account. So change that. You make sure that your passwords are really obscure and strong and stored in some location where they can't easily be accessed without your authentication and um, and update everything. You know, if you are going to use the plugin architecture ofWordPress, which let's be honest, most people do, then make sure that you update everything. Do your diligence, your due diligence to make sure that you've got at least an angle on how reliable and updated the plugins that you're going to deploy are. And then make sure to make sure to jolly well, update them as soon as there's an update available. I would say daily, you know, not everybody can manage that, but it would help if you could do it on a daily basis more if possible. If you can automate those things and you're happy with the consequences, especially now that we've got the psych health option inWordPress, you can update much more on an automatic basis and get feedback about what's gone wrong. Should something go. Um, then you, you're protecting yourself as much as you can.
David Waumsley: 20:51 Yeah, absolutely. Do you know, I would love to know those people who do just build and don't have a care plan whether they send their clients off with a security plugin installed, whether they do that or whether that's the client's responsibility. Because since you're thinking about it now, I mean, those sites that didn't come on that care plan ball before, I had one I sent off without a security plugin on. I didn't think they would understand what those plugins were telling them,
Nathan Wrigley: 21:18 which gets us into the whole licensing issue, which we'll say for another day about whether, whether that's a legitimate use of the license that you've given or you know, if it's a free one, that's fine. Um, but the, oh, I forgot more. I was going to say, now it's completely gone out in my head. I'm sorry. I'm going to hand it back to you. Oh, that's annoying. Okay. That's okay. Should we move on to what we kind of do? Because we really were their care plans. I just, I thought it'd be interesting to talk interesting to talk about what we actually promise in our plans to the clients. I mean, you know, do we promise to clear their hacks if they get them? Well, it's interesting actually. I've just remembered what I was going to say and that is that w when there's a client who doesn't want to be on the care plan, I have a, I have a seat.
Nathan Wrigley: 22:02 It's not really a sequence of emails in that it's not really automated. But I do send out emails shortly after launching the site and handing it over. And I do say, look, you know, you just be mindful that a, it's a bit like driving a car without insurance. I don't actually use those words, but that's a decent analogy. Um, you cannot really justifiably come back to me having crashed it. Uh, in this case, you know, it's been hacked or I did something horrific and now it won't load. The site won't display any content or whatever. You can't really legitimately come back and say, um, look, I think it's your responsibility to fix it. I do make that point. I don't really drive it home if they've said we don't want any part of your care plan, but I do make the point that, look, B B, be mindful that this is a, this is a possibility.
Nathan Wrigley: 22:50 And then we kind of leave it there and it's not really come back to bite me yet. So, um, anyway, sorry. Uh, regarding care plans, what do we promise? Yeah. I had to open mine up actually and have a look. I've got various levels basically regarding the security. My, um, my care plans speak about backing up and the frequency of that backing up, the more you pay, the, the more often that bucking up takes place. Um, um, uptime monitoring. So monitoring in terms of whether the site's gone down, there's loads of services out there, which you can use some of them free, some of them paid where you can get a a five every five minute little ping of the website or possibly more if you pay and it'll tell you if something's gone down. And I've found those to be very reliable and that genuinely get the emails and they do go down and genuinely get the emails and they do come back up. Um, and then it's things like, um, whether or not there's like security plugins installed and licensed and paid for so that that are kind of three areas which I do really, you know, uptime monitoring some kind of security solution and backing up.
David Waumsley: 23:55 Yeah. But tell you, I mean it's, I actually say that I'll get them back up and running again if there isn't any, because I do mention this one but we talked earlier as well but and in some ways we're the same but we probably before this goes out we'll go and change our terms and conditions of it. But um, yeah you use, we'll put them back but not necessarily without losing some data because you've got to use a backup, which is pretty much what I'm going to do as well.
Nathan Wrigley: 24:26 Yeah. So why when we were talking before this call, it did suddenly occur to me that, you know, there might be problems with my strategy. But anyway, the principle being that backups are my, my best line of defense, if you know what I mean. It, what I mean by that is it's something that I can proactively do. I can do that. I can make the backups, I can put them somewhere safe. I can make sure that they're stored for the appropriate length of time so that they're available to me should something go wrong. What I don't have control over is, is when a hack will take place. So backups to me feel like my best foot forward if you like. And then on top of that as security plugins and what have you. But yeah, the problem, which fingers crossed touch wood, all of that stuff which hasn't really arisen too much for me is the whole notion of a site getting hacked.
Nathan Wrigley: 25:16 It needs to be cleaned up and yet the backups are, are so new. Sorry, the attack took place so long ago and the, the vulnerabilities been there sitting, waiting, let's say it was in there for three months, but the site has been updated so many times within that three months that the backup is kind of pointless cause they've written loads of blog posts or they've added a whole bunch of content that is a bit of a problem. Um, and one that I'm sure other people have faced and I don't really have a hand on heart. I don't really have the perfect answer for that.
David Waumsley: 25:51 No. Well, I, I'm, I had to deal with quite a few hacks because of people who didn't come on home care planner who haven't updated, have come to me and just want only yesterday. And um, it's, I've had to, I mean, they've not lost any data because I have had to go through the task of cleaning up all the files and hoping that the hack doesn't come back. And so far it's been good and, and I've been lucky as well with my own sites, so they haven't been hacked once I'd been managing or, well that's not entirely true. A couple did, but they were very quickly found and they were very simple hacks and were salted. So I think, yeah, at the moment, I just wonder if that's, yeah, so in a way we promise to get people up and running, but we're not really guaranteeing that we will secure their data and I've never really fleshed this out at all. Yeah, that was the interesting
Nathan Wrigley: 26:44 thing that the conversation before we recorded brought to light is that I haven't really fleshed this out either. I haven't really made a, made it explicit or differentiated in any way that, you know, the backup might not be the most recent. In other words, the hack, the hack could take place months ago and so the backups will, will work. There's nothing wrong with the backups, but they might not get you back to exactly where you want to be. And obviously let's say for example, an ecommerce site that's absolutely unacceptable. It needs to be, um, including all the orders. And I think at that point I'm weighing up time versus money. I would, I would be reaching into my wallet as part of the care plan and paying for somebody to, to go through that. Somebody who is an expert in this with a fine tooth comb looking at it. Um, because you know, after, after a few hours of my time, scraping around, the payment to the professionals would, would make perfect economic sense and I would feel happy that I had some kind of agreement with them that they'd done their job to the highest possible standard. Whereas I think the nature of the beast with with acts, you can never have that certainty that you yourself have cleaned it up unless you're a bit of an expert.
David Waumsley: 28:04 Yeah, well that's what I'm, I'm waiting to find out soon because so far they've been cleaned up and I've been able to do it within reasonable time with, with various scanners. In my case, wordfence is been very good, positive, a false positive. So a lot of them, but as long as you can kind of work out what's happening, it's cleaned it up and it's done it for me, I guess I would need to do the same because it's happened so infrequently that we've hacks and you know, not once I'm managing that, it would probably be better to know that there's a service I would call upon.
Nathan Wrigley: 28:38 You see that there are services like, um, WP security audit log, which realistically will be your absolute best friend should you need this. The problem is it's a bit like insurance. We sort of begrudge, paying for things that we don't need until suddenly we need them and we think, oh, why didn't I spend a fortune on the insurance that would, would, would help me out at this point? You know, I went for the cheapest possible option. Um, and, and you know, it makes for a good starting point, you be able to see where this comes from. And I think that's the problem. The, the fear that I have a little bit around cleaning up sites is that without those logs, without a real fine grained understanding, my worry is always, well, how did it get there? What was the thing that allowed it to she there?
Nathan Wrigley: 29:25 So cleaning up is one thing. Okay, I've removed, I've, I've removed all the evidence of it in a sense. I've, I've hoovered around a little bit and cleaned the cup, but what put the mock on the carpet in the first place. How did that happen? And with a good security logging strategy, you increase your chances dramatically. Now it might be that it was some vulnerability which are plugging update then patch. So it can't happen again. So you're fine, but you, unless you've got those logs, I suppose you're not going to know that. Um, and that, that's where my worry comes from cleaning up because of what you just said. You know, you're hoping that, that you've done it. Um, but the hope for me, um, would, would make me lose sleep a little bit, I think, which is why I would, would happily pay somebody to do that.
Nathan Wrigley: 30:13 And do you think they would always get to the bottom of that? Because I don't suppose they would. They might just take half the same approach, but I presume not having enlisted the services of these organizations, I presume there's some standard agreement that you signed, which places some responsibility onto them for, for, you know, having an, having another look. Should it re-emerge I don't know, perhaps in the comments somebody could, uh, could highlight that to us. I just feel that security is so ephemeral, so constantly on the move, you know, the, the, the ice is always shifting that, um, you need to be really on top of this to understand what's going on and it's just not my area of expertise. I have a, I have a anecdotal interest in it, but I'm not an expert on it, you know?
David Waumsley: 31:01 Yeah. But I think it always comes down to, um, you know, who my clients, they won't pay a lot for their maintenance. You know, I've set it up so it's very affordable. So there's not much I can spend on these kinds of services. So the best I can do is a backup. One thing that did cross my mind, we didn't talk about this earlier, which was, um, when you go for a incremental backup system instead, if you thought you had something like a, any commerce site that was busy, you know, so it does a backup every time somebody makes a new order, say,
Nathan Wrigley: 31:33 yeah, well, um, my strategy with that is I just take a full backup every day. Um, that, that is literally the, the, like what I do, you know, there's an, and within that, obviously I've got the database, I've got the files and what have you. Um, but I, I could see the point if you've got a big ecommerce store or something where there's actual, you know, importance in this, a database update, um, every couple of hours would seem like absolute common sense. Absolutely. Makes Sense. Yeah. I think some of them though are running on as soon as the event happens. So as soon as an order comes in, some hook and fires offer. Yeah. Again, why not, um, no reason not to. You've just got to have the capacity to store that stuff and the capacity for that to be happening in the background and not, not destroying the, uh, the speed of your website loading, I suppose.
David Waumsley: 32:23 Yeah, yeah. That's the big thing, you know, because I'm, I'm a big fan of wordfence and, um, but I'm not a big fan of how heavy it is. Uh, you know, so I, I've, you know, for a little wild until just recently there was some hacks that friends of ours got, you know, I was really thinking about just converting over. So something else did the scan in and it, you know, it saved on server resources, but I've completely turned around within, you know, a week into the fact that I'm not gonna change what's been working for me because of the scanner. So good.
Nathan Wrigley: 32:57 It, this is in wordfence you, you like the, the capability, even though it does use quite a lot of CPU cycles and times out on, um, you know, on, on cheaper hosting.
David Waumsley: 33:07 Yeah. Okay. Well, it seems to be okay for that, but it's, I mean, my rationale behind it now, and I'm starting to think a little bit about treating sites differently because largely I've put the same in for everybody's sites. And there were some sites which just know that they could easily be static sites, really the updated maybe once a year and nobody goes into them. And I treat them the same as I do a busier side where they might get updates on them every couple of days. You know, what about them?
Nathan Wrigley: 33:39 What about the restriction of roles and things like that? Do you, do you restrict the capability of your clients to interact withWordPress in any way or do you give everybody admin permissions and just sort of hope for the best?
David Waumsley: 33:52 Yeah. Well we talked about this and I realized that in fact I did realize before, but I've been such a full on this really. I did give them all the owners admin rights and anybody extra they wanted to. I gave them lower roles and I've really only just worked out months back really that all they need is to be a an editor role because the page builder I'm using, I can give them full access to everything they need on that and while I'm managing their sites, they don't need to put in a new plugin or anything and that just causes big problems. If they do. And you said you said it perfectly before that a they don't know anything else. Yeah.
Nathan Wrigley: 34:35 I'm wondering about all this sort of stuff. Who should this, all of this go into my, if you like contract at the beginning of the project. In other words, should I explicitly say, look, I'm taking daily backups. Um, there'll be stored but if there's a vulnerability and there's a hack, I can only restore the backups that I've got and you know, and it will have to go back as far as the vulnerability being discovered. But equally with this, should I be saying, I wonder if anybody does do this. Should I be saying, okay,WordPress is got this user, it's got this user permissions, user roles system. When we hand over the site we're going to give you the editor role and we are going to keep the administrator role for ourselves whilst your, whilst you've got the site in our care, obviously you know, if they demand the site, I've got no problems with uh, giving them all of the files and everything. And at that point you can have the administrator role. I'm just saying this is a possibility. I don't, I don't have any strong thoughts on this, but maybe explicitly saying whilst it's under our care, whilst you're paying for our care plan, our advice and our policy is that you will have the editor role and you will, and we reserve the right to keep the administrator role because it can break things and we don't want the site to being broken. Dewey, he said sounding terribly condescending and patronizing.
David Waumsley: 35:58 No, but you just said the one thing about them not knowing anything else is it just because I'd already decided that of course it's their site so they can have an admin role, you know, even when we're looking after it as far as I'm concerned. But what I didn't need to do is to kind of give them that early, just wait until they request it. So, which I'm doing now. Um, they automatically go in and learnWordPress as an editor. So they don't see all of the, the stuff that I have to deal with that's just distracting for them. But I'm pretty sure just saying that alone. Um, they're not going to ask me for the administrator role know. It gets very unlikely. So, so it's taken care of.
Nathan Wrigley: 36:40 Yeah, quite a lot of times, you know, you'll do like a screen share or some way of showing your client what it is that you're, that you're trying to achieve. You know, they'll write you how do I do this? And you send them a lumen video or something of your screen and, and I will explicitly say, look, um, there's a whole extra set of menu set, which you won't see, but you'll have this one, you'll have, you'll be able to see this menu. Um, and, and they don't seem to mind, nobody's come back and said, oh that's weird. I want the, I want all of the capabilities that you've got. I've never really helped that. Um, I'm trying to think if that's true. Yeah. I can't re I can't off the top of my head. Remember a time where a client has gone, no, I want the full Monty in my case. Most, I would say most of my sites or sorry, uh, clients are somewhat afraid of breaking things and they're quite happy for me to deal with all those things cause they just want to log in, create content, Click Save, log out, go away, come back and next month or whatever.
David Waumsley: 37:35 Yeah. No, I mean mine comes out of the fact that I, I wanted to train people to use WordPress and their sites a bit more, but I think I've been initially a little bit over keen to expose them to everything that that is there inWordPress when they're just, they might as well ask for it. Yeah, they can have it, but I bet most won't ask for it.
Nathan Wrigley: 37:55 There's a couple of things that, uh, that I've been, that the editor role is incapable of doing and I can't remember off the top of my head what it was. But, um, you, I give the clients the editor role and then occasionally they'll ask me for something which is beyond the scope of the editor role. So there are various plugins on, I can't remember the name of the one that I just, I showed you before we started recording, but there are various plugins and obviously you can do this yourself if you want, but if you want to nice click a point and click interface, you can have editor role, you can upgrade the editor role if you'd like. So that it inherits just a few of the admin permissions. And I've had to deploy that a few times just because it made absolute sense for the client to have this. And for me not to do it all the time. So there are, there are caveats, there are times when the editor role will not work out. And um, I've got around it in that way. Uh, but, but it's fine. And then you asked them, sorry, go on.
David Waumsley: 38:51 I was just going to say the plugin that you mentioned, cause I still got the tab open is at the menu and would you access by Guy Primavera?
Nathan Wrigley: 39:00 Yeah. And I've used that a few times and simply put, it just enables or disables a certain items in the, the, it only works with the editor role and it enables or disabled certain things that I can't remember what it was that I needed to enable. It might've been something to do with media or a page builder or something. Um, and it fixed that problem for me and we could move on and they could do the task that they needed to do without really, um, compromising anything that I, I wanted to keep from them because they were an editor. Um, you've also put on here, do you, do you restrict things like, uh, what a client cannot blow? Do you give them full access to all that as well? Hmm.
David Waumsley: 39:41 I, I do. Um, and that that's included because I've been given them administrative roles earlier on and not so much now. They'd been added in some plugins, AC, I've tried to say this early too, most of them that, you know, it's your site so you can do what you like. So that's what seems like a good idea. And most of them haven't touched it, but a few have and certainly the sites where we, I don't manage them, they just have a knack for updating good plugins, but the ones that just seem to have a vulnerability recently. So that's given me a few thoughts. that's absolutely diabolical isn't it? You know, they install the plugin in which the vulnerability arises the very next day. It's almost like that. It's just bizarre. But um, yeah,
Nathan Wrigley: 40:28 the, the, the, you use the word ownership or something a moment ago and I think that that's kind of the point of it really. It's kind of, I don't make any claims on owning it, but whilst I'm looking after it, I kind of, I kind of obviously have a different approach to you in that you, you have been at least anyway, happy to give them the admin role and you want for them to be able to explore whatWordPress can do and learn what it can do. I think I've taken a bit more of a guarded approach, a bit more of a kind of, you know, castle and moat approach that um, there's certain things that I want to restrict them from doing just because I don't want the extra burden of, of fixing stuff that they break because as soon as they come onto the care plan, in a sense, I, I take on the custody of that.
Nathan Wrigley: 41:14 I take on the, the ownership of, of fixing stuff when it goes wrong. So the more the more hands that are, the more, well, what's the expression cooks spoiling the broth. The more cooks that we've got, the more chance that it will get spoiled and the more work that I will have to do. So, yeah, it's just a different approach and I bet, I bet. I bet our community is really split about this one. How much, what user roles you give them, what access do you give them? What do you tell them they can do? You know? Or maybe in some cases you even build sites and never even let them know that there's aWordPress log in. You literally do it all. They send you the copy, send you the images and you upload it all I supposed and, and that they don't even know whatWordPress is used for on that site. I bet some people are doing that.
David Waumsley: 42:01 Yeah, absolutely. Do you know what? I've changed my mind a little bit. Just having this conversation today about how I need to approach things because I am keen that they feel they have ownership and am keen that they learn to be able to do things with their sites because I think there's a demand for that amongst many clients. But I just don't think I need to give them too much too soon. I don't need to say they can't have it, I just don't need to shove it in their faces. And I think because my problem is exactly what you'll see in, you take on the responsibility for the site while you're managing it. And if you encourage them by giving them admin access to go and use plugins, then they're going to do it. And then, you know, then I have to say something like, you uploaded something that was vulnerable so you created the problem. Yeah. I don't want that conversation.
Nathan Wrigley: 42:49 No. And it's a difficult balance isn't it? And I suppose it would come down to, in your case at least anyway, it would come down to when the question is asked, you know, you're not going to refuse them should they ask the question. But my guess would be that if you gave them the editor role and everything was based around that, I don't think that many of your clients, because they're running a business, they've got something better to do. The website is a function of the business. It's not, it isn't their business. It's just something that, that, you know, enables their business that you probably won't get too many of those questions. They won't really ask. Look, is there some, is there some feature that you've disallowed me from using? My assumption would be probably that they'll think, um, okay, this is, this is the system that's been built for me. Here's, here's, here's what I can do. Um, and they might occasionally reach out and say, you know, is it possible for me to do this thing in which at which point you might need to have those conversations. But I think it'd be fairly few and far between.
David Waumsley: 43:47 Yeah, no, I think this is great. This is great chat for me anyway if no one else, but because it's actually, and I think this is the important thing, isn't it? When we're talking about security, you need to, you need to have a rationale, something that you believe in also. Otherwise you, you always feel a little uncertain about what you're doing.
Nathan Wrigley: 44:03 Yeah, yeah indeed. So we, we do, there is a case to be said for restricting what clients can do, you know. Um, do you, do you have like a password policy for, for clients? Do you enforce them to use strong passwords? I know that's kind of like going back to what we were saying earlier, but that was more about, um, you know, offs offsite stuff. Do you, do you force them to do certain things like that?
David Waumsley: 44:26 I think I've nailed it now because I, I set up their account and then give them the, the original strong password to go in initially. Yeah. And uh, now it's part of the security plugin that I'm using that it forces strong passwords. So if they try and change them or add anybody else in, they won't be able to use a weak one. So I think I've probably nailed that one. Oh, that's good. Yeah. So what you send them the, upon signup, you send them theWordPress email and they then have to use a new password, but the plugin interrupts at that point and it says, no, it must be a strong one. You can't give as a shoddy weak password. Yeah, that is good. I'd forgotten that they do that, but you're right. I, I'm pretty sure that I, and enable that on every site as well. Yeah. WellWordPress is pretty good at, I mean, he suggests your Pa, it gives you your password in the first place, doesn't it? So you would have to change it to a weaker one. Yes. Anyway, which I do like, but I mean I, it's literally in wordfence for me that and I think it's in many of them where you can just turn on for strong passwords to someone. Can't change it to something weak if they try. Yeah. Yeah. Now
Nathan Wrigley: 45:30 I have, I have something to ask you David, because we've now talked for 42 minutes. Mike. We are, we are no where near, um, through this subjects. My fear is that if we keep going, this podcast is gonna end up as like probably close to two hours. What do you think? Should we split this one in two and offer, offer our offer, our listeners the uh, the second part next week.
David Waumsley: 45:58 Yeah. Why not? I think that's a good idea because we could, we could talk a little bit on the actual tools that are out there because we haven't really touched on those. There's a ton of them. Yeah. Do you want to do that now or do you want to save that for next week? Let's save it for next week. Okay.
Nathan Wrigley: 46:12 Do that. Okay. In which case somewhat, somewhat surprisingly, we're going to split the episode up into two parts because there's just more to say. So, uh, we'll make it so that it happens next week. So we'll just follow on from exactly where we got to and um, okay. So for now, we'll, um, we'll knock that one on the head, but we'll see you next week. Thank you so much for joining us on the WP Builds podcast again this week. I hope you got something out of that and remember that next week we'll be talking about the kind of plugins and available options that are in theWordPress ecosystem. So join us for that. Sorry that we had to cut it short this week, but honestly, you don't want to listen to an hour and a half of David and I droning on about Internet security. The WP Builds podcast was brought to you today by WP and UP one in four of us will be directly affected by mental health related illness.
Nathan Wrigley: 47:05 WP and ops supports and promotes positive mental health within theWordPress community. This is achieved through mentorship, events, training and counseling. Please help enable WP and UP by visiting WP and UP.org forward slash give together, we can press forward. Okay. That's all most it for this week. Just a couple of things to say. Join us next Thursday, obviously for the next installment of this podcast. Join us on Monday when we'll be going through theWordPress news. Very early in the morning, I released a, an audio version of my take on theWordPress news for the previous week, and then at 2:00 PM UK time we do a Facebook live in which I'll be joined by some special guests in theWordPress community in the WP Builds Facebook group, which you can find [email protected] forward slash Facebook. It's very nice when people join us and comments and so on. It's really, really very lovely indeed, but that's it. I think so. Maybe I'll see you Thursday. Maybe I'll see you Monday, but I hope to see you again soon. I'm going to feed in some cheesy music.