Posted on

Piping Email with PHP and SiteGround

One of the fun things to do with computers is to think outside the box, to use tools for things they aren’t exactly designed for. Email is one of my favorite toys with which to play with. Email is universal, and everyone has it. So when you create a new user for it, everyone can now do that.

What can we make email do that it doesn’t do already? Well, email is a delivery system, so we can use it to not only deliver data of some kind, but also to trigger an event that causes a computer somewhere to do something. If necessary, email can also respond back to you.

In the early days of the web, there were email addresses you could send an email to with a URL in the body. It would retrieve the URL and send you back the copy. Email pre-dated the web on the Internet, so there was a time when people had email but not web browser. This was a great way to get to the web before you got a web browser. The downside was that most email at that time didn’t support images, but this was okay because most webpages at this time didn’t HAVE images. 🙂

I’ve also used email to deliver data and trigger processing. Last year for Mother’s day, I built my mother and mother-in-law digital picture frames based on Raspberry Pis. The front-end media management for these frames is a WordPress site. This gave me a convenient API already built to deliver images to. The problem is that my siblings are not programmers, so I needed an easy way for them to send images to these frames. Email was that easy way.

I created a system that allows them to send a picture via email. Each digital picture frame has an email address, and they can send pictures to it. While WordPress handles all the user management and image processing, SiteGround’s email system allows me to make all of this happen.

The way to do this is called a “pipe” because you are “piping” the contents of an email to a program of your choosing.

I’ll stop here and tell you upfront that if you are not a programmer or at least a very technical user, this is not for you. Programmers can write programs (like I did) to take the input and process it. Technical users may also be able to install programs on their server that will accept the input and do something with it. If you are not in one of these two groups, I suggest you go find a programmer you trust and hire them to help you do this.

In SiteGround, the process is pretty simple. You first create an email address, then you create a filter for that email address. In my case, I created momspictureframe@example.com (not the real email address) in my Site Tools.

Then I went to filters and created a filter for momspictureframe@calevansxample.com.

  • I gave it a name that I could recognize, “Pipe Pictures to Mom’s Frame”.
  • I set the proper condition. I want this filter to trigger any time any email comes to momspictureframe@example.com. So I set it to:
    • IF ANY
      And then, I set it to trigger on the TO email address.
    • TO EQUALS momspictureframe@example.com
  • Finally, I set it to perform actions. In this case, I perform 2 actions.
    • First, “Pipe to a program”
      This is where you need to be a programmer. I wrote the program necessary to process the emails and uploaded it to my SiteGround site. I have to know the exact path and program name for this to work. Even a good programmer is going to have to experiment a little to get this right. Still, once they get it right once, it’s easy to do it again for other pipes.
    • Second, I set a “Discard Message” action.
      Remember that the first thing I did was create an actual email address? This means that unless I do something, emails will actually be stored for this address. Since I never plan to log into the email server to view them, I want it to toss each and every email coming to momspictureframe@example.com after I’ve handed it off to my script for processing. If I wanted to archive the email for future use, I would drop this action.

That’s it. Assuming you have a program handy that will accept the contents of an email and do something, you can now trigger it using a SiteGround email pipe.

Once you understand the power of piping emails to programs, the possibilities are endless. The example I gave you was a simple one but by no means the only one I’ve written. Again, since email is ubiquitous and available on just about any platform, you can open up a whole new world of processing and interactions for your users.

One word of caution, be aware that email is designed to be mostly insecure. You need to build security into your applications to make sure that only the users you want to, can interact with your system. The easy way to do this is to check the sender of the email, but that’s also insecure. If you do this, it should just be one of the checks you do.

[subscribe_cta]

Posted on

What are Brute Force Attacks and Why YOU Don’t Have to Worry About Them

Exactly what is a “brute force” attack on a website? Just the name “brute force” conjures up a bad guy in a cheesy action movie. For most websites, a brute force attack can be very serious.

What is a brute force attack?

A brute force attack is exactly what the name sounds like. There is no deep logic involved in guessing logins or passwords, it’s just a bot that starts with a login of “A” and a password of “A” and works from there. It will patiently try every combination of letters and numbers there is until it finds a login and password that works. When brute force attacks started, that was all there was to it. Over the years, they have gotten more sophisticated, but at the core, it’s just a bot.

These days, you have bot networks that do this. The problem was that brute force attacks from a single computer were real easy to detect and block. So now a network of hundreds or thousands of computers work together to attack your site and guess a login or password.

Also, these days we have “dictionary tables” which are just lists of passwords that have already been used or words that can be combined together to make a password. A bot network can try thousands of times per second to guess a login and password. Your site is only as secure as the weakest password on it.

In addition to dictionary tables, attackers have gotten even smarter. As a site is hacked and all of the user info is pulled down, the logins and passwords for that site are added to the ones to try. They know that a lot of people don’t bother to create different logins and passwords most of the time so a login on one site is probably good on another.

How do you mitigate a brute force attack?

Well, there are 2 answers to this question.

If your website is not hosting with SiteGround

If you are not hosted with SiteGround then you need to start researching security plugins and configuring firewalls. We’ve talked about some of this before in previous blog posts. You will need to:

Install an application firewall and properly configure it.
There are several good plugins in the WordPress plugin repository that will secure your site against brute force attacks and other types of attacks. The top 3-5 are well respected and while I won’t recommend one here, you can probably find one that comes highly recommended and get it implemented. All of the good ones have a monthly fee associated with them but that’s what it takes to protect your site.

Require strong passwords for all users
We’ve talked about passwords before but it bears repeating. Strong passwords are your first line of defense. Your users might not like it but it will keep your site and their data secure.

Require Two-Factor Authentication (2FA) for all logins
2FA mitigates brute force attacks 100% because the login and password are only 2/3 of the login procedure. For the final 1/3, you have to have the person’s phone. That’s a game-ender for brute force attacks.

As with strong passwords though, users usually hate 2FA. You can limit 2FA to admin accounts but if an attacker gets into your site, you are compromised. So you have to decide which is more important and that’s a bad choice to have to make.

Implement a password rotation policy that forces new passwords at least every 90 days
Another one that users hate but is effective in helping prevent brute force attacks is requiring users to reset their passwords. This is another thing that users hate and if you do enough things in the name of security that users hate, you start to lose users. So it’s a tightrope you have to walk.

Bonus tip: Fail2Ban
In addition to all of those, my personal favorite tool is Fail2ban and WP-fail2Ban. Properly configured (and it takes a developer or network admin to properly configure) this combination can be a very powerful tool to prevent a brute force attack. It’s not easy to configure but it is very powerful. Fail2ban is open source and free, the plugin WP Fail2Ban has a pro version that seems to be worth the money.

I don’t usually recommend specific plugins but this one is unique. I have the free version installed on all my blogs that are not hosted on SiteGround and it works wonderfully. I am strongly considering upgrading to the pro version.

WARNING: This plugin requires Fail2ban to be properly installed, configured, and working on your server. Fail2ban itself has a couple of requirements as well. This is not a trivial plugin to get working. If you are not a developer or very familiar with Linux, get help.

If your website is hosted with SiteGround

If your site is hosted with SiteGround, go back to sipping your coffee. SiteGround has a full suite of tools already implemented including AI to detect brute force attacks from bot networks. This doesn’t mean your site is 100% absolutely secure, nobody can get to 100% safe. It does however mean that this is one less thing you have to worry about.

Wrapup

Brute force attacks are well known and well understood. There are tools that you can install that will mitigate the risks of them compromising your site. That having been said, your best bet is a hosting partner like SiteGround that deals with it for you to that you can spend your time making your site more awesome.

[subscribe_cta]

Posted on

Securing User Passwords with “Have I Been Pwned”

securing passwords

Most developers are familiar with the website “Have I Been Pwned?“. Most non-developer and non-techie people have probably never heard of it. That’s ok, that’s what this blog post is for – to not only tell you about it, but to show you how to use it to keep your WordPress site safer.

First, the term “Pwned” originated in a game. It was a typo because the letters “P” and “O” are so close to the keyboard. Like many good mistakes in gaming, it was appropriated and now is common slang in technical and gaming circles for “Owned.” Depending on the context, it can mean that someone really beat you bad in a game, or that someone has compromised your server and now has access to it. Either way, you’ve been pwned. Pwned is never a good thing. 🙂

What’s “Have I Been Pwned?”

The website “Have I Been Pwned?” is more tech than a game. It was set up by Troy Hunt because, after every major data breach, he would do a post breech analysis of the data released over and over again, and see the same credentials and passwords being used. When a data breach occurs, the attackers will sell or release any user credentials they obtain.

Most users have the bad habit of reusing logins and passwords, so the credentials that work on one site may also work on another site. Thus if a user’s data is released from one site, it can be potentially disastrous for a user because the attackers can try their login and password on a multitude of other sites and gain access to more and more sites and data.

How to Use It?

So Troy gathered any data he could get from a data breach and put it all in one big database. Then he built a website where you can enter your email address and see if it was included in any of the breeches he has access to. Just for fun, go ahead, click the link and check your email address. You’ll probably be surprised, and not in a good way, pwned is never a good thing. 

These days the website also provides an API that other websites can use. The main function of this website is to prevent a user from reusing a password that has already been compromised. WordPress has several plugins that hook into the registration process and check the password a user is trying to use against haveibeenpwned.com’s API. The API takes a prefix of a “hash” of the password. The password itself is never sent across the wire. It returns all the hashes that start with that prefix.

The plugin then looks for its exact hash. If it finds it, it will give the number of times that password has been released, regardless of the site that was breached or the user name. The plugin then makes a decision on whether or not to let the user use that password.

This, by itself, will not make your site safe. As I discuss in “Is My Website Safe”, there is only one way to secure a computer from the Internet – turn it off. However, adding this layer to your security stack is one more way to make it more secure. Add enough layers of security, and your site is not an easy target, so attackers move on to another one.

[subscribe_cta]

Posted on

When Do You Need to Hire a Programmer

UPDATE: In case you’d like to learn more about what goes into planning, building, and deploying a website, we strongly recommend that you watch our “Web Developer AMA (Ask Me Anything) webinar”. In this webinar, our panelists – popular experts Cal Evans, Michelle Schulp, David Bisset, and Mario Peshev – will answer various web development questions and share their own experience on the topic. You can also listen to our podcast episode “Do I REALLY need to hire a developer” where host Cal Evans talks more on communication with your developer, defining budgets, reporting on the task, and so on.

If you are thinking of building a website, a web application, or a web-based store, at some point, you are going to ask yourself the question, “Do I need to hire a programmer?” The short answer to that question is “It depends.”

Three Scenarios

The real answer to that question will depend on who you are and what you are trying to build. Let’s take a look at three common entrepreneurs.

Alice

  • Alice owns her own hand-made widgets store but wants to branch out into selling her widgets online.
  • Alice understands the intricacies of hand-crafting widgets of high quality. Alice understands to a great extent who her market is and how to reach them.
  • Alice knows what she wants her website to look like but doesn’t have the skills to stand up the site, design the site, and maintain it.
  • Alice plans on managing all of the content and products on her site. She just needs someone to deal with development and design.

Alice needs both a developer and a designer to work with her to get her site up and operational. After that, she will need her developer partner on a retainer to handle monthly maintenance, and deal with issues as they arise. She will need her designer only when she wants to re-skin her site or add new graphical elements.

Bob

  • Bob has an idea for a new service that is web-based.
  • Bob understands how his idea will work.
  • Bob knows what he wants the website to look like and how the application will flow.
  • Bob is not planning on selling multiple products or services, just this single idea.

Bob needs a development partner for the long haul. Bob should seriously consider hiring a developer either part-time or full-time until the product has shipped. Bob will need a designer to develop the graphical elements, but since there is a single service involved, the relationship with the designer will be temporary.

Mary

  • Mary wants to set up a webshop to sell her photography.
  • Mary is a power-user. She understands computers and knows a little about programming.
  • Mary is comfortable with computers and has always wanted to learn programming.
  • Mary has a steady permanent income, and this project will not be her primary source of income in the beginning.

Mary probably does not need to hire a developer. Given that she is a photographer, a creative pastime, she may not even need to hire a designer. Mary can start with existing plugins and themes and customize them as necessary, using the WordPress admin interface.

If Mary chooses a good hosting partner like SiteGround, that will take care of WordPress and plugin upgrades, as well as routine backups and scanning her site for malware, she doesn’t need to immediately invest in a developer retainer to manage all of that. She can set these things up herself.

Mary may need to hire a developer in the future if she needs the functionality that does not currently exist in plugins she can download or buy. She may also want to eventually hand off the management of her infrastructure to a developer partner so that she can focus more on her photography.

Seriously, It Depends

As we’ve seen in these three different scenarios if you need to hire a developer, and at what stage of the project, largely depends on the project, and on you. If you are unsure about whether you need a developer, chances are good that you do.

Invest a little in your project by hiring a developer to sit down with you and do the “discovery phase” of your project. This is where the developer listens to your idea, asks you a LOT of questions, and then presents you with a detailed plan on how to build out your idea. They will most likely also present you with a quote for what it would cost for them to build it out.

The great thing about paying for the discovery phase though is that you now own the documentation that comes out of it. If you have any doubts about the developer you have chosen, you can shop the project around to other developers who can take the documents and give you an estimate without having to go through another discovery phase.

Don’t wait until you’ve gotten into the weeds of your project only realize that you are in over your head. Make the decision on whether to hire a developer early on in your planning phase. Then, invest the time necessary to find one with whom you feel comfortable working. Your project will go a lot smoother in the long run.

[subscribe_cta]