In Support of Stronger Passwords – Not Secret Usernames

I can discover usernames in WordPress, which means I’m halfway to compromising an account.

It’s a common security report. The details vary – sometimes they find usernames through CSS classes, sometimes they’re using enumeration, sometimes it’s from a REST API endpoint – but the real problem is that the underlying logic is flawed.

WordPress has taken the stance that usernames aren’t secret.

From our handbook:

The WordPress project doesn’t consider usernames or user ids to be private or secure information. A username is part of your online identity. It is meant to identify, not verify, who you are saying you are. Verification is the job of the password.

Generally speaking, people do not consider usernames to be secret, often sharing them openly. Additionally, many major online establishments — such as Google and Facebook — have done away with usernames in favor of email addresses, which are shared around constantly and freely. WordPress has also moved this way, allowing users to log in with an email address or username since version 4.5.

Instead of attempting to hide a public identifier, WordPress attempts to encourage users to choose strong passwords instead, through both user interface as well as education.

Note that WordPress is not the only open source project to believe this. Drupal has similar arguments for the same thing.

Why? Because knowing a username doesn’t mean you’re halfway to compromising an account. Let me explain.

[bctt tweet=”Knowing a username doesn’t mean you’re halfway to compromising an account.” username=”aaroncampbell”]

Usernames Are Public

A username is an identifier, a claim to who you are, much like your actual name. When I go to the bank to pull out cash I identify as Aaron Campbell, but then they want to verify that by looking at my drivers license or passport. That required verification is your password. I share my name with anyone, but they cannot have my verification documents. Those are mine.

Moving back to the internet, my username on Twitter is aaroncampbell and every one of my followers knows that. My username on Gmail and Facebook is aaron@xavisys.com and anyone that ever E-Mails me knows this – it even used to be on my business cards. You could discover my username on this site, but you don’t need to – it’s aaroncampbell.

Even if I didn’t have two factor enabled in all those places though, you wouldn’t be “halfway” to compromising any of those accounts. Users know they need good passwords but usernames are generally simple, easy to remember, and alphabetic or alphanumeric. To put it simply, they’re already easy to guess.

But wouldn’t keeping them secret still help? Wouldn’t having to guess both the username and password make it twice as hard? Shouldn’t WordPress help with that?

No, no, and no. And it all comes down to entropy.

Entropy

Password strength is usually referred to in terms of information entropy, measured in bits. The idea is that a password with 42 bits of entropy would be as strong as a string of 42 random bits. There can be a lot of complexity in calculating accurate entropy. Dictionary words (including ones in custom dictionaries built for the target), patterns, dates, and many other things can be used to reduce the raw entropy of a string. Best case scenario though, your password isn’t susceptible to any of those, in which case the raw entropy (H) can be calculated using this formula, where N is the number of possible symbols for each character, and L is the number of characters in the password:

H = log2 NL

Let’s calculate the entropy of my username of aaroncampbell. It’s 13 characters long (L) and each character has 26 possible symbols (N), giving ~61.1 = log2 2613. Keep in mind that in a real-world scenario, my first and last name, along with many other words specific to me, would likely already be built into a dictionary, making this number much lower.

Given a very short (too short), ten character random password of yZ3#8gPI^0, the entropy is ~65.7 (log2 9510).

Assuming that you can try to crack the username separate from the password, the combined entropy is ~126.8. If you instead increase the length of your password to 20 characters, it’s entropy alone would be ~131.4. All my passwords are 50 characters or ~328.5 bits of entropy.

The Best Solution

Don’t worry about your username, but do focus heavily on your password practices. Use a password manager like LastPass or 1Password. You cannot have good password practices without a password manager. Good passwords should be long – 50 characters is what I use; random – not a “random phrase” you use, but actually randomly generated using a large character set; and unique – only used in one place.

[bctt tweet=”You cannot have good password practices without a password manager. Try @LastPass or @1Password.” username=”aaroncampbell”]

Bonus

If you really want to secure your account, use two factor authentication (2FA). Many sites offer this option, and I personally use it everywhere I can. I use Authy as my 2FA app because I think it’s the most user friendly. It allows me to rearrange things to fit my preferences, add it to multiple devices, and even backup and restore everything for when I change devices. You can also use Google Authenticator or LastPass Authenticator. To add 2FA to your WordPress website, you can use iThemes Security Pro (paid), which is what I use, or Two Factor.

Website Security – Simple Steps to Take

Website security is important. We all know it. For many though, it’s a topic they prefer not to talk or think too much about. They don’t really consider it in very many areas as they build or manage their site. Why?

Security is Scary

You know you want to be secure, so you start to check out this weird security thing. Brute force? You can handle that; good passwords, limit login attempts, maybe even two factor authentication. Then you suddenly become aware of cross-site scripting (XSS), SQL injection (SQLi), cross-site request forgery (CSRF), remote code execution (RCE), and potentially so many more that you’re simply terrified. You begin to buy into “ignorance is bliss”. But website security doesn’t have to be scary.

[bctt tweet=”Website security doesn’t have to be scary” username=”aaroncampbell”]

Security is Something You Can Handle

When you start to research website security it’s easy to become overwhelmed as you’re slowly exposed to all the various forms of attacks. Each can be nuanced, complex, and confusing. The good news is, you don’t need to know how every vulnerability works in order to increase your security. Many of them can be prevented by following some relatively simple best practices. With a little added effort and by making a few smart decisions along the way, you can drastically increase your online security.

[bctt tweet=”A little added effort and a few smart decisions can drastically increase your online security.”]

When most people think about securing their site, the first thing they think of is their password. And passwords are important. They aren’t where you should start though.

Security and Your Host

The security of your site needs to be managed all the way down “the stack”. The stack is all the software that sits on top of each other in layers to become your website. The tip of this is likely all you really interact with – WordPress and your plugins. Below that is your database, PHP, caching tools, web server software like Apache or nGinx, and an operating system. There’s probably also a firewall somewhere either inside that stack or outside as a separate appliance.

Every part of this software stack needs to be properly configured, managed, and continually kept up to date. It’s integral to the security of your website. It’s also a lot of work and quite complex. Thankfully, you don’t have to worry about it if you choose a good quality host and let them worry about it for you.

Consider security when you choose a host. If you haven’t checked to see that your host has good security practices, take the time to do so. If you haven’t yet chosen a host, make sure that security is one of the things you evaluate when you do.

Choose Quality Software

Most of you are here because you use WordPress. I’m obviously biased, but I think that was a good decision for security. The WordPress security team works very hard to make sure that WordPress is as secure as possible. However, WordPress isn’t the only software you’re using to run your site.

You need to make good decisions about what plugins and themes you use as well. Did you consider security as you selected your plugins and themes? Did you look into the security practices of the companies or developers behind them? Don’t expect to find plugins or themes that have never had a security issue, but do look for those that have handled them well and have implemented good security practices into their development processes. You want quality plugins and themes with reputable people or companies that stand behind them.

Take the time to consider other software you’re using as well. Are you using a reliable and reputable SFTP client? Are you running good virus protection software on your computer? With the pervasiveness of the Internet, many modern computer viruses work to harvest login details from websites and send them to someone for later use. Learning to think about security at every step of the way, getting into the “security mindset”, will really help. You’ll start to see places that you can increase your security that you had never before realized even affected your website.

Great Password Practices

Everyone knows that it’s important to have good passwords, but what makes a password good? A good password is long, random, and unique.

How long should a good password be? I tell most people that it should be a minimum of twenty characters. All of mine are at least fifty unless the site or service has a lower limit (which usually leads to me whining lots and often reaching out to them to discuss better password practices).

What do I mean by random? Well…I mean random. Not a snippet from a poem you like, not a favorite verse, not a seemingly random combination of things you know or easily remember, and not a pattern on the keyboard. The best passwords are completely randomly generated.

Unique means that the password is only used in one place. The password to log in to my website is different from the one for my E-Mail, which is different from the one for my computer, which is different from the one for my back, etc, etc. I don’t use the same password in two places and neither should you.

How can I possibly have that many different fifty character passwords that are completely randomly generated? Do I have a super human mind? Not at all. I use a password manager. You can’t have good password practices without a password manager. I use LastPass. Lots of people love 1Password and it’s a great option as well. I don’t care which you use, but you need to use one.

[bctt tweet=”Passwords should be long, random, and unique. You need a password manager to do it right.”]

This is one of those areas where you have to put in that added effort I mentioned. A password manager will take some time and effort to set up and get used to using. Eventually though, you’ll probably find that it makes things easier not harder. It’s a fantastic investment into your online security.

Two Factor Authentication

When you try to log into your site you fill in a username field. On this site for me, that’s either my E-Mail address or “aaroncampbell”. That’s me saying “I’m Aaron”. My site wants proof of that though, as it should. There are three basic ways you can prove you are who you claim to be.

  1. Something you know – A password for example. With your bank this might be a PIN. As a kid with a fort, it was a code word.
  2. Something you have – For your car, house, hotel room, etc this would be your key. “Let me in if I have this.” For your website this is probably your smartphone with an app on it.
  3. Something you are – Many phones are starting to support fingerprint access for example. Some data centers use retina scans.

Two factor authentication (2FA) simply means that in order to verify you are who you claim to be you must supply proof from at least two of these groups. For websites this is almost always something that you know – your password, and something that you have – your phone with an authentication app on it. I use Authy because I think it’s the most user friendly. It allows me to rearrange things to fit my preferences, add it to multiple devices, and even backup and restore everything for when I change devices. You can also use Google Authenticator or LastPass Authenticator.

There are two plugins that make easy to add 2FA to your WordPress website.

  1. iThemes Security Pro is a paid plugin that also does many other great things for your site. If you want to invest a little money in the security of your site, invest in your host and in this plugin.
  2. Two Factor is a free plugin by George Stephanis that adds two factor authentication to your site simply and effectively.

Like your password manager, some additional effort is required for setup and to get used to it. However, the added effort here will continue forever. Every time you log into a site you use two factor authentication on, it will take you an additional fifteen to thirty seconds. It is absolutely worth it though. Using multiple factors for identity verification increases security so much that it’s honestly hard to quantify.

Bonus: Once you get used to using two factor on your WordPress website, start using it everywhere else too. I use it on GMail, Github, Slack, Amazon AWS, Mailchimp, Mandrill and more!

SSL Certificates

Encrypt all data sent between your website and the computer or device that’s accessing it with an SSL certificate. It’s the thing that changes the URL from http:// to https:// and adds a lock and/or a green color to the URL bar of the browser to let the user know they are browsing safely.

SSL Certificates add a visual cue to browser bars, reinforcing a user's security

At this point, there’s no reason for any site to not have an SSL certificate. They used to be quite expensive but cost is no longer an excuse. Many hosts offer them for free and the ones that don’t offer them cheaply. Often you can install them yourself through your control panel, but if you can’t opening a ticket with your host should take care of it.

Is Security Really That Important?

People want to know “why would anyone want to attack my website?” They think that because they don’t process credit cards or store personal information, that no one would care to hack into their site.

It’s not if you get attacked, but rather how you prevent it from being successful.

There are two basic types of attacks that try to compromise sites.

Targeted attacks are the kind that people tend to think of first. A person or persons work to compromise a specific site for some sort of payout. Often they’re trying to get credit card numbers, identities, etc. They want a good payout and put in a concerted effort to get it.

The second, and far more prevalent, are scripted attacks. Programs written to crawl the internet and try to compromise sites. Pushing for sheer numbers they look for simple to break passwords, out of date software with vulnerabilities, and other known weaknesses that can be exploited in an automated way. Instead of a large payout from one targeted site, the script attacks hundreds of thousands or millions of sites, compromises thousands, and makes a little bit from each. These attacks aren’t only more prevalent, but are indiscriminate. Anything attached to the internet will be attacked. It’s not if, but when.

Make it Hard on Them

Attacks on your site will happen. You can drastically improve your security, and thus your ability to fend off these attacks, by following these best practices. They’re not overwhelming. They are all things you can do.

  • Use a Security Conscientious Host – Keeping the stack your site is built on secure helps keep your site secure.
  • Choose Quality Software – Starting with WordPress is great, but also look at your plugins and themes as well as software on the computers you use to build or access your site.
  • Use Great Passwords – Great passwords are long, random, and unique. You can only do this correctly with a password manager.
  • Use Two Factor Authentication – Two factor authentication will use something you know (password) as well as something you have (your smartphone) to verify you are who you claim to be. This is a massive leap forward in the security of your user account.
  • SSL – Every site should have an SSL certificate. Inexpensive or even free, SSL certificates encrypt all data sent between your website and the computer or device accessing it.

 

Open Source Got Me Started

I started writing computer code about 26 years ago in 1991. At that time it wasn’t easy to teach yourself how to code. The Internet existed but not in the way we know it now. It was much smaller, contained far less data, ran at much slower speeds, and the first graphical browser didn’t even exist until two years later. So how did nine year old me learn? Open source.

Games Get Me

Windows didn’t gain popularity for another year or so. MS-DOS 5.0 released that year though, with a couple life changing games. Nibbles was a classic snake game where the snake grows with each thing it eats and you work to avoid running into obstacles, the wall, or yourself. Gorillas was a turn based combat game of sorts, featuring banana throwing gorillas on a skyline. I played both games as most nine year olds might, bordering on obsessive, but it was the mathematics in Gorillas that really caught my interest.

Screenshot of Gorillas game
The original Gorillas in action. I admit it, I’m feeling quite nostalgic

Each player took turns entering an angle and a velocity. Their gorilla would then throw an exploding banana accordingly. The goal was to hit the other gorilla, although the city scape could get in the way. You might have to explode though a building to get your opponent, or throw extremely high and hard to get the right angle to hit them without hitting a piece of the environment. Creativity was a part of it, but it was the numbers that really made it what it was to me.

After a while though, the novelty wore off some. I got surprisingly good at judging angles and velocity and fewer and fewer people wanted to play against me anymore. That’s when a fun game became life changing.

Open Source

Screenshot of the Gorillas open source code
This is what you saw each time you played the game. “Press Shift+F5” to play was as user friendly as it got.

Gorillas and Nibbles were both written in QBasic, which is sort of a combination of the BASIC programming language, an IDE, a compiler, and an interpreter. Meaning you could write code in QBasic and it was capable of executing it right there inside the editor. As a curious nine year old I scrolled down to look at the code that powered the game that I enjoyed so much. And I learned.

There’s no way that I could have written either of those games at that time in my life. It took months before I could even convince my parents to take me around to book stores in search of resources. But I learned a lot from the code itself. I broke a lot of things, but succeeded in making the bananas behave differently, adding invisible obstacles, spawning the gorillas inside the buildings, and more. It was practically intoxicating! The POWER! It hooked me completely. Because of open source.

Leveling Up

In the early nineties I got into BBSs. First just logging into them to play “door games” (sorry young people, you’re going to have to Google some of this yourself) and eventually running my own. One of my favorite games was a MUD called Legend of the Red Dragon (L.o.R.D.). Being highly competitive, I found value in tracing through the code of the game and the in-game modules to find the secrets and tricks to be able to level up faster. My ability to understand code was now an asset to ten year old me.

I learned a scripting language called “lady” in order to build my own modules. Existing modules, and their code, were my teachers. My BBS started to stand out as I added my own unique tweaks to a popular game. Enough that my parents noticed. And were none too happy with having three phone lines in our house, all of which were constantly busy. My leveling up in games through code didn’t end though.

Chip’s Challenge was all the rage when I was twelve. My seventh grade class went nuts over it. It was a puzzle solving game wherein you overcame obstacles to collect keys. When you completed each level you were given a code to write down. You could use that code to start up where you left off. Everyone was in on the challenge and the codes were proof. I immediately tried to turn to the source code as a solution and was horribly disappointed to find out that I couldn’t.

Open source had been so amazing, but it took a closed source application to really make me appreciate it. In order to do what I thought should have been easy, I had to learn about hex editors, earn codes manually, and use each new code I earned to slowly reverse engineer a compiled file. I was the first of my class with a full set of codes, but I was also now enamored with open source software. And it was a closed source game that pushed me that way.

My Mentor

For anyone that knows what hex editors are or what it takes to reverse engineer compiled code, that last bit might have sounded a little crazy. For those of you that have no idea what any of that is, the correct response is roughly “how could you learn how to do that as a twelve year old in 1994!?” The answer is that I had a mentor now. The summer before seventh grade, my parents connected me with the person that ran the computers for the school union I was in.

I spent that whole summer learning under him. I continued to work with him through all of junior high. Even then, much of my learning happened from “open source”, although in most cases it was his source code. I learned the basics of Novell Netware scripting, more BASIC, C, and more. All by having the chance to look at various sources of code and ask him questions.

Back to Open Source

As the Internet became more ubiquitous, I pushed back into open source. It was easier now. In 2000 I started developing websites for money and used only open source platforms. I knew better now. I knew that the easiest way to have the control I wanted was to be able to view and modify the code. In 2005 I made a pivotal decision; I moved to WordPress development. In 2007 I started to contribute back to the project. It hooked me again, and I’ve been happily contributing to and advocating for open source ever since.

Twenty six years later and I still love open source. More than ever. 💗

The Difficulties of Security Disclosure

Security is ever a game of balance. Ease of use against safety is the one I find myself thinking about most often; locks on your door inconvenience you with having to get out your keys, long and unique passwords necessitate working with a password manager, two factor requires additional equipment and steps. Most often adding security impacts ease of use in some negative way. Finding the balance here is important.

But security isn’t a single balancing act. Many of the decisions we must make require finding the right balance. Each requires thought and consideration, as well as a clear set of priorities. Especially when it comes to disclosing vulnerabilities. Every situation is going to be unique, but knowing the right questions to ask will help. The time to think through these questions is now, hopefully long before you are faced with them.

Should This Vulnerability Be Disclosed?

Yes.

Disclosing the vulnerability is best for your users. It builds trust. It’s also the best thing you can do for the future of security. Hopefully other people can learn from your issue and not have to face the same one themselves.

“But, it’ll make us look bad!” You’ll look worse if someone else discloses it and you were hiding it. No security is perfect. Every company I’ve talked to that has owned up to a security issue has ultimately seen increased trust from their users.

“But it’s fixed now and no one was affected.” That’s fantastic! Well done! You should let people know how well you handled it.

“But if we make it public, people will try to exploit it!” Now we’re getting somewhere. This shouldn’t be a question of if, but of when. And deciding when to disclose can be tough.

When Should We Disclose?

Who would have thought a four-word question could be so complex and hard to answer? There is so much to consider. How do you balance what’s best for your users and your own reputation (spoiler: What’s best for your users is best for you)?

To figure this one out, you’ll need to answer a couple additional questions.

How Serious is the Vulnerability?

Objectively rating the severity of an issue can be tough, but considering these three things will help:

  • Discoverability – How likely is it someone could discover this and begin to exploit it?
  • Exploitability – Is this easy to exploit? Can attackers script it? Does it require authentication or social engineering?
  • Reach – How many are affected by this?
How Can We Best Protect Our Users?

It might be that you can protect your users by giving them time to update to a secure version before disclosing. The worst thing about disclosing is that you can not only disclose to the “good actors”. When you put the information out there, it’s available to the well-meaning as well as those with more nefarious intentions.

While waiting can give users time to upgrade, remember that if the issue is discovered and exploited before your users know about it, you have ultimately put them at a disadvantage.

How Detailed Should the Disclosure Be?

Yet another balance to be found. This one between informing your users and giving instructions to the potential exploiters.

Make sure to include enough information for your users.

  • Help them understand how severe the issue is. Hiding the severity doesn’t help them.
  • Let them know what risk they face.
  • Give them steps to follow to protect themselves.

This is not a how-to. Do not include enough information for people to be able to easily exploit. Make them figure that out on their own.

What Did I Do Wrong?

Ask yourself this last question after everything has settled. Maybe a week or two after the actual disclosure, sit down and assess how it went. Revel in the successes, but admit the mistakes. Use them to tweak your processes for next time.

Case for the REST API Endpoints

The Open Web and a History Lesson

For this to make sense, you first need to understand how I view the web right now. The internet has become a foundation that a huge percentage of humankind rely on. I think that our future is as dependent on technology, the internet being a key piece of that, as our recent past has been dependent on scientific foundations. I truly believe that the future of all people will be better if this key piece of our technological foundation is freely available to all, able to be used for any purpose, and not controlled or excessively influenced by any particular person or group.

I gave a short talk recently in Phoenix, where I said this very thing, and it came with a small history lesson that bears repeating.

Robert Hooke was a scientist in the late 17th century. Many of you might vaguely remember his name from your junior high science class. He’s the guy that looked at cork under a microscope and discovered that plants, and much more, are made up of cells.

Isaac Newton is a name you probably remember better. We all picture an apple when we think of him, right? Something about gravity? The truth is that Isaac Newton gave us a lot. He invented calculus, discovered many things about light including that white light is made up of many other colors of light, and in his principia he gave us laws about gravity and motion.

In a letter from Newton to Hooke in 1675, Newton famously said:

If I have seen further, it is by standing on the shoulders of giants.

And the best part is, we’ve been standing on the shoulders of people like these since. Much of modern medicine can be traced back to an understanding of the cell. Similarly, our world has been made smaller through things like air travel, where modern jet engine technology could not exist without calculus or the principles of force that Newton gave us.

Because of this, society as a whole has been able to make consistent and rapid progress forward. People don’t have to start over. They don’t have to rediscover the cell or create calculus, and can instead pick up where others left off and move forward from there.

So what the heck could this possibly have to do with the REST API endpoints in WordPress?

We’ve built something that has the potential to be a tool for others to use. It’s part of the height of our proverbial shoulders. It may not have the far reaching effect that calculus has had, but it does have the chance to do things that we can’t currently imagine. Newton probably didn’t imagine the Boeing 777 either.

If we don’t offer these kind of modern tools, built into WordPress, to allow people to build the future of the Internet, then we risk them using similar tools offered by closed solutions from Facebook to Medium.

It’s going to be a lot of work. Not just to merge, but to keep up, improve, and generally manage for the future. But it will be worth it. To push forward the open web. To help make sure that people can pick up where we left off and keep making progress.

Joining GoDaddy as a Full-Time WordPress Core Contributor

Today is my last day at iThemes. It’s been a great two years, and I’ve learned a lot. I’m very appreciative of my time here and I will absolutely miss all the people. If you haven’t checked out iThemes or had the chance to meet Cory, Matt, or any of their amazing team, you definitely should.

So, what now?

Well, the title here kind of gives it away. I’m excited to say that I’m officially joining GoDaddy as a full-time WordPress Core contributor. I start there on September 6th, and am excited to help push WordPress forward with the full support of a company like GoDaddy behind me.

But why?

I honestly can’t remember when I first started using WordPress. I think it was sometime in 2004, because it was before Kubrick became the default theme. And it was certainly before we had things like WYSIWYG editing, which came along in late 2005 with the WordPress 2.0 release.

But while I can’t remember exactly when I started using WordPress, I remember very clearly when I started contributing to WordPress. It was June 12, 2007. That was the day that I opened my first ever bug report for WordPress, uploaded my first ever patch, and had my first bit of code put into the WordPress codebase. Yep, it all happened on one day!

Aaron's First Ticket

The feeling that I got from that was amazing. I loved that I’d just made a small impact on a group of people, most of whom I didn’t even know. I started to slowly ramp up my involvement in the project. I contributed more and more, and got involved enough to really get to know the people. By 2009 I was traveling to WordPress events, and by 2011 I was speaking at them regularly.

I’ve become very passionate about the WordPress project and the community that has built up around it. For a long time I’ve wanted to do more; to contribute more often and to take a more involved role in pushing the project forward. So when GoDaddy talked to me about bringing me on as a full-time WordPress core contributor, I was excited.

What does that mean?

Basically, I’m going to be working to make WordPress better and GoDaddy is going to pay for it!* There are a lot of massive benefits to this, including being able to have very consistent reliable time that can be counted on by release leads, being able to reliably take on projects that span releases, and being able to work on some of the less fun areas that are generally more neglected by volunteer efforts. I think that this kind of dedicated support from companies whose businesses are heavily invested in WordPress is extremely healthy for the project as a whole, and I’m ecstatic to get the chance to do this.

* For those that don’t have experience with open source software development, or don’t understand the pervasiveness of WordPress, this is going to be confusing. You’ll have to ask me to explain it all over coffee some time.

Migrating from Mandrill to SendGrid

Recently The Rocket Science Group, the company behind both Mandrill and MailChimp, decided to change things up. They decided to roll Mandrill, their transactional E-Mail service, into MailChimp as a paid addon available to paid MailChimp accounts only. A lot of people freaked out or got really upset, most of them focusing on the fact that many people who were using Mandrill for free or close to it, were going to have to start paying at least $40 per month. That’s $20 per month for a MailChimp account, which they might not even have a use for, and $20 per month for the lowest tier of the Mandrill transactional email addon.

I was upset too. Not because of the additional cost, but because of the way Mandrill users were treated. An email went out to all Mandrill users on February 24th, mandating that all existing users needed to have a paid MailChimp account set up and connected to Mandrill by April 27th. That gave nine weeks.

Nine weeks isn’t a lot of time, and Rocket Science knew this. Is it enough time to set up a MailChimp account, link it to your Mandrill account, and pay them the extra money every month? Yes. Was it enough time to research an alternative, set up an account elsewhere, rewrite all your transactional email code to use a new API, train users to use a new interface at this new solution, test all the new code, and deploy? Not really. At least not in many cases.

However, that’s exactly what I did. Not because I was upset at the extra monthly cost, but because I didn’t like being treated like that.

I started with some simple research to find alternatives. As it turned out, plenty of other people were doing the same research and posting their findings, which greatly simplified the process. What I found is that since my usage was pretty straight forward, almost any of the available alternatives would work for me. I ended up choosing SendGrid.

The actual development wasn’t particularly interesting.  The APIs are different, as you would expect, so all the code needed to be changed but was ultimately similar enough to be pretty simple.

One of our hangups came with tags. In Mandrill we used tags to label various kinds of E-Mails, what server the E-Mail was triggered from, etc. We use those to help us track where deliverability issues occur, as well as to help us track down bugs when they happen. The problem was that SendGrid didn’t have these. Luckily, SendGrid DOES have what they call “Unique Arguments“. Basically, they let us do the same thing, adding in our own unique key/value pairs, with the only downside being that their web app doesn’t give you much in the way of working with those (like viewing all bounces with a specific value for one of the arguments).

And that seems to be the only real downside so far. The web app for SendGrid doesn’t seem to be quite as powerful or fully functional as the one Mandrill has. Having said that, delivery, responsiveness, speed, etc all seem completely on par. I’ll happily give up the zoomy UI though, if they’ll treat their customers with a little more respect.

Being Understanding in this Digital Age

This has been an interesting week for me. I’ve worked every day from a hospital room. To try to keep a very long story somewhat short, my grandma was in the ER Sunday, the experience was bad and they dismissed her rather than taking the time to actually figure out the problem. This resulted in her being BACK in the ER (a different ER; fool me once and all that) as 12:30am Monday morning, getting admitted to the hospital a few hours later, and being under acute care ever since.

It’s rather severe. She’ll likely be in the hospital another week or two, but the prognosis is starting to look up.

It’s been incredibly hard on my immediate family. My grandpa has severe Alzheimer’s, and while there are many things he cannot remember, he never seems to forget that his wife of nearly 68 years is in the hospital. Not for even a second. Unfortunately, he can’t stay at the hospital with her all day every day, because he needs to have some routine to help keep him on track. This means that my dad has been taking care of grandpa, and playing shuttle service to bring him to the hospital every day and take him back home every evening.

Emotions have been high as well. Everyone here cares about my grandma greatly, and that can cause logic to be clouded by emotion, making everyone a little more touchy and on edge. Especially when things weren’t looking so good.

So what does all this have to do with being understanding? Well, that comes down to some of the communications I’ve received this week. The ones from people that have no idea where I’m at or what I’m going through.

They tend to start out innocent enough. Someone asking me about one of my WordPress plugins, possibly sending me a product or service they’d like me to review, or even sending me a legitimate work proposal.

Unfortunately, any of those kinds of things that came through this week have been summarily ignored. I’m not sorry about that. None of those things are important enough to take even a few minutes of attention away from my grandma and what she’s going through. I suppose I could have responded with some short blurb explaining what was going on, but I stand by my actions as being perfectly acceptable. And yes, I’d ignore them all again (and probably will for at least another week).

Receiving, and ignoring, those messages didn’t bother me at all though. Like I said, they didn’t know where I was or what I was going through. The frustration really started yesterday (or more accurately last night), when I started to open and read some of the more recent messages. Some of then had taken on an angry tone; “if you don’t care about this, then…”, “You’ll never get my work if you don’t respond”, or “People said you were reliable, but I guess they were wrong.”

Just how fucking important do you think you are?

Not that I need to justify myself, but I think pointing out my internal responses to these statements helps underline how ludicrous they really are:

  • It’s not that I don’t care about whatever it was you were writing about, I just don’t care enough to put it above my family. Deal with it.
  • I don’t want your work anyway. Even if I was looking for work, working for an impatient, self-important, pain in the butt, isn’t my idea of fun.
  • I’m glad to hear people said I’m reliable. Right now, my family finds me incredibly so. I’m glad that me not responding to you in 48 hours gives you the right to judge me differently.

The truth is, we’ve all come to expect a level of accessibility that I think has become unreasonable and unsustainable. Technology has made it so that most of us, myself included, walk around with our E-Mail, Twitter, Facebook, etc in our pocket. We tend to check it habitually, and therefore respond quickly. Often within minutes or hours.

The problem is that, as we all know, doing something consistently builds expectation. People now expect a response within an hour, think themselves patient if they wait half a day, and feel like you’re purposely ignoring or slighting them if it takes longer. The distance the electronics place between us makes it easy to never take the time to think about where the person on the other end of your communication is, what they’re doing, or what they’re going through.

I have to think that not a single one of these people would have barged into my grandma’s hospital room to give me their message, expecting me to stop dealing with family and put my attention on them. Yet essentially that’s what they asked of me.

Expectations of availability have gotten out of control. When do they afford us time for ourselves? When do we get to focus on something so important that we don’t want to be bothered?

Try to remember that even though there is often technology between you and someone else, it’s still a person you are dealing with. A person that has to go through the same kind of crap as you sometimes. Be understanding.

WordPress Security – The Big Picture and What You Need

I’m pretty passionate about WordPress, I’m pretty passionate about security, and I’m heavily involved in both. I’ve been working with WordPress for over ten years and helping build WordPress for over eight. I’m also on the WordPress core security team and have recently taken a lead role working on the iThemes Security plugin.

There has been a lot happening around WordPress security lately. Even the Federal Bureau of Investigation (FBI) has weighed in with a Public Service Announcement. An article by The Register covering that PSA was recently brought to my attention through Facebook, and honestly caused quite a stir.

First, the URL itself ends in “word_press_is_atrocious”. Ignoring the fact that WordPress is a single word, the word atrocious is never used in the article itself. It’s just a good, scarey URL. Even without using that word though, the article scared a lot of people. It ends with this gem:

WordPress hacking is a favourite pastime of lazy hackers and exploit kit -slingers who seek to achieve maximum carnage for minimum effort.

Is that really the case?

I think that the maximum carnage part is obvious. Numbers put WordPress at somewhere between 20 and 25 percent of the web, so if you want to be able to affect literally tens of millions of sites at once, you want to compromise WordPress.

Having said that, minimum effort is also accurate and explainable. Minimum effort because you only have to target a single system. Minimum effort because when you find an exploit, even one that’s already been patched, there are going to be sites out there that are vulnerable because people don’t upgrade. Minimum effort because you can stand on the shoulders of giants, since so many people are working to do exactly what you’re doing.

Sound scarey? It’s really not. Especially not for you! It’s tougher for the project as a whole…I’ll try to explain.

In the last couple years, the target on our back has grown because we’ve grown. But we’ve made a lot of progress toward being more secure. It goes FAR beyond patching a security hole. The biggest insecurities come from those that don’t update and from insecure plugins or themes. So we focused on those.

Now we have auto updates. When a new security release of WordPress is released (the y in x.x.y), WordPress updates to it automatically. Of course, some people complained about this, but ultimately (and statistically) WordPress sites on the whole are much more secure now.

We’ve also put some pretty serious systems in place for handling plugin vulnerabilities. We have plugins@wordpress.org and security@wordpress.org that can be E-Mailed if a problem is discovered. We have a plugin team that can review it, and if necessary remove it from the repo while a fix is worked on. When a fix is released, if it makes sense, we can even push the update automatically like we can with security releases of core.

We take this EXTREMELY seriously. We don’t want to update a plugin and break a site, so we don’t force everyone to the latest version. Instead we require a security patch be applied to each branch of the plugin and only update you to what you already had…but SECURE! BOOM! Isn’t that nice? I mean, people complain, but again: WordPress sites as a whole are more secure.

In the specific case sited in the Register article, they are talking about WP Super Cache. If we use their numbers, there are one million sites affected by this vulnerability. Remember, that’s out of over sixty million sites that run WordPress. And what do you need to be secure again? Simply update the plugin. A few clicks in your dashboard. Unfortunately, some people will put off the update, leaving their site vulnerable to attack rather than installing the update quickly and fixing the problem.

The good news is, we can push out patches to all one million sites in ONE DAY. All those sites will be secure again, even though it was a plugin that had the vulnerability.

So that’s the big picture, but I said it was easier for you, didn’t I? What can you do? There are lots of things, but let me list out the biggest ones for you so you can tick them off:

  1. Check your site daily and update things.
  2. Use strong passwords. This means getting something like 1password or Lastpass because you can’t have 50 character random passwords that are different for every site without having a way to manage those. In this same vein, usernames aren’t secret. Don’t worry about your username, just make sure your password is strong.
  3. Limiting login attempts is great. It’s NOT a replacement for a strong password, but it helps with brute force attacks. None of the recent big (meaning affecting lots of sites) vulnerabilities were from brute force attacks, but they still happen. If you have a strong password, brute force is more likely to take down your server than result in a compromised site. Obviously you still want to avoid this.

There’s obviously more you can do. Security is complex, nuanced, and tedious. But if you do those three things, you’ll be most of the way there.

Header image credit smlp.co.uk, on Flickr